APM Using Containers to Optimize the End User Experience
April 20, 2018

Brien Posey
Fixate IO

When people talk about the benefits of containers, they tend to focus on how containers make life easier for developers. Yet developers are not the only group impacted by containers. Ultimately, the end users who run containerized applications need to be happy, too, in order for containers to be a success.

With this reality in mind, it can be helpful to consider ways in which using containers can help users to have an all-around better experience, then orient containerized development practices toward that goal.

Take Advantage of Code Portability

The idea of taking advantage of code portability might be better expressed as taking the leap (if you haven’t done so already) and running containers in production. Even today, there are organizations in which the development staff uses containers, even though containers are not used in production.

For developers, the use of containers makes perfect sense. Containers make it simple to set up environments for testing code. Developers don’t have to waste time creating and configuring virtual machines, and can instead focus on writing code.

The problem is that if an organization does not use containers in production, then code that was developed as a containerized application may eventually be run in a virtual machine. While there is nothing wrong with running code inside of a VM, there is no guarantee that the code will behave the same way that it did in the development environment.

Because developers put so much effort into testing their code, it makes sense to take advantage of container portability. This guarantees that the new bugs won’t be introduced, simply because the code is now running in a new environment. That, of course, makes applications more reliable, which is good for the end user.

Avoid Patch Management Hell

The days of an application being created and remaining unchanged in perpetuity are long gone. Today, it is a given that applications will be repeatedly patched throughout their lives. Although developers may view patching as an opportunity to make applications better, patch management can be a source of extreme annoyance to end users. After all, we have all seen examples of operating systems that constantly demand that the user stop what they are doing, and wait for an update to be installed. Never mind the reboots that always seem to occur at the most inopportune moments.

Of course, the concept of disruptive application updates is most commonly associated with applications that are installed locally on the user’s device, but updates for remote apps can be just as impactful. Just this morning, for example, I attempted to use a web application only to find that my browser was not displaying the application interface correctly, because of some updates that were taking place on the backend.

Making the transition to containerized applications will not mitigate the need for application updates. Code will probably always need to be maintained. However, for the end user, containers will reduce the duration of the update process to as little as a few seconds. Hence, some updates may go completely unnoticed.

Dynamic Scalability and High Availability

When it comes to running applications, the bottom line is that users expect their applications to be fast, responsive, and ready to use when they are needed. When properly implemented, containers can deliver on all of these.

One of the most effective ways in which admins can ensure the performance and availability of their applications is to create multiple instances of each Docker image, and then use a load balancer to evenly distribute traffic among the available instances.

Yet, the big challenge in providing workload scalability in this way is determining how many instances are actually needed. Some organizations have addressed this problem by writing elaborate scripts that create and destroy container instances in response to changing workload conditions. A better solution may be to use a third-party container monitoring tool.

If the goal is to ensure a good end user experience, then simply using a script to monitor a few key metrics might not be enough. Such a script would likely be able to detect an outage, or a serious performance problem, but a well-written monitoring tool is capable of looking at the end user experience as a whole. Such tools may also detect and help remediate subtle conditions that need to be addressed before they become a problem. The end result is a better, and more reliable end user experience.

Brien Posey is a Fixate IO contributor, a freelance technical writer and a 15-time Microsoft MVP
Share this