When is a monolithic architecture a better choice than microservices?
1
In my ten years as a software engineer, I’ve discovered a bizarre trend that smooth projects often get less recognition than chaotic ones. It may be due to a perception that it must have been an easy project if it was so smooth. On the other hand, projects with multiple day follows, dramatic reverts, etc get a ton more visibility. Have others seen this on their organization?
My manager keeps pressuring me to go for a promotion, but the payoff is terrible. I was passed over last year, so now I feel good about my decision to resist. It's basically endless paperwork and corporate politics for a tiny bump in salary. I'd much rather continue writing code remotely, do my job, and stay under the radar. Is it okay to resist the push to move up?
Am I overreacting or is this a completely reasonable thing to be anxious about? My company has been doing surprise layoffs with no heads-up whatsoever. You'll notice someone is just gone from Slack one day, and leadership stays completely quiet until gossip starts spreading. It's been really hard to focus, knowing anyone could be next.
When you have to ask that question. That's when. When you're unsure which one you need. That's when. When you have more microservice than users per hour. That's when. When you have no evidence of enough user traffic and performance bottlenecks that are best solved with a microservice. That's when. In short... choosing to add additional microservices adds overhead costs: 1. Orchestration. 2. Service integration testing. 3. Complex repo/dev environment management. 4. Dependency management risks. 5. CI burden. It is not free. Don't pick it by default. Understand why it became a powerful tool for horizontal scaling in the first place.
Yeeeee buddy! And don't be too harsh on yourself. I was a clean code + agile + clean architecture acolyte... for a while (yeah, I went down the Uncle Bob rabbit hole - recovering with Primeagen videos now, LOOOOL) IMO you NEED to drink enough of the kool-aid to realise that it has a bad after-taste. The good thing, though, is that you learn the limits of whatever you're evangelising. Balance in all things. That's what makes us learn good engineering imo.
When you need to perform RDD (Resume Driven Development)
lambda functions as services. 🤣
Check out this interesting interview: https://youtu.be/LcJKxPXYudE?si=Kklp0JaLgQvY5WnX
When it’s a small team or a single team. Monolith app has a lot of benefits.
Scale the number of systems based on the number of self sustaining teams you have.
Microservices is the way
Part of the problem is that monolith and micro services (MS) are not a uniform thing. There is a good and bad monolith implementation and a good and bad MS implementation. There is also a huge middle ground between the two where 99.99% of apps will be just fine. Don't let perfect be the enemy of good enough. I once inherited a huge monolith. It used a custom build wire protocol for all comms AND storage. Each processes behavior was hard coded to hostnames so every process has to be run on the correct host. Storage was a custom, in house built(?!?!??), database with many issues. All comms were via RPC. Finally, they weaponized inheritance so changing a commonly used base class resulted in sprawling changes. Processes owned their "DB" and also provided access (without auth!) via RPCs. The wire protocol had zero support for backwards compatibility. RPCs meant that there was zero abstraction. This was a monolith done very wrong. _Everything_ was tightly coupled, a small change (moving one value from string to int for example) frequency resulting in rebuilding millions of lines of code, huge testing costs, plus a day long migration + down time. In short, 1 element change in 1 class cost the customer 250k and took 6 weeks to go live. In actuality we did about 2 deploys a year, each cost the costumer at least $1m. I have also seen systems that were excessively decomposed into way too many tiny MSes (i.e. hundreds). I don't know if they got paid by the unique MS or they just drank the cool aid? To successfully ppl produce and output from 1 input required dozens of API calls internally. Everything was abstracted and fragmented down to the smallest possible chunk. Managing this was a challenge: containerized java SB apps running in k8s. Huge networks of namespaces, svcs, helm charts, etc. Performance was terrible because everything took many API calls to do anything and network calls take forever. Consistency was a huge issue; how to handle storing results when they are spread over 5 MS and the third call fails? Debugging an issue was super painful and took a long time digging through the splunk logs. The number of ways for the system to not work correctly was huge. We spend 50x dev time making everything super resilient, handling dozens of failure modes correctly, and handling edge cases. The system was always slow and brittle.