4 ms·
> It feels like we’re starting to pass the peak of the hype cycle of microservices I feel like any article I see on microservices bemoans how terrible/unnecess
by scarmig 8y ago
> It feels like we’re starting to pass the peak of the hype cycle of microservices
I feel like any article I see on microservices bemoans how terrible/unnecessary they are. If anything, we're in the monolith phase of the hype cycle =)
If you're moving to microservices primarily because you want serving path performance and reliability, you're doing it wrong. The reasons for microservices are organizational politics (and, if you're an individual or small company, you shouldn't have much politics), ease of builds, ease of deployments, and CI/CD.
- cphoover 8y ago100%
- jacquesm 8y agoIt's like almost everything else a matter of balance. A monolith that cross-connects all kinds of stuff in ways will become an unmaintainable mess over time, a ridiculously large number of microservices will move the mess to the communications layer and will not solve the problem. A couple of independent vertically integrated microservices (or simply: services, screw fashion) is all most companies and applications will ever need, the few that expand beyond that will likely need more architectural work before they can be safely deployed at scale.
- scarmig 8y agoEven at a very large company, it's probably too common to spin out some logic into its own microservice. Often times owning your own microservice is a great argument for a promo, even if the code could just as well be in an existing service. Companies would claim to discourage that tendency, but it's a false claim. So that's an additional reason for microservice frameworks: a welfare safety net for software engineers.
- nwah1 8y agoDevelopers think of microservices this way, now. Managers still think of it as exciting.
- ori_b 8y agoThere are also two purely engineering considerations: scalability and crash isolation. Scalability -- for when your processes no longer fit on a single node, and you need to split into multiple services handling a subset of the load. This is rare, given that vendors will happily sell you a server with double-digit terabytes of ram. Crash isolation -- for when you have some components with very complex failure recovery, where "just die and recover from a clean slate" is a good error handling policy. This approach can make debugging easy, and may make sense in a distributed system where you need to handle nodes going away at any time anyways, but it's not a decision to take lightly, especially since there will be constant pressure to "just handle that error, and don't exit in this case", which kills a lot of the simplicity that you gain. Both are relatively rare.
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]
- jules 8y agoMicroservices are not good for scalability. You want data parallelism, like 20 webservers that all do the same thing. Not splitting your app into 20 microservices all doing something else.
- cc81 8y agoYou need to build a pretty big system for ease of builds, ease of deployments and CI/CD to become easier with microservices.
- scarmig 8y agoYes. If you would balk at multiple SWE years worth of work to move to microservices because of all the opportunity costs for your business, microservices aren't for you.