This post is the fourth in the series “Containers Power Agility and Scalability for Enterprise Apps.” To view the series from the beginning, click here.
IT’s mission is essentially all about trying to achieve and then maintain a balance between speed, flexibility and cost. There was a time when every application ran on its own server. But that’s both fundamentally inefficient and costly because most applications don’t continually process data. If every application had its own server, managing the environment would be overly complex, and the number of applications any organization could afford to run would be limited.
The need to more cost-effectively share a physical IT infrastructure gave rise to virtual machines, which enable multiple operating systems to share access to the same underlying physical infrastructure. Because accessing all those virtual machines gets a little unwieldy, it wasn’t too long before thousands of virtual machines were being marshaled together to create platform-as-a-service (PaaS) environments, which layer middleware, databases and tools for developing applications on top of virtual machines.
But while that approach has served IT organizations well, it’s still not very efficient. Each application needs access to its own guest operating system, and that means that each virtual machine includes a complete OS. Over time, that adds a lot of overhead into a IT environment that would be much more efficient if applications could share access to a common, lightweight operating system. That simple idea gave birth to the concept of containers.
Multiple containers can run on the same machine and share the OS kernel. Each container runs as an isolated process in user space. Container images are typically tens of megabytes in size and start almost instantly. In contrast, each virtual machine tends to be much larger, takes minutes to deploy and boot, and, over time, tends to grow even bigger.
Containers allow each application to be packaged with its own runtime environment. That runtime environment includes all the libraries, configuration files and application binaries needed to run an application image. This capability is what allows multiple applications to run on the same operating system.
Containers have been around for a long time, but containerized applications only became truly portable between multiple operating systems with the arrival of Docker containers. That provided developers with a more efficient approach to packaging application code in a way that enables the code to be deployed on multiple platforms without having to refactor the application.
It’s little wonder that containers are rapidly becoming one the most popular means of delivering code. In fact, container-as-a-service (CaaS) environments are emerging as an alternative to PaaS environments. That’s because CaaS is designed to be more agile than PaaS (which is typically optimized for building and running complex, 12-factor applications that need to be built in a highly opinionated way, unilaterally decided by the builder of the PaaS platform).
Microservices, Meet Containers
The significance of containers goes well beyond mere portability, however. Containers are enabling microservices, a fundamental change to how applications are constructed. Of course, microservices – just like containers – are not a new idea. It’s just that before containers arrived, building and maintaining applications based on a microservices architecture was incredibly difficult.
As a result, more organizations stayed with traditional monolithic applications, even though they knew that monolithic approaches to building applications were inherently inflexible. Containers changed that worldview by making it not only simpler to build an application based on microservices, but to maintain it as well.
Containers, however, introduce new challenges. When deployed at scale, it becomes necessary to introduce a layer of orchestration to make sure containers are invoked in a specific sequence and dependencies are managed. Examples of container orchestration platforms include Kubernetes, Docker Swarm and Marathon.
The most compelling aspect of containers is arguably the flexibility they inject into the application release cycle. Containers eliminate the process of “patching” an application to add new functionality. Instead, containers encapsulate new functionality that is added to the application either as a new microservice, or to replace an existing set of containers. The most efficient way to accomplish that task is to employ a Blue-Green deployment model in which two identical instances of a production environment are created. Only one of those environments runs live in production, while the other is being updated. Once the updates are completed, the second environment becomes the live environment. The cycle continues as the first environment is updated in turn.
That capability makes it possible to break up an application into a series of microservices that can be managed in isolation from one another. IT organizations make use of continuous integration/continuous deployment (CI/CD) platforms to provide the means of managing that process. Instead of updating an application once or twice a year, it’s now possible to continuously add or replace functions as desired.
The challenge that arises from this approach is connecting all the various microservices together using application programming interfaces (APIs) and then providing each microservice with access to all the back-end data sources required. While that may sound simple enough, it’s not too long before an IT organization can find itself struggling to manage a bewildering array of data pipelines that are subject to change at any moment. Organizations that can afford to hire hundreds of software engineers to manage this process have enthusiastically embraced microservices.
The issue the average enterprise organization will next encounter is finding a way to manage all those data pipelines in a way that doesn’t require many highly paid software engineers that are hard to find and retain. Automation, such as that provided by Mesosphere DC/OS, goes a long way towards easing this burden. DC/OS sharply reduces the complexity associated with managing data pipelines by providing a framework that enables IT administrators to securely deploy and manage data pipelines and applications at a higher level of abstraction.
A Better Way to Build Software
Managing access to those data sources has never been more critical. Usage of microservices based on containers has thus far been mainly limited to stateless applications that don’t require access to persistent forms of storage. Initiatives such as the Container Storage Interface that make it simpler to plug any type of persistent storage into a container orchestration platform remain a work in progress. In the meantime, there are solutions such as container storage software from Portworx that make persistent storage available to containerized applications. As more IT organizations start to realize the degree to which microservices represent a better way to build software, interest in building stateful applications based on microservices has sharply increased.
Like all monolithic applications, microservices are still subject to the laws of data gravity. The preponderance of data in the enterprise still resides on-premises, so what IT organizations need to enable a multitude of microservices to dynamically access back-end services is nothing less than a cloud of their own. Of course, IT organizations could opt to deploy microservices in a public cloud. But the cost of moving what amounts to petabytes of data into the cloud is not only substantial, but also takes a very long time.
The great thing about containers is that they can run almost anywhere. Most containers in production environments today are deployed on virtual machines or in a PaaS environment, because many IT organizations still don’t have access to tools to manage them natively. There are also some concerns about the level of isolation that can be achieved between noisy and nosy container neighbors sharing the same physical machine.
But as containers and the platforms they run on mature, it’s only a matter of time before many more containers are deployed on physical machines. The number of containers that can run on a physical server can be counted in the hundreds, while most organizations are lucky to run 25 containers on a virtual machine. In the meantime, IT organizations would be well advised to look for a platform capable of managing containers wherever they happen to be found.
Best Practices
Container-based microservices are transforming application delivery. Best practices to enable this transformation include:
- Train developers how to construct microservices that will run in containers.
- Adopt a container orchestration platform to simplify management of microservices and the APIs they access.
- Implement a CI/CD platform to achieve the level of DevOps required to manage dynamic application updates.
- Be able to manage containers deployed on multiple types of platforms.
- Adopt a private cloud with hybrid/edge/multi-cloud capabilities that abstracts away the complexity of managing data pipelines built on distributed data services.
- Enable the building of stateful applications by making persistent storage available to containers.
Microservices represent nothing less than a fundamental change to the way all of IT will eventually be managed. That journey is now only just beginning. But savvy IT leaders can see far enough ahead (into what for many of them is uncharted territory) to make some critical platform choices today that will significantly reduce the bumps in the road they’ll inevitably encounter.
For more information on containerization and how containers work in distributed, scalable systems, please visit https://mesosphere.com/blog/containers-distributed-systems/
