It’s just not worth it until your monolith reaches a certain size and complexity. Micro services always require more maintenance, devops, tooling, artifact registries, version syncing, etc. Monoliths eventually reach a point where they are so complicated that it becomes worth it to split it up and are worth the extra overhead of micro services, but that takes a while to get there, and a company will be pretty successful by the time they reach that scale.
The main reason monoliths get a bad rap is because a lot of those projects are just poorly structured and designed. Following the micro service pattern doesn’t guarantee a cleaner project across the entire stack and IMO a poorly designed micro service architecture is harder to maintain than a poorly designed monolith because you have wildly out of sync projects that are all implemented slightly differently making bugs harder to find and fix and deployments harder to coordinate.
I still have to find a name for this disease, but it’s somewhat like “you’re neither Google nor Netflix”.
Everything has to be Scalable™ even if a raspberry pi could serve 200 times your highest load.
I’m currently involved with a “micro service system”, that has very clear, legal requirements, so we know exactly, how much load to expect. At most, a few thousand users, never more than 100 working at the same time on very simple business objects. Complex business logic, but technically almost trivial. But we have to use a super distributed architecture for scalability…
I’m guessing you already got an answer for that though when you asked about it.
Could be either “oh you’re right let’s not do that”, or “because we want to design for horizontal scalability rather than vertical in case the demand grows later”, or “the client has requested and it’s paying for this feature” and so on.
It’s because they think it’s what you’re doing for a large project. Simple as that. There’s no future demand, the client doesn’t care, and I’m not right because they said so.
Micro services always require more maintenance, devops, tooling, artifact registries, version syncing, etc.
The initial transition is so huge too. Like, going from 20 to 21 services is no big deal, but going from 1 service to 2 is a big jump in the complexity of your operations.
Dude just start with a monolith and part it out as you scale. Of course microservices are a waste of time if you build them right off the bat.
It’s just not worth it until your monolith reaches a certain size and complexity. Micro services always require more maintenance, devops, tooling, artifact registries, version syncing, etc. Monoliths eventually reach a point where they are so complicated that it becomes worth it to split it up and are worth the extra overhead of micro services, but that takes a while to get there, and a company will be pretty successful by the time they reach that scale.
The main reason monoliths get a bad rap is because a lot of those projects are just poorly structured and designed. Following the micro service pattern doesn’t guarantee a cleaner project across the entire stack and IMO a poorly designed micro service architecture is harder to maintain than a poorly designed monolith because you have wildly out of sync projects that are all implemented slightly differently making bugs harder to find and fix and deployments harder to coordinate.
I still have to find a name for this disease, but it’s somewhat like “you’re neither Google nor Netflix”.
Everything has to be Scalable™ even if a raspberry pi could serve 200 times your highest load.
I’m currently involved with a “micro service system”, that has very clear, legal requirements, so we know exactly, how much load to expect. At most, a few thousand users, never more than 100 working at the same time on very simple business objects. Complex business logic, but technically almost trivial. But we have to use a super distributed architecture for scalability…
I’m guessing you already got an answer for that though when you asked about it.
Could be either “oh you’re right let’s not do that”, or “because we want to design for horizontal scalability rather than vertical in case the demand grows later”, or “the client has requested and it’s paying for this feature” and so on.
It’s because they think it’s what you’re doing for a large project. Simple as that. There’s no future demand, the client doesn’t care, and I’m not right because they said so.
Micro-services and monoliths sit at opposite extremes though. There are other takes in-between, like multiple services (not micro) for example.
The initial transition is so huge too. Like, going from 20 to 21 services is no big deal, but going from 1 service to 2 is a big jump in the complexity of your operations.