Comment by mey | Hacker News Reader

Comment by mey | Hacker News Reader

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

Why 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.

Yeah, 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.

Multiple instances with shared nothing is the opposite of a monolith, by definition.

Not if they're all running the same code.

OK, 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.

I'm not sure if it's a useful distinction, because when you think you're building a 'monolithic' app you might actually be building a 'polylithic' app. Beyond that, in a lot of instances you have to make very few tradeoffs to go from 'monolith' to 'polylith'.

By your definition, most rails/django apps are probably polyliths.

Author here - Came to reply with basically what you just said.

Thanks for giving it a read!

Jesus 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)

At 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.

> dwarf fortress like learning curve

Good way to scare me off ever attempting to learn something, haha

This made me chuckle a bit. Also a huge sbt fan, but I see were the gate comes from (the learning curve)... :)

Author 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.

Scaling 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).

You 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.

Reply on news.ycombinator.com