A senior executive of one of the world's largest commercial software companies told me they use software containers in their development process to increase agility and bring new products and updates to market more quickly. Their development cycle is now months instead of years.
A software container is simply a very thin package of an application and all the libraries that support the application, which makes it easy to move the application from one operating system to another. A developer can build an entire application and then use a tool to take all the source code and supporting files and basically create something like a zip file so the container can be deployed just about anywhere. It contains everything the application needs to run, including code, runtime, system tools and system libraries.
Unlike a virtual machine that has the whole operating system beneath it in a package, a container is just the application. Containers are smaller, thinner and typically more portable than VMs because you can run them on top of any hypervisor as long as you have the proper host OS running above that hypervisor.
The most popular container technology is Docker.Basedon open standards, Docker containers can run on all major Linux distributions and Microsoft operating systems with support for every infrastructure. They have become very mainstream because of the beneficial impact on organizations to quickly deploy new applications.
Containers are awesome but they have drawbacks. There are some security risks that go along with this new development idea.
For one thing, containers don't keep themselves up to date. There's no mechanism to make sure the components within the container are staying up to date and and addressing security vulnerabilities. For example, it's easy to create a container with a particular version of Java and then deploy the container. Weeks later, when a new release of Java comes out to fix a flaw in the previous version, there's really no easy way to know how many of those out-of-date containers are out there, and no way to simply install an update to the container. Furthermore, unlike VMs, containers typically don’t include anti-malware, IDS/IPS, and other security agents, which puts them at risk of attack.
A development philosophy for containers is to split up applications into micro services. Whereas a traditional application might be divided into, say, three tiers for a web app, the container approach splits the application into many more small containerized components. That three tiered web app might end up with 20 or 30 containers. Having this many entities further complicates the management task of tracking, securing and updating/replacing the containers.
Another complication is that Docker has an all-or-nothing administration model, which makes it difficult to restrict administrative privileges to just those tasks that a person or team needs to perform. This model can be a challenge for companies that want to separate administrative access across different teams, like developers and testers. It's difficult to securely delegate access to just the right level of people throughout the environment.
Sign up for CIO Asia eNewsletters.