3 ms·
HN could be a little less pessimistic. People aren't choosing microservices merely because of the hype. Here's why I'd choose microservices for a large project
by jeswin 3y ago
HN could be a little less pessimistic. People aren't choosing microservices merely because of the hype.
Here's why I'd choose microservices for a large project:
1. People don't produce uniform code quality. With microservices, the damage is often contained.
2. Every monolith is riddled with exceptional cases in a few years. Only a few people know about corner cases after a few years, and the company becomes dependent on those developers.
3. It's easier for junior developers to start contributing. With a monolith you'd need to be rigid with code reviews, whereas you could be a little lax with microservices. Again, ties into (1) above. This also allows a company to hire faster.
4. Different modules have different performance and non-functional requirements. For example, consider reading a large file. You don't want such an expensive process to compete for resources with say a product search flow. Even with a monolith, you wouldn't do this - you'd make an exception. In a few years, the monolith is full of special cases which only a few people know about. When those employees leave, the project sometimes stalls and code quality drops. Related to (2).
5. Microservices have become a lot easier thanks to k8s and docker. If you think about it, microservices were becoming popular even before k8s became mainstream. If it was viable then, it's a lot easier today.
6. It helps with organizing teams and assigning responsibility.
7. You don't need super small microservices. A microservice could very well handle all of a module - say all of payments (payment processing, refunds, coupon codes etc), or all of authentication (oauth, mfa etc).
8. Broken Windows Theory more often applies to monoliths, and much less to microservices. Delivery pressure is unavoidable in product development at various points. Which means that you'll often make compromises. Once you start making these compromises, people will keep making them more often.
9. It allows you the agility to choose a more efficient tech/process when available. Monoliths are rigid in tech choices, and don't easily allow you to adopt a different programming language or a framework. With Microservices, you could choose the stack that best solves the problem at hand. In addition, this allows a company to scale up the team faster.
Add:
10. It's difficult to fix schemas, contracts and data structures once they're in production. Refactoring is easier with microservices, given that the implications are local compared to monoliths.
- dlisboa 3y agoYes! Finally! People keep making the assumption that going for Services/Microservices is merely technical. It’s almost all about people and organization. Point 7 is the most important of the technical considerations: just make your services big enough to make sense as a separate unit and small enough to not be another unchangeable monolith. Yes, it’s not sane to have 300 Lambdas that add one number to another talking to each other over network, so just don’t do it. Microservices the “Netflix way”, with the huge graph of services, gives a bad name to the idea of factoring out modules into independently deployable parts, which always made sense. Kubernetes just helps with deployment, but how coarse or fine you factor is on you.
- danmaz74 3y agoFor "large projects" there are merits to microservices, but large projects are the exception - most projects aren't large. Unfortunately, a few years ago the consensus seemed to be that microservices should be applied to every project size, because they were always better - which generated so many problems. The simplified view I hold is this: if your main problem isn't a lack of engineers, but how to split work between hundreds, or even thousands of engineers, then microservices make a lot of sense; that's true at FAANG and some other companies. If your main problem is how to get the maximum out of a limited number of engineers you can afford to hire, then microservices is not the solution. The latter is by far the most common case.
- bilalq 3y agoI very much agree with these points. 1 & 8: This is something I've experienced first-hand quite a bit. When code quality starts slipping in service, it accelerates and inevitably leads to more hacks built on hacks. The containment afforded by service separation helps keep these hacks quarantined and minimizes the pollution and spread. 6. There's no ambiguity or question of who owns what when services/packages are separated and have distinct owners. Transferring ownership means transferring ownership of the service. In large companies with some teams working on secret projects, it's much easier to have viable workflows with service separation than with a monolith. Permissions management and so many other things are easier. 7: I think this is an excellent point. Another way of looking at this is as having multiple focused monoliths. I'd also add that there's a benefit in blast radius minimization. Updating a library or merging in a risky change doesn't risk breaking literally everything all at once. One service can update something and you know for a fact that it can't break anything other than that service and its dependents.
- cjfd 3y agoThe truthfulness of this comment depends very heavily on four words: 'for a large project'. This is the problem with the microservices hype. It is so very easy to ignore this four word restriction and start applying them everywhere. As such your post is a contribution to the problem and not the the solution.
- pjmlp 3y agoMicroservices are rebrandend SOA. We weren't doing Sun RPC, PDO, CORBA and DCOM everywhere for fun, yet with some rebranding, SOA should be the solution for everything.
- seabrookmx 3y agoI prefer the SOA terminology because as the post you're replying to says, you don't need to make these services too small, whereas "micro" implies that they are. Monoliths vs microservices is really a spectrum.
- pjmlp 3y agoI fully agree with that.
- eternalban 3y agotldr: Microservices trade design complexity with operational complexity, to address the shortcomings & patterns of the modern IT sector, at both worker and management levels. This was an excellent choice for consulting (companies like ThoughtWorks, who were pushing microservices) as it optimized their workflows and bottom line: the answer to every client's question of "what's the architecture?" was "Microservices". The companies pimping m.s. were internally optimized for this architecture - running a consulting shop where the time between "here is our project" to "here is our proposal" is approaching zero is profitable. And the best part -- just like all those "GPT-processes" now being pushed by companies built around an api -- is that by the time clients encounter operational complexity of running micro-services, the consultants have long left the building.
- switch007 3y ago> Microservices trade design complexity with operational complexity Yup! And it annoys me so much how architects/consultants get away with just proposing 'microservices' without being held responsible for all the increased operational complexity. It's left as something for devops to figure out later.
- mrg3_2013 3y agoI would argue Microservices trade 100% design complexity with 100% operational complexity and 20% design complexity. Everytime I saw a microserviced design, I always wondered how would they debug this easily and re-operationalize it. Sometimes it is better to let the entire system die and spawn it back instead of having something running to make it look like it's alive.
- roflyear 3y agoOr more than 20%.