The desire to quickly take a concept from the idea phase to the product phase has driven the adoption of cloud-native development tools. The container trend is an example of a technology that allows for fast development.

With a platform such as Docker, a developer deploys the same Docker image on their laptop to a production host. What’s the impact of containers and microservices on managing production applications? Can organizations leverage their same tools, or is a new approach required?

Microservices and containers

To understand the impact of containers, it’s important to consider a concept that’s coupled with containers–microservices, a method of developing applications into small distributed processes. A classic example of a microservice is a web server. As demand for an application rises, an application can spawn additional Apache web servers, each running in an individual container. Once demand subsides, the system resources used to spawn instances of the microservice can be released.

Containers are ephemeral. Data and system settings exist only during the life of each container’s run cycle. The ephemeral nature of containers lends itself to the microservices architecture. Each time an application needs to spawn a new microservice, a request is made to the container management system.

An application, or a system of applications, could spawn dozens or thousands of containers that could last seconds or indefinitely.

Example challenge: Monitoring

From a technology point of view, application monitoring has traditionally lived in the server silo. The server team would offer a default set of metrics and alerts for monitoring an OS instance. Over the years, monitoring teams have added the capability to monitor application services in addition to the OS environment. However, these monitoring targets were stateful. Production VMs are normally static configuration items. Traditional applications don’t spawn mini-VMs that last for seconds.

The static nature of this environment created a one-to-one or many-to-one mapping of services-to-VM. If a VM failed then, the service failed. With some certainty, the server team could alert the application team on the availability of a service based solely on the status of the VM. The microservice architecture breaks this relationship. A container’s health isn’t measured using the same metrics as a VM’s health.

DevOps to the rescue

Container monitoring is an area that illuminates the practical need for DevOps. However, DevOps is a loaded concept. In some instances, DevOps refers to tools such as Puppetand Chef and, in other instances, it’s the concept of merging development and infrastructure operations.

In a perfect world, application monitoring would be part of the application design. While data center managers can continue to report on the overall health of a container host, there needs to be a partnership between the development and operations teams on the approach to application-level monitoring.


I’d love to hear your feedback. What are some of the practical operational challenges you’ve encountered during your container adoption? Tell us in the comments.