MapR and containers

2018 will be the year of Containers as its value to developers and operations teams becomes more obvious in terms of how it supports DevOps. From a developer’s perspective, it is about the freedom to develop in any language on any operating system and any infrastructure, the container is the critical environment that developer’s use. The central store is a library of base images that are supported by the organization. The developers can use these images to construct their applications, then using a common set of tools the performance can be monitored and these services deployed. Ovum considers that the major issue with the current containers technology is it lacks any real consistent ability/approach to deploy stateful container-based applications easily. In this Report understand how MapR provides a platform to allow developers to produce stateful container-based applications simply.

Why containers will move from hype to mainstream adoption in 2018/19

The old world of VMs is rapidly coming to an end in terms of its market dominance. VMs have a profile that meets the current needs of organizations, the use of VMs is ideal for execution runs measured in terms of hours to months and are charged on a VM per hour basis. The issue with VMs is they require constant patching and are still representative of the monolithic applications, only virtual versions of them. Containers provide a journey to the microservices architecture, with containers the basic building block is a file and it is a fully versioned service, with its use measured in minuets to days. The charging is still VM per hour but these containers are more granular and begin to the SOA approach of constructing new services from re-useable components.

Operations benefit from being able to define the base images and therefore standardize the environment to match their skills and constraints. Containers are still in its early stages of maturity, but with more ISVs switching to containers as the vehicle for software development and distribution the expansion of this lightweight technology looks certain to accelerate in 2018. The big questions about the use of Containers revolves around the roles and responsibilities, Containers enables the organization to develop the workflow to match its needs and organizational structure. However, as developers demand greater self-service ability to develop, test, and deploy these services the old tensions between Dev and Ops will re-surface. Ovum believes that while containers make deployment simple and could be ceded to development or business teams, the role of IT operations must not be over-looked as the infrastructure still needs to be considered in any software delivery lifecycle and the concept of SLAs or guarantees will be expected on these services, so Containers still needs the correct processes and procedures to be followed. The advantages of a technology like MapR is it enables these containers to access persistent data storage, which operational teams understand and can provide to the developers. Without persistent data storage the container application requires additional high availability level exception handling to be coded in to the application, therefore increasing the responsibility of the developer and making the application more complex and potentially reliant upon the underlying infrastructure.

The MapR Persistent Application Client Container (PACC) Provides Seamless Data Persistence

The issue for many developers with containers is how to make the application stateful in an easy and consistent manner. PACC is based on a Docker container image that is designed to operate with the MapR client. It connects to the MapR Converged Data Platform (MCDP) as the persistence tier, which includes a file system, a database, and a data streaming service capability. To give the container applications access to a persistent store, PACC uses a FUSE-based POSIX client that allows applications to read and write data directly to a MapR cluster just as if they were writing to the LINUX file system. This lets organizations deploy existing applications in containers with no code changes, onto any node in their infrastructure.

The convergence of file system, NoSQL database, and event streaming is what makes the MapR Converged Data Platform useful for containerizing modern applications. You can leverage any combination of files, schema-less NoSQL records (especially in JSON), and event streaming data. Consider the platform services available in a MapR deployment:

MapR file system (MapR-FS)

MapR enables both structured and un-structured data to be managed in a unified approach. Part of the simplicity of the MapR approach is it allows all storage disks to be referenced as a storage pool. And because the file system is designed for cluster environments it avoids common problems such as locking contention, which enables reads and writes to be performed faster and more efficiently. The other major advantage of the MapR file system is it is not a layered file system, meaning it is not a secondary file system that sits above any base file system in the operating system. It is a true file system with its own high speed I/O and caching systems, and therefore does not introduce I/O latency, overhead, or delay on any read or write.

MapR database (MapR-DB)

The MapR database is a NoSQL database and uses the MapR file system at its core. A NoSQL database has some advantages and some aspects that users must be aware of. For example, at periodic intervals, the logged incremental data updates must be written to disk, and this operation will consume resources and introduce delays, so the timing of these writes is an important consideration. However, the MapR-DB architecture uses smaller optimized logs that avoid the latency that other NoSQL databases exhibit. Also, for Ovum the big benefit of MapR-DB is its ability to support analytics through integration, MapR-DB can be run in the same cluster as Apache™ Hadoop® and Apache Spark, enabling organizations to immediately analyze or process live, interactive data with Hadoop.

MapR streaming (MapR Streams)

Making any distributed system operate requires a communication channel through which application, containers, can pass messages. MapR includes in its MCDP a publish and subscribe message bus. MapR groups messages in to collections, called topics, and these topics can be managed from a security, replication, and retention aspect by applying policies at a global or topic level.

MapR provides a route for organizations to start the micro-services-based journey to application flexibility

Microservices are the next stage on the journey beyond containers, and while currently this has little traction in the market, Ovum considers that from 2018 it will begin to find applications where microservices can deliver real business benefit being offered as services. One of the key attributes micro-services architecture will require is the ability to be stateful in a multi-dimensional environment. The analogy often used is that of a chain is only as strong as its weakest link, which means any stateful services must be as fast and portable as the stateless services. This requires a degree of control that implies it must be inside the application, or platform, and not managed outside of the application where there is less control. The market is yet to become fully defined in terms of will containers and microservices be competitive or complimentary technologies. Ovum considers that while some workloads will naturally be best served by one or the other, many workloads could be delivered by either approach. Both these approaches are complimentary and eventually microservices will become easier to deploy as containers, and containers will become more agile with microservices in them.