This vendor-written piece has been edited to eliminate product promotion, but readers should note it will likely favour the submitter's approach.
You built a private cloud at great expense and, despite the initial cost, real savings are being made. And even though you thought the cloud was just what your development teams wanted, they are now clamouring for containers. Why?
In common with most enterprise companies, you probably justified the investment in your cloud from an Infrastructure perspective with an emphasis on increasing utilization of physical hardware. The average utilization before virtualization was often below 10%, and virtualization as an enabler of workload consolidation has been a critical tool in ensuring that money spent on hardware is not wasted.
But – and it is a big but – typical enterprise private clouds offer little beyond cost savings and accelerated (virtual) machine delivery to the development teams who consume them. These are certainly valuable, but are rather short of the full promise of cloud.
What development teams are really looking for is a platform with APIs they can use to directly attach their automated software lifecycle tools. To quote one development lead: “I just don’t want to talk to Infrastructure.”
However, what Infrastructure typically gave them instead was just as constrained as the old physical world – with burdensome processes, limited lifecycle automation, the same old problems with patches and absolutely no tooling integration.
In short, servers were now virtual but most of the old pain points for developers still existed – and Infrastructure functions continued to be characterised as a blocker rather than an enabler of change in the development world.
What are they and why are developers using them?
To quote Wikipedia, a container is “any device … that can be used to contain, store, and transport objects or materials.” While this applies just as well to wicker baskets as software containers, the key thing for IT is how containers differ from virtual servers.
Containers enable development teams to package their software, along with resolved software dependencies, into a single artifact. Containers require a host operating system in order to run – but multiple containers can be run on a single OS instance while maintaining logical isolation from each other (no more do you need an OS license per application component instance to get that isolation).
As containers don’t each need their own OS, they can be started as fast as the wrapped application software can be started (no waiting for an OS instance to boot) and, as they include resolved software dependencies, instantiation on a server is merely a matter of copying the container over and starting it up. The repeatability and abstraction provided by containers enables developers to concentrate on delivering easily deployable and functioning software while someone else provides a managed platform for those containers to run on.
Sign up for CIO Asia eNewsletters.