Member-only story
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 below news.
Please note that this case study was done (and released) in 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
∘…
