Containerized applications are entering the enterprise data center with a different architecture and operational...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
models to create new challenges for systems administrators. As always, good communication and tools that provide visibility will make a huge difference.
Docker has made containers easy and productive for far more developers. Docker is just one way of running containers; other options include Cloud Foundry's Garden and direct access to Linux containers (LXC). The initial appeal of these technologies is around developer productivity. Containers let developers use a standard way to write code. But what happens when containers hit the production side?
VMware has already shown it wants vSphere to be the platform for production containers. What does VMware need for VMs to be more widely run in production? In particular, what will the operations teams need to adequately support containerized applications in production?
VMware addresses infrastructure needs
So far VMware has four core infrastructure parts for containers: Code Stream, Instant Clone, Project Lightwave and Project Photon. Together, Code Stream and Lightwave bring governance and authorization to the build, test, and production lifecycle for containers. These offerings will help make sure only the right code versions end up in production after the right test and authorization processes. The goal of Code Stream is to enable rapid code deployment in today's modern application development environment.
Instant Clone aids in deployment and security, allowing a one container per VM rule without overhead. Instant Clone was previously known as Project Fargo or VMFork. It allows a running VM to be used as the basis for a new VM; both disk and RAM are treated as copy-on-write so there is no overhead for starting each new VM. This addresses the container-to-container isolation issue present in many container products, without making any other change to the container platform.
Finally, Photon is a lightweight Linux distribution designed to go inside these VMs and be the host to the container. Making its own Linux distribution allowed VMware to support multiple container types, and to optimize Photon to run in a VM on vSphere. VMware has a project, codenamed Bonneville, to allow native Docker commands and APIs to drive Instant Clone. Bonneville treats an ESXi server as a Docker host and can create Docker containers using Instant Clone from normal Docker command lines. So far VMware has a few products and features that support containers.
What else will operations teams want?
The needs for VMware's customers are likely to be a little different from the needs of early adopters of containers. VMware's customers will be adding containers into an existing infrastructure for enterprise applications. These customers are also likely to have multiple containerized applications across differing security boundaries. The applications will need to share the same underlying virtualization platform. Containers will live alongside three-tier applications on the same infrastructure and mostly run inside VMs. The operations teams will be adding container support to their existing skill sets. This is very much the brownfield deployment scenario for containers.
Operations teams often need to work out what happened when something went wrong. The disposable nature of container instances makes this hard after the fact. VMware needs to find a way to link container logging into external log aggregation systems. The obvious system is its own vRealize Log Insight. Having a way for each Photon instance to forward container logs to Log Insight would help operations teams identify what happened. It is important that VMware continue to embrace giving customers the choice to use other products. If Photon has an agent to log to Log Insight, then it should also be able to be configured to log to any syslog server. In fact, Log Insight should be just another syslog server to the agent.
Another regular activity for operations teams is investigating performance issues with applications. For containerized applications, the operations teams need to see which VMs contain which container instances. The challenge is compounded by the fact that containerized applications tend to have lots of instances which might be spread over lots of VMs and possibly physical servers. Operations teams are going to need tools that correlate all the container instances across the tiers of the applications to provide a logical view of performance. Then the logical view needs to easily show the mapping back to the physical resources that ultimately limit performance. Without a logical view, it will be very hard for operations teams to identify which applications are impacted or causing issues.
Another challenging aspect of container-based applications is the deployment of updates is often automated. Operations teams may have no notification when a new version of an application is released. Since a new version of a containerized application can be a trivial change or a complete re-write, there can be large capacity and performance impacts to updates. This is where Code Stream needs to provide notification and tracking into operations tools like vRealize Operations Manager.
What's the hype around cloud app containerization all about?
App wrapping vs. containerization
How application containerization compares to Linux containers
Evolution of containerization is reaching for the cloud