It’s new, it’s hot, it’s shiny, it’s a container! Linux containers solve all of your application and infrastructure problems after all, so there’s no doubt that you want to build a container solution to solve all your company’s IT problems. Well… actually…, it’s never that simple, and in fact for many enterprises, containers are a solution that will require a massive overhaul of the entire application development environment. If your company is prepared to make that journey, then the benefits will pay dividends on the efforts required to move to the latest technology to cause a radical shift in the IT space.
Containers as a technology are by no means new. Click To TweetContainers – Old Technology, New Life
Containers as a technology are by no means new. Coming out of the resource sharing and time division computing models of the 1970s which have continued to exist in the mainframe technologies derived from those initial services. The mini-computer era saw containers as well, and that technology model, though by no means the same exact solution, was evident in the Unix class systems from Sun, HP, IBM, and others in the 80s and 90s. The Linux world added the support that created the current container revolution over the past 10+ years, but it was not until the release of the Docker container management specification that the world really took notice.
Why did containers adoption lag until the Docker iteration?
So what made Docker’s new take on containers so compelling? Perhaps it was simply that the timing was right; development pipelines were suddenly API enabled, leveraging the new infrastructure as a service offerings as just another thing to manage with software. Adding in deployment process automation allowed developers to add the normal operations processes to their environments by treating the entire solution as a development process, the world of Infrastructure-as-Code. While the Virtual machine model is a reasonable and reasonably efficient model for this sort of infrastructure, the idea of a container handling just the parts of code that actually change is quite compelling for the developer.
Containers were hard to use
There were issues with this model. The general concept of a container is fairly straight forward, bundle together the minimum required code for your application, any required libraries, and perhaps other applications (such as a web server or a middleware engine, even a database), but leave out the rest of the operating system, and run that in a restricted space on top of a normal operating system, with the right extensions of course. This model and the development in the Linux space came early for at least one large corporation, namely Google, and their involvement early on in the Linux development worked for them given their constant focus around efficiency at scale. Other were not so lucky to have the power of a Google behind them, and yet still found ways to make the model of the container work, even though the management and creation of a container was by no means simple, or even really efficient. The tooling was just not there for widespread adoption.
Demand for container-like services grew with IaaS & PaaS
As the Infrastructure-as-a-Service (IaaS) space grew, so too did the interest and even demand for container-based development approaches. The first shifts in this space that moved the needle forward was the advent of the Platform-as-a-Service (PaaS) model. Development, specifically of dynamic web service projects, had been moving to a set of framework-based environments, where one would develop either plugins for a running service such as a WordPress or Drupal content management system, or for the more complex systems tools like the Ruby on Rails framework further shifted the focus. The shift was from building the “full web stack” to focusing on the application control logic and perhaps the front-end web interface as two different but interconnected code bases. These developers were not interested in operating the underlying infrastructure needed to deploy their tools, given that it was fairly consistent, and you could effectively bundle your application (and front-end software) into one solution.
Some of the Developer/Operator engineers realized that they could perhaps separate the areas of concern, and provide a platform on which a developer could just divine their actual production code, and describe the dependencies (such as a database model, and specific services libraries), and a service could then deploy the application code itself on top of the rest of the underlying operating pieces (such as a Linux operating system, and the back-end storage and database services that were “consistent” between these sorts of applications). The engine that enabled this tooling, and provided the ability to provide resource constraints and management to the application components themselves was the Linux container capability, abstracted from the developer, and composed and managed by the Platform service.
PaaS – Containers find a Home
With containers finding a home in the PaaS space, it was only natural for more folks to look at containers management more directly. And the complexities of doing so led to the development of Docker, with dramatic effect. In previous generations, creating a container included using chroot environments, and complex command line options that limited the users who were able to easily create a container, let alone run one. In addition, the inability to simply run a container on an OS-X or Windows-based laptop further limited the scope of the software engineers who were able to validate their environments as they had been doing in the IaaS VM-based development space.
Docker makes containers easy
The shift to Docker-based containers changed this dramatically, firstly because the process for creating a container became dramatically easier, using a simple composition language, in a sense an extension to the simple requirements files used with other PaaS like offerings, this solution provided a quick and easy way to create a custom container from scratch. In addition, a layering model made it even simpler to start with someone else’s base container, and just add the specific elements needed for one’s own application. While the simple deploy to your local laptop solution hadn’t yet been achieved (though there is now a beta of this exact functionality with Docker), the composability meant that it was simple enough to launch a container in a VM on your laptop, and that was close enough to production equivalent, in fact, this mirrored how most containers were being deployed for production, that the development model was now simple enough. The toolchain was finally available to provide a “container-as-software” solution.
In the journey so far, we’ve seen that containers are now a viable development model, and can fit into the Infrastructure-as-Code model for deploying an application. But it’s not yet clear what the implications are for an Enterprise. In the next installment, we’ll investigate Enterprise application development, including the concepts of microservices and service-oriented architectures to see how we enable container-based development for different enterprises at different points in their software development life cycles.
Part 2 Containers and Application Development (Microservice connection)
Part 3 Benefits of Containers for Enterprise Users