Tag Archive for containers

Containers Continue on Track for 2019: 3 Key Trends For the Maturing Container Ecosystem

This blog appeared first at the Amalgam Insights blog.

The past few years have been exciting ones for containers. All types of tools are available and a defined deployment pipeline has begun to emerge. Kubernetes and Docker have come to dominate the core technology. That, in turn, has brought the type of stability that allows for wide scale deployments. The container ecosystem has exploded with lots of new software components that help maintain, manage, and operate container networks. Capabilities such as logging, load balancing, networking, and security that were previously the domain of system-wide software and appliances are now being brought into the individual application as components in the container cluster.

Open Source has played a big part in this process. The Cloud Native Computing Foundation, or CNCF, has projects for all things container. More are added every day. That is in addition to the many other open source projects that support container architectures. The ecosystem just keeps growing.

Where do we go from here, at least through 2019? Pretty much on the same path. 2019 will be a year for rounding out and growing container technology to make it more palatable to large enterprise applications. With the basic technology done, the work to make container networks secure, resilient, and manageable will be the primary focus for containers.

That doesn’t mean there won’t be new and exciting technology added to the container ecosystem. Serverless computing, which has been built on containers, will now itself be turned into a container technology. The KNative project to create serverless computing in a Kubernetes cluster is an example of interesting development that needs to be tracked over the coming year. For many developers, having to deploy container clusters is, in of itself, too much work. They would prefer a new level of abstraction that allows them to ignore all the workings of the cluster and just write code. KNative might just do that.

Another area to watch will be hardening containers. While the capacity utilization of containers is better than virtual machines, they also less safe than VMs. Inhibiting the ability of code running in a container to access the host operating system is an interesting way to make containers more secure.

Finally, the emergence of service meshes for containers is an important development for containers and microservices. Services meshes are set of network services controlled by a central controller accessible from the container cluster. This offers the possibility for much more flexible clusters that can access centralized services that compliment the internal components of the system. Service meshes help provide a balance between centralized and localized services.

2019 is not going to be “exciting” for containers in the sense of blockbuster new technology. Instead, this is the year when the container ecosystem grows up, filling holes in container architectures. The refinement of the container ecosystem is critical to long term health in the space. It won’t be exciting but it also won’t be boring.

Monitoring Containers: Do you know what happening inside your cluster?

container with a spherical object in it

This was originally published on May 18th on the Amalgam Insights. For reasons I can’t fathom, I forgot to push the publish button.

 

It’s not news that there is a lot of buzz around containers. As companies begin to widely deploy microservices architectures, containers are the obvious choice with which to implement them. As companies deploy container clusters into production, however, an issue has to be dealt with immediately:
container architectures have a lot of moving parts. The whole point of microservices is to break apart monolithic components into smaller services. This means that what was once a big process running on a resource rich server is now multiple processes spread across one or many servers. On top of the architecture change, a container cluster usually encompasses a variety of containers that are not application code. These include security, load balancing, network management, web servers, etc. Entire frameworks, such as NGINX Unit 1.0, may be deployed as infrastructure for the cluster. Services that used to be centralized in a network are now incorporated into the application itself as part of the container network.

Because an “application” is now really a collection of smaller services running in a virtual network, there’s a lot more that can go wrong. The more containers, the more opportunities for misbehaving components. For example:

  • Network issues. No matter how the network is actually implemented, there are opportunities for typical network problems to emerge including deadlocked communication and slow connections. Instead of these being part of monolithic network appliances, they are distributed throughout a number of local container clusters.
  • Apps that are slow and make everything else slower. Poor performance of a critical component in the cluster can drag down overall performance. With microservices, the entire app can be waiting on a service that is not responding quickly.
  • Containers that are dying and respawning. A container can crash which may cause an orchestrator such as Kubernetes to respawn the container. A badly behaving container may do this multiple times.

These are just a few examples of the types of problems that a container cluster can have that negatively affect a production system. None of these are new to applications in general. Applications and service can fail, lock up, or slow down in other architectures. There are just a lot more parts in a container cluster creating more opportunities for problems to occur. In addition, typical application monitoring tools aren’t necessarily designed for container clusters. There are events that traditional application monitoring will miss especially issues with containers and Kubernetes themselves.

To combat these issues, a generation of products and open source projects are emerging that are retrofit or purpose built for container clusters. In come cases, app monitoring has been extended to include containers (New Relic comes to mind). New companies, such as LightStep, have also entered the market for application monitoring but with containers in mind from the onset. Just as exciting are the open source projects that are gaining steam. Prometheus (for application monitoring), OpenTracing (network tracing), and Jaeger (transaction tracing), are some of the open source projects that are help gather data about the functioning of a cluster.

What makes these projects and products interesting is that they place monitoring components in the clusters, close to the applications components, and take advantage of container and Kubernetes APIs. This helps sysops to have a more complete view of all the parts and interactions of the container cluster. Information that is unique to containers and Kubernetes are available alongside traditional application and network monitoring data.

As IT departments start to roll scalable container clusters into production, knowing what is happening within is essential. Thankfully, the ecosystem for monitoring is evolving quickly, driven equally but companies and open source communities.