Here's a quote from https://grugbrain.dev/ (discussed here on HN a while ago) which seems very appropriate:

> Microservices: grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too. seem very confusing to grug

Some thoughts:

- #12 add observability needs to be #1. if you can't observe your service, for all you know it's not even running. Less hyperbolically, good instrumentation will make every other step go faster by lowering the time to resolution for any issues that come up (and there will be some)

- #11 is incredibly oversimplified, and potentially dangerous. how to do double writes like that and not create temporal soup is...complicated. very complicated. it's important to remember that the database the app is sitting on top of is (probably) taking care of a great many synchronization needs.

if you can do a one way replication, that drastically simplifies things. otherwise either do it in the monolith before breaking up into services, or do it after you've broken up services, and have the services share the database layer in the interim.

(I'm not debating that it needs to be done -- just advocating for sane approaches)

- #10 - I've had great results with the strangler pattern. Intercepting data at I/O gives a lot of tools for being able to gradually change internal interfaces while keeping public/external interfaces constant.

- #5 - as you introduce more processes, integration and end to end testing becomes more and more vital. it becomes harder and harder to run the service locally, and it becomes harder to tell which where a problem is occurring. cross service debugging can be a nightmare. in general it's just important to keep an eye on what the system is doing from an outside perspective and if any contracts have inadvertently changed behaviors.

I sympathize with both positions — however, spend any time working somewhere like a bank, or hardware/electronics company founded before 1980, and you’ll develop a distinct distaste for monoliths.

I’ve seen monoliths create teams of career software bureaucrats who exist to choke out companies to their last breath. Companies will go underserved for decades while underfunded projects fail to replace a monolith one after another. All crossroads lead to the monolith that was written in some language that died 30 years ago, performs like it did 30 years ago and is maintained by people hired 30 years ago — creating imminent crises with their looming retirements.

I think a lot of people here read this article as writing monoliths vs microservices — not so. There are many very old, inherited monoliths that are actively creating maintenance crises at many businesses. These need to be modernized in chunks, because full rewrites take years to fail (and often do, eg. the mythical data warehouse). Microservices offer some incremental path out of the quagmire.

If you don’t have the skills to write modular maintainable monoliths then you most definitely don’t have the skills to implement modular maintainable microservices. It’s the same skills required to do both: the ability to break down a complex system/problem into a number of simpler systems/solutions/modules/libraries/services/… so that the complex system/problem can be solved by composing those simpler systems/solutions/modules/libraries/… into a single system/monolith/…

A lot of those steps just seem like good engineering. (I personally prefer modular monoliths over microservices though, in all but very few cases.)

Advice. Don’t bother if you have a monolith. Just keep trucking on with it and partition your stuff vertically with shared auth and marketing site.

Fuck microservices unless you have a tiny little product with a few million users. Which is almost none of us.

90%+ of transitions to microservices occur because the developers involved need to give the impression they are doing something in the absence of being allowed to build something new like they would prefer, and want to put "microservices" on their resume for when they try to leave their current shithole of a company for a slightly better paying, trendier shithole

I was once working with a guy that was hell bent on microservices.

When our banking application became incompatible with logging, due to his microservice design, he really argued, fought and sulked that logging wasn't important and we didn't need it.

Does each microservice really need its own database? I have recently proposed my team initially not do this, and I'm wondering if I am creating a huge problem.

Enjoyed the article, and found #11 and #12 to be almost a requirement for most teams.

I've worked for an org that adopted microservices when it's small size didn't justify it but eventually found its footing with good containerization, K8s from a growing DevOps team. Individual teams were able to eventually deploy and release to various environments independently, test on QA environments easily.

And I now work for an org with a monorepo with 100+ developers that probably should have been broken up into microservices a while ago. Everything just feels broken and we're constantly running around wondering who broke what build when. We have like 6 SREs for a team of 100+ devs? I think a lot depends on how well CI/CD is developed and the DevOps/SRE team.

People forget, micro services commonly serve massive tech companies. With 100 developers working on the same product, you need it broken up and separated. If you’re in a small company, the value proposition is not as great. It’s contextual, and a tech stack that solves organizational problems, not always technical ones

Looks like microservices became a self-goal. However author can be praised buy giving a context (implicit) of a huge team which should be split.

Microservices have one big advantage over monoliths: when you have a very large number of employees developing software it means that you can keep your teams out of each others' hair. If you don't have a very large team (as in 50+ developers) you are probably better off with a monolith, or at best a couple of much larger services that can be developed, tested and released independently of each other. That will get you very far, further than most start-ups will ever go.

Why microservices called "micro"? When it's almost implied it requires a dedicated team to develop and maintain? Looks it's like SOA but with JSON and k8s.

> 10 Modularize the monolith

A couple paragraphs on a couple of tools for the middle to late stages of such an effort is tantamount to "and then draw the rest of the fucking owl".

Decomposition is hard. It's doubly hard when you have coworkers who are addicted to the vast namespace of possibilities in the code and are reaching halfway across the codebase to grab data to do something and now those things can never be separated.

One of the best tools I know for breaking up a monolith is to start writing little command line debugging tools for these concerns. This exposes the decision making process, the dependency tree, and how they complicate each other. CLIs are much easier to run in a debugger than trying to spin up the application and step through some integration tests.

If you can't get feature parity between the running system and the CLI, then you aren't going to be able to reach feature parity running it in a microservice either. It's an easier milestone to reach, and it has applications to more immediate problems like trying to figure out what change just broke preprod.

I have things that will never be microservices that benefit from this. I have things that used to be microservices that didn't need to be, especially once you had a straightforward way to run the code without it.

You can actually use microservices to reduce the complexity of a monolith.

One example which I built just for this purpose is Barricade https://github.com/purton-tech/barricade which extracts authentication out of your app and into a container.

I have a strong feeling that the author never in their career transitioned from monolith to microservices. Even to the point "we are getting somewhere", not to mention "we are successful at this". Text reads like self- complacency.

hold on, if we have half a dozen web apps that serve different needs, but all share similar "guts" — a monolith doesn't really make sense because App B will have all the code of App A but only use like 10% of it...

So if I split App A from App B (and App C, D, etc.), but create a single "back-end monolith" for both apps, that makes sense right? Is that still microservices?

And if half of them need authentication, but I want to keep my auth data separate from my other backend data, shouldn't I create a "regular db backend" and an "auth backend", for my many web apps?

Essentially this is what I've done. I don't start with "microservices" but at the same time I don't want to glom ALL my random sites and apps' front-end and back-ends into the same code base... that makes upkeep WAY too difficult.

Is this a monolith, a microservices, or none of those? I'm not really a "real" engineer and haven't drank any koolaid so I honestly don't know if this is the right way to do it. Most of my sites and web apps are Sveltekit / Vercel, with CF Workers, Supabase, Deta, and Railway doing some other stuff Vercel can't do.

(I don't have a hosted machine or anything lol)

Is there a guide on doing the opposite?