Ensure container monitoring and control via smart tooling
Don't try to stick with traditional monitoring tools when your organization matures to containers; they won't do enough. Seek out monitoring and management tools with targeted capabilities.
Applications -- if you can still call them that -- are so dynamic and malleable when composed of microservices in containers on distributed resources that they hardly resemble monolithic designs. Yet, no matter the architecture, IT operations support must quickly identify and rectify any problems in production.
IT organizations tooled up for monolithic app monitoring and support are poorly equipped for microservices and container monitoring.
Container isolation and portability
For IT support professionals experienced on VMs, containers seem to be a backward step. A VM includes everything that the application needs to run: the OS, the software stack and, sometimes, even the data. With VMs' capability to package functions or services, the admin easily captures and stores known-good working systems. If a change causes problems, the admin can revert to an earlier version, maintaining functionality while the team conducts root cause analysis on the issue.
The capability to fail over to a previous container, even against a nonidentical base platform, makes containers a viable and valuable deployment method.
Containers share certain parts of the underlying OS and only include parts of the overall stack that the app function or microservice in the container requires to run. Containers need the same underlying OS as they get moved around infrastructure; VMs do not.
Containers can include enough of an environment to be highly portable yet still maintain an efficiency advantage over VMs because they do not carry around a complete OS copy. Virtuozzo's system container approach is one way to achieve this middle ground. For example, if a function requires a specific patch level of an OS, that patch level is held within the container, whereas the actual OS itself is still shared by multiple containers.
As such, it is possible to replace many VMs with an equivalent, but much more resource-efficient container. The capability to fail over to a previous container, even against a nonidentical base platform, makes containers a viable and valuable deployment method.
Container monitoring and management tools
IT organizations can keep containers healthy without failing over to previous versions thanks to advanced tooling. Container management tools are maturing and can be tied into evolving DevOps processes.
Open source Kubernetes technology -- and the many commercial variations thereof -- introduces capabilities such as container monitoring; the ability to restart ones that are misbehaving in small ways and to shut down and replace ones that are misbehaving badly; and methods to make the containers available to other containers and users in a clear and easy way. A large group of IT product vendors, including Oracle, IBM, Red Hat with OpenShift, CoreOS via Tectonic, and Canonical (particularly in conjunction with its DevOps tooling, Juju), offer Kubernetes.
Also, consider vendors such as Electric Cloud with its ElectricFlow product and CA, which, after its acquisition of Automic, has a range of tools that enable container monitoring and management with automation. Cloudify also offers strong container orchestration. For container deployments already managed with Mesosphere DC/OS and the Apache Mesos open source technology, Mesosphere Marathon is a strong option for container monitoring and control. And for Docker users, swarm mode provides capabilities through scripts and command line-based interactions.
Most public cloud platforms have container orchestration services, and here, Kubernetes is also prominent. Amazon Web Services offers Elastic Container Service and Elastic Container Service for Kubernetes, while Microsoft runs Azure Container Service and Google has its Google Kubernetes Engine.
Monitoring, analysis and remediation
For IT operations support, a container orchestration system should offer a range of capabilities:
Health monitoring: The orchestrator should enable users to check on containers to make sure that they operate within agreed policy limits. This kind of container monitoring data should be reported in an easy-to-digest form, preferably via a GUI.
Automation: Orchestrators should consistently and repeatedly provision containers against different base platforms, as required.
Remediation: Remediation is based in the capacity to stop, restart, replace or otherwise work with containers that are operating outside agreed policy limits.
Root cause analysis: Container monitoring identifies a problem -- so, where exactly is it? Container-based systems hosting microservices can be complex, so tools that quickly and effectively identify where the problem lies are in demand.
Integration into other systems: Containerization is the downstream side of a full DevOps process. Therefore, make sure that the chosen orchestration system can operate within the enterprise's DevOps tool set. An orchestrator should complete feedback loops to other systems, such as help desk/trouble ticketing and developer tools.
Housekeeping: While monitoring container health and compliance, an orchestrator should also identify zombies -- unused containers that are still live. It can either alert administrators for intervention or shut down the containers as necessary.
Containers -- alongside related trends, such as cloud computing and distributed application architectures -- change the way that organizations provision and use their IT platforms, so ensure that the orchestrator suits tomorrow's needs, as well as today's. A container monitoring and management system fit for purpose in the future will provide long-term value.
