When is a monolithic architecture a better choice than microservices?
1
I previously worked at a credit union where software developer salaries were way under market ($50k–$60k), prompting me to leave and triple my income. I later discovered that the chief of technology hired a former developer and close friend as a remote, part-time contractor at a triple-digit hourly rate. This individual maintains a separate full-time job and works completely flexible hours, 20-40 hours. This feels like blatant cronyism. Is there any recourse?
I just graduated with my bachelor's in computer science at 26. I had a good GPA, but it took me a few extra years to get through the program for various personal reasons. My main concern right now is the age gap. Since I'm starting my career a few years behind the typical age group, I'm worried I might never catch up financially or professionally. Will companies view my age as a red flag for entry-level roles, and does starting later cap my ultimate career trajectory?
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.