carloscastilla - Fotolia
For enterprises looking beyond virtualization, and even many looking for an ideal public cloud application strategy, containers have exploded in popularity. They have lower overhead than virtual machines, are often faster and easier to deploy, and normally allow you to run more applications per server. Containers seem a perfect development target, but they have security and compliance problems and pose quality of experience and availability risks that developers have to address. This tip explores these pain points of using containers in a cloud development environment and when developers can and can't relieve them.
Developers should view containers as something between multiprogramming, multiuser portioning and virtual machines. So they must inventory the things that containers will manage to isolate components of applications, understand the role of container management tools like Docker, and address the specific issues of container development for each OS and container management combination needed.
Containers, like VMs, can hold application components and allow servers to share multiple components or even component instances. They share basic operating systems services and, in some cases, even some middleware services. They manage elements like visibility and naming to minimize interactions.
Since containers are "above" traditional virtualization technologies used in cloud computing, a container is essentially portable across multiple clouds, whether public or private, and in any combination. Since the OS is shared, containers have low overhead and can be used to subdivide infrastructure as a service or VM instances to take full advantage of this portability. It's likely that most developers of container-exploiting applications will be targeting this portability mission as the prime benefit.
Just how containers work will depend on two factors -- the operating system that's hosting them and the management platform that deploys them. Although there are other container management systems for Linux and other operating systems, the most common platform is Linux and Docker. The first task for a developer is to identify the environments in which container applications are expected to run and ensure that the management tools and middleware selected are compatible with all the targets. Popular container management systems will accommodate differences in the software platform where the containers run, but not all such systems will address all the issues.
The general approach taken by container implementations is to designate resource assignment, isolate the operating system container system and manage the relationship between the contents of the container and the OS and resources through a container management system. In Linux, for example, the user information, file systems, name and process spaces, and networking are managed by both the OS and a container management system such as Docker. Containers can be deployed without management tools, but they radically simplify things like version control of middleware tools and network connectivity. This means container tool choices will need to be carefully evaluated, either before you start development or during early application planning.
Users with successful container projects suggest that anyone building container applications should strongly consider committing to containers to host their development. The experience gained in setting up and maintaining container development will be helpful in building container-based applications. You can also test out application lifecycle management practices and portability of instances using the development containers, reducing the risks of testing practices on real applications.
Open source and system software and tools are often loaded from a central library, which contains the supported software. There are other sources of container base images, but developers need to be mindful that the images they select are still supported by the current version of their OS and container management system. This level of version control is critical for container-based applications so be sure to test any changes in base image versions. Testing will depend on the combination of OS and container management system. Although using a common container management tool for all your deployments can potentially be limiting in your host server or what applications can be run, it will be more efficient overall. Containers and their contents are transient, and the biggest mistake new container developers will probably make is not accounting for this in application design. All container applications should be viewed as a collection of microservices that are both stateless and have no persistent data store within the application. You'll need to provide state control and data persistence with out-of-component tools. It's smart to use data-driven, back-end state control to be consistent with outboard database recording of persistent component data. Be sure to record any dependencies on these tools because if you port applications to another cloud development environment, you'll need to port, or provide access to, the tools as well.
A final consideration is the networking and workflow integration of containerized applications. Public clouds will require special considerations as they complicate "private IP" use. Tools such as Docker set up networks and presume component integration strategies. Developers will need to take both these activities from where the tools leave off and where your applications need to be.
Since containers are increasingly popular with users, it's more likely that direct container hosting options will be available from suppliers suitable for your cloud or container goals. These may require specific container management tools, or even be based on the cloud development environment. Containers and VMs are also converging in a tool sense. You'll want to track not only the tools you use, but the whole container space as you develop applications to ensure better options aren't presenting themselves and that your applications are flexible enough to accommodate the trends in container technology. Containers are almost surely part of your application future so use them well.
Are containers right for my IT environment?
How does container fit in the cloud picture?
Why use Docker when VMs do the job?