5 ms·
From personal experience Microservices enforce a clear interface and isolation pattern. This is achievable many ways, but having discrete deployed code makes i
by mey 10y ago
From personal experience
Microservices enforce a clear interface and isolation pattern. This is achievable many ways, but having discrete deployed code makes it very hard to violate rather than being disciplined.
Licensing costs can go drastically up as most modern licensing is node/core based. As can deployment procedures get more complicated.
I would love to understand how this article believes that the modules in a monolithic system can be scaled horizontally if they are actually a single code base in a single system. Either the system isn't monolithic, or it they have never really done it. Sticking a load balancer in front of a micro service and scaling based on measured load requires tools and technologies, but is very scalable. It also allows you to do rolling deployments of draining/rotate out/update/rotate in that allows you to get near no planned downtime.
Distributed transactions are the devil, but you don't need to do them in a microservice design. It requires design work on the front end to clarify what the system of record is, but if each service has a domain it controls, and all other services treat it as the truth, it's rather simple. I say this having researched doing payment transactions across geographically diverse colo's and we treated that as a sharding/replication/routing issue very successfully.
Ninja edit: Starting with a microservice design is most likely overkill for a lot of systems, but either way, clear interface/boundaries in your system are good and healthy
- 0xfaded 10y agoAt work I built and maintain a large codebase that deploys to multiple servers to perform multiple tasks. We also license software. The answer to your question is simply libraries and build targets. My monolith is mostly shared code, with unique functionality at the fringes, but it all builds into a single deployable jar, minus the licensed libraries which are special cased. I'm a huge fan of SBT, despite its dwarf fortress like learning curve.
- hood_syntax 10y ago> dwarf fortress like learning curve Good way to scare me off ever attempting to learn something, haha
- freekh 10y agoThis made me chuckle a bit. Also a huge sbt fan, but I see were the gate comes from (the learning curve)... :)
- lgunsch 10y agoWhy would you not be able to scale a monolith? You can apply the same principles to it: "[Stick] a load balancer in front of a micro service and scaling based on measured load"? A microservices allows you to scale up very particular components of an architecture, but there is nothing stopping a monolith from being horizontally scaled in just the same way. In AWS, I would make the monolith deployed with an AMI in an auto-scaling group with a load balancer in front.
- sbov 10y agoYeah, scaling app code is generally a solved problem: shared nothing with some load balancers. It doesn't work for every problem, but the above has been standard in my circles for at least a decade by now. Databases are trickier though.
- robotresearcher 10y agoMultiple instances with shared nothing is the opposite of a monolith, by definition.
- deleted 10y ago[deleted]
- anamexis 10y agoNot if they're all running the same code.
- robotresearcher 10y agoOK, I looked up the definition of monolithic application in a couple of places, and the meaning is not quite what I thought it was. I thought it was 'one app does everything for everybody' but it's more like 'one app does everything for somebody', so the horizontal scaling applies, and my previous comment is wrong. It's a shame that a 'monolith' application doesn't just mean a genuine singleton, though, as that would be the perfect name for it. A bank of load-balanced monoliths should be a polylith.
- deleted 10y ago[deleted]
- jsmith0295 10y agoYou could achieve better horizontal scalability by making the monolithic application work in a distributed fashion. This would be easier with some platforms than others. Actor based systems in particular tend to be easier to do this with.
- StabbyCutyou 10y agoAuthor here - your ninja edit is one of the core premises of the entire post. Some other folks have addressed the scalability questions you raised, but i'd add - I am in no way advocating for monoliths as a better approach. Rather, both have tradeoffs you need to think through before adopting. Thanks for taking the time read.
- pbreit 10y agoScaling is comparatively easy when compared to generating the amount of usage that actually requires scale. So it's pretty much a waste to think too much about it in the beginning (note that I am not granting permission to be sloppy).
- gimmeabreakguy 10y agoJesus christ. "Stick a load balancer in front of it and scale horizontally" works _precisely_ as well for a monolithic app as it does for a microservice. Which is to say, it might work, to some degree, to some total load, for some systems, and it might not for others, and will eventually break down at high enough load for pretty much anything that's not a pure function (e.g. you could scale a RESTful javascript linter horizontally presumably forever with more load balancers and more api servers, but your chat system is going to get more complex)