One of the frustrations of DevOps organizations considering public cloud or hybrid cloud services is the fact that...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
different hosting environments and cloud providers often have different application requirements. That means that creating cloud application instances can involve multiple instances per application or changes to both deployment scripts and machine images to reflect different hosting needs. Can containers solve this portable cloud problem? To find out, understand how containers are different from VMs in a portability sense; ensure container deployment realizes your goals in portability; and consider whether a more managed VM and machine image model would provide as good, or better, portability support.
The most important thing to recognize about container technologies -- like Docker -- and virtual machine or Infrastructure as a Service (IaaS) technology is that the primary benefit of containers is not portability. Containers significantly reduce the resource requirements per component, which means you can get more application components onto a given server using containers than using VMs. The cloud portability benefits of containers are created as a byproduct of how containers work, not as the goal.
In VM applications and IaaS clouds, machine images include everything an application would find in a host, including the OS, middleware and virtual versions of the devices. In container applications, the host OS and some middleware are shared, and applications have their own copies of application-specific resources (in Linux, that includes five namespaces -- Process, Network, Mount, Hostname and Shared Memory). Applications designed for containers are forced to be compatible in versions of most elements just to share a container. That tighter platform software version control is one factor in portable cloud.
A container management system like Docker is the other. Docker can deploy applications in containers on any suitable platform, where IaaS clouds and virtualization stacks for data centers will normally have their own incompatible management systems. The common management framework for containers makes it easier to host them in multiple clouds and in data centers and move applications among all the options, something that can benefit an organization moving toward DevOps.
If the combination of tight software version control and compatible deployment management are the things that let containers contribute to application portability, it follows that your container plans have to preserve these capabilities if cloud portability is your goal. There are several critical steps to that preservation.
The first is you need to adopt a single container management strategy. Docker is the most popular container architecture, but there are other options like Canonical's LXD. Container portability depends on using the same container architecture throughout your clouds and data centers, and that means you'll need to ensure you have a single container strategy that works on all your hosting options before you start. That's what makes Docker -- the most widely used container system -- the logical choice for those who want portable cloud.
The second step is to employ additional container tools to standardize deployment. Nearly all large-scale Docker deployments use Kubernetes for management and container communications, but look at Shipyard as well. If you're a user of DevOps tools, you'll want to ensure your package supports container deployment and use the modular resource-related (Infrastructure-as-Code) capabilities of DevOps to create environment-independent deployment into containers. Docker Compose will work for pure-container deployments, but most users won't get to that point quickly.
The third step is to systematize container security and standardize the mechanism across all your environments. Containers are not as secure as VMs. If you're going to deploy containers in the public cloud, consider using dedicated servers or VMs to host your container system, rather than using a public container offering if you have security concerns. Docker now has its own Docker Content Trust mechanism, and there are a number of third-party security tools, including some based on blockchain technology, to add security. Be consistent in your application of these tools if you want cloud portability.
The fourth step is to centralize logs in a portable way. It's easy to lose track of logs in container systems, and easier if you deploy across multiple clouds and data centers. Tools like LogSpout can at least pull the logs together and organize your view of what's going on.
Finally, use a tool like Flocker to manage databases and volumes. Portability of containers can create massive inefficiencies in database usage and placement, and making portability easier invites creating more problems. In some cases, you may want to use containers to host database query services as microservices to centralize how databases are accessed, but beware of creating too many network hops and introducing too much delay in response time.
Many IT professionals will recognize that applying all these disciplines to containers to achieve portability isn't too far from applying the same discipline to VMs. Could you simply structure your VM or IaaS choices and machine images to secure portability and use DevOps tools to standardize the deployment process? Yes, but ...
Version control and deployment discipline will improve machine image portability in IaaS or VM deployments, but the underlying issues of hosting efficiency remain, and unlike container systems, there's no direct penalty to letting your platform software version control discipline go soft. You may discover a problem only when you try to cloudburst or fail over to another platform.
Most enterprise cloud users will find containers a positive step toward creating truly portable applications for the cloud. If you combine containers with strong DevOps practices and use Infrastructure-as-Code principles in defining and configuring cloud resources, you can make container apps very transparent to hosting locations, and make your cloud applications more resilient, more responsive and less expensive to sustain.
Cloud developers learn to love containers
This just in: Docker persistent storage a new option for containers
Is Docker trying too hard? Some think so