61–70 of 243 posts
If I were consulting for this company, I would have told them to stop right there, microservices are probably not for them. Unless you build from the start for microservices on something like AWS lambda, doing with such a small team would be really hard.
And as they eventually discovered, a lot of unnecessary overhead for such a small team.
Microservices shift complexity from code to operations - microservices don't remove complexity - they spread it wider, making the whole more complex.
Examining behavior in the limit (a la physics) is interesting. Imagine a system where every function call goes out to a separate process. Suddenly you have a lot of processes waiting around to be called. Debugging requires special tools. Profiling becomes a nightmare. Even determining if the system is fully running becomes difficult. What have you gained?
Separation of responsibilities? Easier to analyze because you only have so many inputs and outputs to a simpler system?
Debugging something that touches a lot of paths in a monolith can be quite nightmarish as well.
Earlier quoted context omitted.
I hope you're trolling. If not, enjoy implementing joins across services.
Doesn't this just mean you picked a bad service boundary? You shouldn't have to join across services, ever. Seems like a straw man.
Microservices shift complexity from code to operations - microservices don't remove complexity - they spread it wider, making the whole more complex.
Why would you consider microservices if you are only 12 developers?
I’m in a team of 4 and the few API’s we expose would be considered microservices. We did that because it was easiest and fastest for us to build and maintain and the features we provide were all quite distinct.
Monolith vs microservice is not a dichotomy, it's a spectrum (as it is with so many other things). Individual microservices can still become monolith-y and become responsible for doing a Lot of Things (TM). That being said, the biggest hurdle in a re-architecture project like this is usually in the "n=1 -> n=2" stage, and "n=2 -> n=5" is a lot easier: once you add service #2, you learn how to set up telemetry, permis…
1. You can't "migrate" to microservices from a monolith. This is an architectural decision that is made early on. What "migrating" means here is re-building. Interestingly, migrating from microservices to a monolith is actually much more viable, and often times just means stick everything on one box and talk through function calls or IPC or something instead of HTTP. Don't believe me? See this quote:
> The only ways we could break down our monolith meant that implementing a standard ‘feature’ would involve updating multiple microservices at the same time. Having each feature requiring different combinations of microservices prevented any microservice from being owned by a single team.
Once something is built as "one thing," you can't really easily take it apart into "many things."
2. Microservices does not mean Kubernetes. The idea that to properly implement microservices, you need to set up a k8s cluster and hire 5 devops guys that keep it running is just flat-out wrong.
3. Microservices are "antifragile," to use a Talebian term. So I think that this paragraph is actually incorrect:
> This uncertainty made creating microservices more fraught, as we couldn’t predict what new links would pop up, even in the short term.
A microservice is way easier to change (again, if designed properly), than a huge app that shares state all over the place.
4. What's the point here? It seems like the decision was hasty and predictably a waste of time. Any CTO/architect/tech lead worth his or her salt would've said this is a bad idea to begin with.
Congratulations, you have micro services!
As someone who have driven the migration from a monolith (just set environment variables and magically the same codebase becomes auth, notifications, workers, web and API and the same codebase reaches into every single database and talks to every single service) into micro services because a simple features were taking months to implement, I can confidently say that even today, in 2022, an average organization does not have the tooling or the team to do a monolith. Monolith is a cargo cult. Break stuff into an digestable chunks, externalize your own internal libraries if they are shared, version the interfaces and stop worrying about microservice complexities.
The term "Monolith" was devised by people who wanted to brand microservices as newer and superior. It's almost as if in order to succeed these days you need to discredit and disparage your competition rather than simply having a better product, and that's why I don't buy into buzz words at all. If it's not broken, don't fix it... Microservices are relatively new and unproven. The way the world has rushed to dive into…
> Microservices are relatively new and unproven. They are so old, buddy, actually. Splitting monolith into services(not always been micro) is a natural evolution for any software.
No less natural than "joining the innumerable incompatible and bug-ridden fragments into a single unified solution."
Linux is a bazar. Except distros and package repositories are cathedrals.
Windows is a cathedral. Except software distribution is a bazar.
The term "Monolith" was devised by people who wanted to brand microservices as newer and superior. It's almost as if in order to succeed these days you need to discredit and disparage your competition rather than simply having a better product, and that's why I don't buy into buzz words at all. If it's not broken, don't fix it... Microservices are relatively new and unproven. The way the world has rushed to dive into…
> Microservices are relatively new and unproven. They are so old, buddy, actually. Splitting monolith into services(not always been micro) is a natural evolution for any software.