Member-only story
The Reason that Led to Docker Mess at Many Software Companies
Don’t Over-Engineer Docker. Use it simply.
Today, I saw a retweet by DHH (creator of Ruby on Rails and co-author of the best-selling ReWork series), which contains this image:
DHH’s comment: “This meme should be right up my alley, but Docker is to me one of the greatest simplifying technologies I’ve seen in my career. The trick is just to stop there! Docker barely needs any seasoning to be delicious (try Kamal for zero-gap deploys, it’s just Docker calls!)”.
I agree with DHH. When Docker is used simply, it can be good. Unfortunately, container technologies are often wrongly used.
A Story of My Phone Conversion with a CIO
A few years ago, I received a LinkedIn message from the CEO of a local small-medium-sized software company. This CEO, somehow heard of me and wanted me to help implement End-to-End test Automation and Continuous Testing. I accepted his connection and shared my phone number.
On the phone call, this CEO explained his eagerness to achieve “Release Early; Release Often”. He asked whether it was OK to let his CIO talk to me before the possible engagement. I agreed.
Then, the CIO called. The conversation, after a few minutes, became awkward. Because of the early talk with the CEO, I had some expectations. However, I felt this CIO was not really interested in E2E Test Automation and Continuous Testing. Then, I asked the CIO for clarification.
The CIO said, “Yes, we wanted automated E2E testing. But our current problem is that we couldn’t stabilise our deployment process to various server environments.”
I asked, “You are doing Microservices, right?”
“Yes”, the CIO answered, “So, my request for your help is Docker deployment”.
I replied, “Sorry, this is not my specialty. FYI, so far, every Docker implementation I have witnessed has been either flaky or failed. It is much simpler, easier, and cheaper to choose a monolith architecture like Ruby on Rails.”
I never heard anything back from this CEO or CIO.
