What's This?

Why are developers the ones driving the increasing use of containers?

The obvious answer would be that containers make their jobs easier, and we’ll talk about why that’s true. But containers also make application development more consistent and life easier for the operations group that has to run and maintain the applications.

We’ve seen many small container pilot projects growing up within lines of business. Many that have delivered great results have been replicated and are beginning to grow rapidly.

What Containers Contain

The easiest way to define containers is to focus on what they contain. In today’s common usage, they contain an application -- or more frequently a microservice that contributes to a larger application assembly -- along with all of the components, libraries, and other associated packages required to run the application, including complete specifications for the storage required by the application. While containers include the kernel of the operating system their application is running on, the application runs in a completely isolated environment with a layer of abstraction between it and the underlying operating system.

Perhaps the most important impact is the enablement of true portability, an absolute necessity for operations in the cloud. From the developer’s standpoint, the biggest benefit is being able to deliver an application that will run properly no matter what else has been done to modify or enhance the environment it runs in.

Operations will find a reduction of problems because the failure of any individual container will not result in catastrophic application failure.  Instead, failure results in another instantiation of the container that will replace the failed one and perform its required functions. This resilience is a big part of the driver behind the adoption of containers. Operations also will not have to worry about providing the right storage for each application, since that is specified within the container itself.

Storage Implications

There are several reasons why software-defined storage has been the preferred strategy for providing persistent storage for containers. Essentially, any kind of stateful app that needs a persistent storage layer with data integrity and active properties is a good fit for containers.

For instance, a large number of the applications being developed using containers and software-defined storage involve NoSQL and NewSQL databases (e.g. MongoDB). These databases need to be integrated, consolidated, and/or scaled, which is far more easily accomplished using containers and often occurs between disparate cloud platforms and storage technologies.

Another reason to prefer these technologies is because they facilitate the achievement of true hyperconvergence, resulting in significant economies of scale produced by having a single control plane, all storage, and all application containers running on the same box.

Additional value is produced by making the best possible use of unused capacity in existing devices rather than adding new ones. Software-defined storage removes the software intelligence that runs the disk controller and other components of a storage solution from a proprietary box, running it instead on inexpensive standard servers. Less expensive storage hardware can now be used, and far greater flexibility is available since the software is literally no longer “married” to the hardware.

The result is increased utilization at lower cost with a single control plane producing increased efficiency. Now who doesn’t like that?