Achieving Continuous Improvement Through Containers

Wercker is a Docker-Native CI/CD Automation platform for Kubernetes & Microservice Deployments

Brien Posey
Brien Posey
July 27, 2017

When implementing a container environment, one of the worst things you can do is to complete the implementation and call it done. After all, few things in the world of IT can truly be managed with a “set-it-and-forget-it” mindset. There is always room for further improvement and optimization.

That’s why organizations that build and maintain a container environment should always be on the lookout for ways to make it better. 

Of course, the question you then ask is: How can I realistically go about continuously improving containers? After all, the concept of continuous improvement sounds nice, but considerations such as budget and the container environment’s stability cannot be ignored either.

Well, if you’re wondering how to implement continuous improvement for containerized environments, this article is for you.

 

Focus on the Small Things

The key in continuously improving your containerized environment is to focus on making small but meaningful changes. Large changes tend to be disruptive, and are usually expensive to implement. Although large changes are sometimes necessary as a part of IT modernization, continuous improvement efforts should be based around small changes.

 

Research, Research, Research

At the same time, it is important to avoid falling into the trap of making continuous changes simply for the sake of making changes. Continuous improvement isn’t only about implementing changes. It is also about doing research into ways of improving the containerized environment. Solid research not only helps with finding ways to improve the container environment—It can also help you to avoid implementing changes that would have an undesirable effect.

 

What Constitutes an Improvement?

Another key in achieving continuous improvement is to clearly define what constitutes an improvement. Even though the thought of defining something that seems so obvious might sound ridiculous, setting objectives up front can help you to focus your efforts.

Every organization is likely to have a slightly different definition of what constitutes an improvement to its container system, but here are some questions to consider while defining your objectives:

 

  • What are the current container operating costs? Is there a way to reduce those costs?
  • What level of performance am I seeing from containerized applications? Is there a way to make the applications perform even better?
  • How much time is being spent on container management? Are there management tasks that can be automated?
  • What tools are being used for container administration? Are better tools available?
  • How quickly can changes be made if the business’ needs change? Is there a way to make the whole environment more dynamic?
  • What workloads are running in containers, and what workloads are running in VMs? Would any of those workloads (including the ones that are already containerized) benefit from being moved to the other environment?
  • How efficient is the container environment as a whole? Is there a way to make it more efficient?
  • How well does the containerized environment meet the business’ objectives? Are there things that can be done with containerized workloads to help the business to better accomplish its goals (not just IT goals, but business goals)?

 

Involve the Stakeholders

As you work to come up with ways to continuously improve your container environment, you should keep in mind that ideas can come from a variety of sources. One of the best sources is the people who actually use containerized workloads or manage the container infrastructure.

Stakeholders will likely have plenty of ideas about ways that the containers can be improved. After all, they are the ones who work with the system day in, and day out. Application users might, for example, know about a performance bottleneck that IT would not easily spot on its own. A line of business manager might have an idea for making two containerized applications work together to deliver a greater benefit than the applications are able to provide by themselves. The point is that inspiration is everywhere. You just have to be open to receiving it.

 

Be Able to Prove that Improvement Has Happened

As previously noted, change is not the same thing as improvement. Some changes are good; others are bad. Several years ago, for example, a friend deleted a number of critical operating system files in an effort to free up hard disk space on his PC. The changes that he made to his PC were focused, and had a well-defined objective, but certainly did not improve his situation.

When continuous improvement is your goal, you must have a reliable way of determining whether a change produces the desired outcome. For this, you should collect relevant metrics both before and after making the change. (It’s also important to have a way of rolling back a change that does not deliver the desired effect.) Such metrics not only validate the impact of the change, they can also help you to justify the change in the event that someone complains later on.

 

About the Author

Brien Posey is a Microsoft MVP with over two decades of IT experience. Prior to becoming a freelance tech author, Posey was CIO for a national chain of hospitals and healthcare facilities. He also served as a network engineer for the United States Department of Defense at Fort Knox, and has worked as a network administrator for some of the largest insurance companies in America. In addition to Posey’s continued work in IT, he is in his third year of training as a commercial scientist-astronaut candidate.

 

Like Wercker?

We’re hiring! Check out the careers page for open positions in Amsterdam, London and San Francisco.

As usual, if you want to stay in the loop follow us on twitter @wercker or hop on our public slack channel. If it’s your first time using Wercker, be sure to tweet out your #greenbuilds, and we’ll send you some swag! 

Topics: Tutorials