Not running containers in production is a risk. Here’s why

Two simple questions to start your working day with:

1. How many VMs do you use in production to host your applications?
2. How many containers do you run in production?

If you do know the answer to the second question and the answer is zero…you are probably at risk. More specifically, your business will be at risk.

Wide adoption

It is probably no surprise that more and more companies are shifting their workloads from VMs to containers. Most of the started with some small scale experiments. Developers started to spin up local test environments and nowadays a lot of organizations are running containers in production without thinking of anything else.

10 times impact

Maybe you don’t run any containers because you don’t need them at all. Perhaps you are running AWS lambda code (serverless), you don’t care about containers that much. But…what if you are still stuck with VMs which should be requested and configured by a central department. Developers depend on it before they can release new versions of their applications.

What if you still treat your infrastructure as “pets” instead of “cattle”? Read on.

Whatever the reasons – if have not started yet with containers for your workloads consider the following list.

The organizational perspective

1. Developers and business managers have to learn the core differences of VMs and containers. Containers are not just a “lightweight VM” – this is a misconception.
2. Everyone in the organization should embrace CI/CD & Dev(Sec)Ops principles in which containers play a crucial role. Every CI tool supports containers nowadays – guess why? 🙂
3. Think about a container strategy. This is crucial for large organizations in which a lot of development teams work on software which relies on containers. Avoid getting a mess out of the transition from VMs to containers. Defining a good strategy takes time and energy.
4. Encourage a lot of people in the organization who are not ready (yet) to change. Change is hard and it does hurt for a lot of people who are used to “old habits”. Developers (probably) need structure to solve difficult problems.
5. Attract new and enthusiastic developers who first ignored your company because you were not innovative and thus attractive enough. Remember: human capital is and will be very important in the software industry. Time to get the smart people back on board.

The tech perspective

1. Developers and operators should adopt new deployment patterns. Containers are created and destroyed on the go – they do not live “forever”. Learn the principles of “pets versus cattle”. One big advantage: you don’t have to remember the names and IP addresses of containers as you might remember from your VMs 😉
2. Stop doing other activities since this eats up precious time – time you need to spend on your core activities: deploy reliable software with new features fast and secure.
3. Developers (remember DevOps?) should invest time to learn about container security to keep your workloads protected. Security in containerized environments is a big topic which touches various stages in the software development life-cycle.
4. Start learning the best practices of building Docker images and find ways to manage those in a meaningful way.
5. Streamline the discussion about governance of containers within the organization. Who owns what and where are the boundaries.

Swap your thoughts

The previous list  is just the tip of the iceberg. Whatever is under the surface can be (and probably will be) much bigger. It is impossible to list them all. This article already takes time to read and your business is already at risk.

So it’s time to swap your thoughts from:

Running containers in production is a risk

to

NOT running containers in production is a risk – a risk for your business!

Final words

My final words are simple: learn from those who went ahead, prioritize and get started…quick 😉 Good luck!