read-more-arr slider-arr-left

7 ways to burn money as a developer - Part3: Docker

Intro

After many years of suffering in software development organisations, I felt it is time to talk about our inefficiencies.

This series is about how we make decisions that end up costly for the companies we work for.

If you missed the first part of this series in which I talk about trends, find and discuss it here.
In the second part I ranted about microservices.

Today we will take a look at Docker and Kubernetes.

Please find all the other parts here!:

Part 4 – Kafka
Part 5 – Low abstraction technologies like Go & Typescript
Part 6 – Using Slack for Monitoring
Part 7 – Cross-Team Collaboration

Part 3: Docker + Kubernetes

When Docker caught my attention ten years ago, I was working for Axel Springer. I was technologically responsible for the Paywall Systems of Bild and Welt, and inherited the platform which consisted of several services built by two different companies.
The stack was the same, high level (Java and Spring), but they had chosen very diverse patterns to configure their applications, and used different runtime environments (JVM, Servlet Container/Application Server).
Also they used different deployment mechanisms.
In an attempt to homogenise how we deploy and manage the services, I decided to wrap them all in docker containers and to re-implement the deployment and orchestration to docker.
Roughly at the same time, we migrated the first services to Spring Boot.
If you do not know it, it is a very high abstraction technology, in which you can bundle your application with the runtime environment in a single file.

 

It so happened, that at the time we were done containerizing our environment, one of my engineers was also done migrating all services to Spring Boot.
When I looked back and reflected I saw we had wrapped one container into another without any added value, burning a lot of money.

 

 

Docker for sure has its use-cases and I use it regularly. Mostly in development environments and automated testing/ci.
Especially very diverse environments with different applications (this is what deployables should be, not application modules, see part 2 of this series).
But they also come at a price. This price is added complexity. And you should be absolutely sure you need it before you go this way.

Back at that time, btw, it was not clear how we would orchestrate our containers. Kubernetes was in very early stages, very unreliable.
We experimented with CoreOS, the underlying operating system and it was working. Having to resolve partition problems and such was not fun, however.

We also quickly came to concerns about patchlevel of the container operating systems and other problems that result from the os-in-os-approach.

Of course, today Kubernetes is an established technology and can be run and maintained in a reliable fashion.
Nevertheless, the added complexity of buying into containers and container orchestration is still massive and you should have good reasons to bring it on.

 

Later in my career I realized that most companies utilizing Docker and Kubernetes suffer from Problems they should not suffer from.
Engineers are busy with understanding the whole infrastructure tooling instead of focusing on solving business problems.
Infrastructure bills exceeding any reasonable levels.

It seems that often, Kubernetes (such as Microservices, check my previous post) are not a tool to enable scaling of engineering organizations but the reason for scaling needs.

Operating the complex distributed system and all the moving parts with all these advanced and complicated technologies (providing a lot of things that most people do not need or use rightly) is overwhelming for most organizations and team.
The result is that engineers are busy with keeping afloat instead of delivering value. The response to this is usually: more people.
Sometimes tenfold of what would be needed if the technology choices were more pragmatic and appropriate.

 

 

If you bought into Docker Containers and Kubernetes without having a strong scenario for it, chances are your payroll and infrastructure spendings are way too high while you and your fellow engineers are busy with stuff you should not waste time on.

How do you feel about Docker and Kubernetes? Do you also love Docker but find the efforts of running and operating Docker+Kubernetes in production is too high and the cloud bill is not benefiting either?

 

 

I’m looking forward to reading your comments.

If you liked this part, also read and discuss the others:

Part 1 – Trends
Part 2 – Microservices
Part 4 – Kafka
Part 5 – Low abstraction technologies like Go & Typescript
Part 6 – Using Slack for Monitoring
Part 7 – Cross-Team Collaboration

About the author

Henning Groß

Henning is co-founder of Zeile7. He has built companies like Element Insurance and Upday before and holds two decades of experience in the tech industry. He held interim Chief technical and lead engineering roles at multinational media giants Bertelsmann, AxelSpringer and other global knowns.

Henning is co-founder of Zeile7. He has built companies like Element Insurance and Upday before and holds two decades of experience in the tech industry. He held interim Chief technical and lead engineering roles at multinational media giants Bertelsmann, AxelSpringer and other global knowns.

Culture – New Work Order
Don’t Ask For Permission

Let us advise you personally

Daniel Bunge Account Executive Marketing + Sales
Make an appointment
Meet the team

By loading the calendar, you accept Google's privacy policy.
Learn more

Load calendar