Monolith ✅ vs Microservices ❌, a New Perspective
One main reason that people chose Microservices: Fear of Testing; Cannot do real UI Test Automation.
The two main topics of my writing: End-to-End Test Automation and Continuous Testing. I usually don’t share my views on software architecture. I consider myself a good software engineer/designer, as I won an international programming award. The concrete proof is a list of apps I have developed (and been maintaining, this is harder) all these years, in my spare time, solo.
The reason I am talking about Monolith or Microservices (two software architectures) here is: this is still about End-to-End Test Automation and CT, very much so.
What led me to write this article? The following news.
Please note that this case study was done (and released) on Amazon, which should embrace Microservices (so customers buying more instances). So, I was surprised to see it.
Microservices became popular about 5 years ago, I never liked it and never witnessed a successful implementation (always with all heaps of problems). It reminded me of the infamous Enterprise Java Beans (EJB). The so-called benefits sound good in theory, but not in practice.
You will find many “Microservices Pros and Cons” and “Microservices vs Monolith” articles online. Here, I will share a new fresh perspective.
A compromised view (between Microservices and Monolith fans) is that “Microservices is complex, introducing overhead (performance and infrastructure, i.e. more expensive) but it is more scalable”. I think both sides can accept that, right?
Table of Contents:
· 1. Most Web apps are not that complex, Monolith is more than capable in terms of performance, scaling, … etc
· 2. A technical compromise resulting from a limitation in its capability to perform comprehensive Automated End-to-End UI Regression Testing
∘ 1. “We don’t have the capability to do automated end-to-end (via UI) testing”
∘ 2. “API Testing shall be enough”
· Advice
1. Most Web apps are not that complex, Monolith is more than capable in terms of performance, scaling, … etc
I worked as a Java Contractor Programmer for over a decade on many projects, honestly, maybe only one or two of those apps can match the complexity of my-solo-developed-in-spare-time apps such as ClinicWise and WhenWise. All my web apps are powered by the Ruby on Rails framework, a Monolith architecture.
By the way, Ruby on Rails is the most in-demand skill according to Hired’s 2023 State of Software Engineers Report.
Some would argue “Your apps would be more scalable if using a Microservices architecture”.
Maybe, but I have always been satisfied with the performance and scalability of my apps. For a Micro-ISV (independent software vendor), infrastructure cost can hit me hard, by using Ruby on Rails (Monolith), a complete production server set-up (for one app) costs me merely ~80/month.
two MySQL database server instances
(one is primary, and the other is mirrored)two app server instances
(one primary, the other for failover)one shared Redis server
(caching and background processing)one load-balancer
(Nginx)
FACT: there have been big advancement in CPU manufacuting (by TSMC), we get faster and faster CPUs & memory & hardrives.
Yes, My apps don’t have a big number of users. If my apps suddenly get a lot more customers, this is a good problem to have, upgrading to faster server instances (up to 20X powerful) is very easy. No changes to the software.
Moreover, setting up testing server instances is very easy, all my existing Mac Minis, basically free.
As you can see, the hyped better scalability by microservices architecture is pale compared to the huge real infrastructure savings every month to my apps: ClinicWise, SiteWise, WhenWise, SupportWise and TestWisely.
Some “Microservices fans” will immediately think “That’s because the volume to your apps is still small”. Yes. How about Github and Airbnb, both developed in Ruby on Rails (Monolith)? Surely your app won’t match even the 0.1% scale needs of Github.
For most apps, the hyped Microservices benefits are not realized, but the cost and complexity are real. Monolith architecture, if done decently, is comfortably capable to scale to a level that 99.99+% apps never need, and cost only a little extra.
So, what is the fundamental reason that some software companies adopted Microservices? Putting aside the silly chasing hype, it is Testing!
2. A technical compromise resulting from a limitation in its capability to perform comprehensive Automated End-to-End UI Regression Testing
I still had friends working as software architects or senior software engineers. From casual conversations with them, I figured out the main reason for them to choose Microservices is easier testing (via API). The logic behind:
1. “We don’t have the capability to do automated end-to-end (via UI) testing”
Numerous software projects have attempted end-to-end UI testing, but the success rate has been extremely low, with ~99.9+% failure. Various tools like Selenium WebDriver (in the past) as well as so-called “better” Protractor, TestCafe, Cypress, and Playwright have been tried, but the outcome remains consistent: failure. So, it is not the framework but rather, the people. As we all know, there were solid test automation successes with raw Selenium WebDriver (see below).
“Facebook is released twice a day, and keeping up this pace is at the heart of our culture. With this release pace, automated testing with Selenium is crucial to making sure everything works before being released.” — DAMIEN SERENI, Engineering Director at Facebook, at Selenium 2013 conference.
Upon acknowledging a new failure (test automation attempt), senior management and lead engineers often prefer to conceal the fact, “our software engineers are OK with coding but struggle with seemingly simple test automation.” Thus, it is in everyone’s best interest to hide these failures or make up some excuses. Consequently, only a few software companies opt to seek external assistance for end-to-end test automation.
Regression errors are observed more (and often) in apps in a monolithic architecture. That’s why a good regression testing process (run multiple times a day) is important (also applies to Microservices too, which often turned into a complete mess). The only correct approach lies in implementing true Continuous Testing, which involves conducting thorough automated UI tests on a daily basis to serve as regression testing. However, few can achieve that. When the number of defects in the defect tracking system surpasses a certain threshold, some senior engineers begin to adopt Microservices.
Why? In theory, each service can be tested independently through APIs (API testing is easy and we don’t know how to do proper end-to-end via UI testing, and we don’t want others to know). In the event of a reported issue/defect, we can focus on fixing and testing the affected microservices without having to modify others.
Will this approach be successful? I don’t think so. This mindset is reminiscent of the infamous EJB (Enterprise JavaBeans), which brought my bad memories (between 2003–2005) when I worked as a senior Java Contractor Developer. When I first heard people talking excitedly about Microservices Architecture (in 2008), my instant thought was “Oh no, the history is about repeat”. I witnessed many failed or struggling (with big cost) Microservices projects and this Amazon case study confirmed that my prediction was correct.
2. “API Testing shall be enough”
By the way, this statement is wrong. According to World Quality Report 2018–19, “The first time ever that `end-user satisfaction” is the top objective of quality assurance and software testing strategy”.
If people stop bullshitting around testing, back to the very basics, shouldn’t we, as software engineers, test the software as the end-user? Of course, we do.
The dilemma is that “our project is doing Agile, Scrum, SAFe, Kanban or whatever, we can’t proudly say we do manual regression testing, which is not practical anyway, but clearly we do not have the capability to do real UI test automation. The agile coaches can only participate in so-called agile ceremonies, such as daily-stand-up, estimating user story points, retrospectives, …, etc.”
Thus, numerous software projects adopt the following testing approach either willingly or inadvertently.
Fake UI Test Automation
That’s why commonly we see one or two fake automated testers hired to do fake UI automation, and no one cares about the outcome.Do API Testing for Microservices
“If we do well, we should have minimized many risks.” Maybe, that's a big IF at first. Good API testing in a continuous manner, is uncommon too. (My ebook: https://leanpub.com/api-testing-recipes-in-ruby)Hire more manual testers to do ‘light’ regression UI testing
“While it is definitely not elegant, not effective, costly, and not agile, What can we do? Let people know none of us have ever witnessed what real UI test automation? Of course, not.”
Proofs of “failed automated UI testing then trying API”: there are many articles about using Cypress or Playwright for API testing. This is a joke, as Cypress or Playwright clearly labelled themselves as a web testing framework/tool. We can always do API testing in any language, such as net/https .
Advice
Either Monolith or Microservices, automated UI regression testing is good (and mandatory for real Agile). Be like a man or an engineer, face the challenge. Admit what you don’t know and learn actively.
Real Automated End-to-End UI Regression Testing is not only possible but also, in my opinion, mandatory. I cannot think of any other way to develop software.
Below is a recent test execution report of 569 raw Selenium WebDriver + RSpec tests for my WhenWise app, running on 6 build agents via a BuildWise CT server.
The first step, the hardest one I think, is for a software team/company to admit: “We do not know real test automation, or real CI/CD at all”. It is not only not shameful, but rather admirable.
To make it easier, check out the following quotes.
“In my experience, great developers do not always make great testers, but great testers (who also have strong design skills) can make great developers. It’s a mindset and a passion. … They are gold”.
- Google VP Patrick Copeland, in an interview (2010)“95% of the time, 95% of test engineers will write bad GUI automation just because it’s a very difficult thing to do correctly”.
- this interview from Microsoft Test Guru Alan Page (2015)“Testing is harder than developing. If you want to have good testing you need to put your best people in testing.”
- Gerald Weinberg, in a podcast (2018)
Also, a Wired article: “The Software Revolution Behind LinkedIn’s Gushing Profits”.
After the admission of no UI Test Automation capability, the rest becomes easier and can get results rather quickly with the following approaches:
Get help from a real Test Automation Coach, such as training and mentoring
All websites are the same from an end-to-end testing perspective, obviously, the shortcut is to learn directly from one who had done this many times.Self-Learning
check out, Advice on Self-Learning Test Automation with Selenium WebDriverDig out the internal talents
often, the middle managers and tech leads are road blockers. Check out, Test Automation and Continuous Testing Competition Week.
In summary, while there may be scenarios where the Microservices architecture is suitable for your application, based on my extensive 25 years of experience primarily in web app development/testing, I have yet to encounter a situation where a robust Monolith framework like Ruby on Rails fails to address important considerations like performance and scalability. A wise IT executive should instead prioritize enhancing the capability of comprehensive end-to-end test automation. Regardless of whether you opt for a Monolith or Microservices approach, ensuring sufficient end-to-end testing coverage remains crucial as a safety net.
A question: Did You Push Software Updates into Production Yesterday?
Relative readings:
My eBooks:
- “Practical Web Test Automation with Selenium WebDriver”
- “Practical Continuous Testing: make Agile/DevOps real”DHH’s The Majestic Monolith
Test Automation Camel, a metaphor that explains why most test automation attempts failed?
Benefits of Test Automation and Continuous Testing series: Executives, Managers, Business Analysts, Developers, Testers and Customers.
Test Creation Only Account for ~10% of Web Test Automation Efforts