Why Do Many Highly Hyped Technologies/Processes, e.g. Docker, Fail?
The thoughts and conversations with my daughter after watching the funny Hilter uses Docker” videos.
Today, my daughter showed me a funny YouTube video, “Hilter uses Docker” (a movie clip with substituted subtitles). Quite Funny!
It seems that more and more people finally had the courage to admit that using Microservices (typically with Docker Containers) is a mistake for most software projects, which I predicted years ago.
For readers who want to argue or debate, read the above case study findings or have a think. Hints: Amazon, the company would brace Microservices. I believe that Microservices or Docker can be implemented well, just so easily went wrong. Every software project I witnessed with Microservices, did not do well. It is cheaper, safer, faster to choose a good Monolith architecture, such as Ruby on Rails. Github and Airbnb are powered by Ruby on Rails, so don’t believe rumors by wrong people. After all, “Ruby on Rails is the most in-demand skill”, Analysis of Hired’s 2023 State of Software Engineers Report.
Every technology or methodology exists for a reason, such as:
Waterfall and RUP in the software process
SOAP, EJB in software architecture
Angular.JS in coding
XML Schema in data change
HP QuickTest Pro, IBM Rational Functional Tester and Microsoft Coded UI commercial E2E test automation tools
An interesting read , “What are the best UI Test Automation Tools?”, by Test Community At Microsoft (2019–03). This article reviewed the popular UI automation frameworks/tools, listing Pros/Cons, including its own Coded UI. However, in the same year, Microsoft dumped the Coded UI.
Anyway, that’s why prefer not writing review-type articles with pros/cons. I go with direct suggestions. E2E test automation is practical, quick, results-driven, and the target existed for 20+ years unchanged (for web testing).
Many fake senior engineers treat it as research, wrong! A real test automation engineer can implement undebatable working E2E (via UI) testing in a matter of days. Check out my article, “How do I Start Test Automation on Day 1 of Onboarding a Software Project?”, and my daughter’s “Set up, Develop Automated UI tests and Run them in a CT server on your First day at work”.
ProtractorJS, Cucumber/Gherkin in E2E test automation
Their failures do not necessarily mean 100% failure for every software project. Today, some high-quality old software developed using the Waterfall methodology is still in use. So, don’t evilize one particular technology.
Those technologies fail because they are unsuitable for most software projects run by average people (here, average is a neutral word). For example, between 2000–2010, in nearly every software project I witnessed, software architects/engineers misused XML Schema. I could use XML Schema well, and so-called enterprise data architects came to ask me questions. Why? I worked as a research scientist at the W3C Australia Office for three years. Is XML Schema bad? No, it depends on who uses it. However, XML schema is complex and easily got wrong, and unsuitable for general use.
Docker (or container architecture) fits in this not-suitable-for-general-use category. Again, it might work for some companies by some top-notch engineers, but for most, it is usually a recipe for disaster. Remind you, at least Amazon software architects in one team made mistakes in going for Microservices, which cost 10X more, compared to using Monolith. From my experience, so-called software architects tend to overestimate their capabilities. Check out JOEL ON SOFTWARE’s article on “Architecture Astronauts”.
Some readers might think, “Zhimin, it is easy for you to say so now. You probably sang for Docker 3 years ago like most of us”. NO, I predicted the failure of the Docker container. As long-time readers know my style, I will provide proof:
Check out my article, Monolith ✅ vs Microservices ❌, a New Perspective
All my apps, including ClinicWise, SiteWise, SupportWise, BuildWise, WhenWise and TestWisely, are based on Monolith architecture. This shall be dame convincing.
One main reason I write this blog is for my daughter. Surely, I won’t risk a father’s pride by telling lies here.
My daughter had a University course on container architecture last year. I told her Container/Microservices was bad but encouraged her to take the course. Why? To know how bad it is.
For a good consultant, knowing one correct way is not enough. You need to know others to answer questions. BTW, she got an A+ on the course and agreed with me. Then I told her, “Now, compared to how I conduct testing and deployment for all my apps, you know the Docker way is complex and generally not good”.
Why Software Architects Choose Hyped Technologies/Processes?
Keep reading with a 7-day free trial
Subscribe to AgileWay’s Test Automation & Continuous Testing Blog to keep reading this post and get 7 days of free access to the full post archives.