Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Defence of Monoliths

techblog.bozho.net

Post reply on HN
Print view View original

71–76 of 76 posts

Re: In Defence of Monoliths

#71

Post by ap22213 »

unoti wrote: post #12

There's a dangerous, contagious illness that developers of every generation get that causes them to worry about architecture and getting "street cred" even more than they worry about solving business problems. I've fallen victim to this myself, because street cred is important to me. But it's a trap. An important meta-idea that encapsulates all of this is remember to solve your business problems as your first priorit…

It's important to solve problems, but if you want to win at this startup game, how you solve those problems can make or break you.

In most cases there others solving the same problem. If you are the team bringing a better solution to market faster, with better design, higher quality, less maintenance, lower infrastructure costs, fewer developers - you win easier and earlier. But, that takes some dabbling and experimenting.

In the end, it's really about working with high quality people. A team of focused, pragmatic, informed, and disciplined people can take the right new tool and become an order of magnitude better. And, they can take the wrong new tool and know when to shelve it quickly.

The winners in this game aren't writing COBOL against mainframes - even though that would probably yield a sufficient solution eventually.

Re: In Defence of Monoliths

#72

Post by ap22213 »

patrickmay wrote: post #8

One advantage of a microservice architecture not mentioned in the article is the ability to scale services independently of other services. Being able to fire up more instances to address a bottleneck is often much simpler than managing threads in a monolith.

This is an important point. If you have a system that processes billions of inputs a day along a fairly complex pipeline, you're constantly scaling up and down. It would suck pretty bad if you had to scale mostly vertically.

Re: In Defence of Monoliths

#73

Post by lowbloodsugar »

wvenable wrote: post #66
lowbloodsugar wrote: post #65

Earlier quoted context omitted.

We've never had to break an API to make a change. Changes to the API should not break existing consumers. That's just as true for monoliths as it is for microservices.

A change to an API necessarily, by definition, breaks existing consumers. You can add to an API without breaking consumers but you can't change or remove.

There are at least two ways to change an API without breaking it:

* Adding a new method to the API does not break the API.

* In certain language/middleware combinations, adding new properties to a parameter object does not break the API.

If we have a method that needs to change, we add a new method. New clients use the new method, and we support old clients until they are retired. When using JAX-RS, we can add new properties to JSON objects provided they are annotated correctly.

Re: In Defence of Monoliths

#74

Post by wvenable »

lowbloodsugar wrote: post #73
wvenable wrote: post #66

Earlier quoted context omitted.

A change to an API necessarily, by definition, breaks existing consumers. You can add to an API without breaking consumers but you can't change or remove.

There are at least two ways to change an API without breaking it: * Adding a new method to the API does not break the API. * In certain language/middleware combinations, adding new properties to a parameter object does not break the API. If we have a method that needs to change, we add a new method. New clients use the new method, and we support old clients until they are retired. When using JAX-RS, we can add new pr…

You effectively have to maintain a backwards compatible system but that limits the amount of change that you can really do. It also definitely makes the system more complicated but more stable. That's the trade off.

If you're constantly changing/breaking the API then that's just a monolith in micro-service clothing. But the system can be simpler and you can make more significant changes quicker.

Re: In Defence of Monoliths

#75

Post by bullen »

The important thing is to improve tools, and with a monolith you can't do that.

So build a distributed PaaS with hot-deploy, then a distributed HTTP database; then you can use microservices without any of the problems mentioned (complexity becomes a non problem since everything is using the same complexity and it very quickly becomes bug free, overhead is removed by PaaS)!

The important step with microSOA is that each developer can choose his tools. That trumps everything else.

Re: In Defence of Monoliths

#76

Post by lowbloodsugar »

wvenable wrote: post #74
lowbloodsugar wrote: post #73

Earlier quoted context omitted.

There are at least two ways to change an API without breaking it: * Adding a new method to the API does not break the API. * In certain language/middleware combinations, adding new properties to a parameter object does not break the API. If we have a method that needs to change, we add a new method. New clients use the new method, and we support old clients until they are retired. When using JAX-RS, we can add new pr…

You effectively have to maintain a backwards compatible system but that limits the amount of change that you can really do. It also definitely makes the system more complicated but more stable. That's the trade off. If you're constantly changing/breaking the API then that's just a monolith in micro-service clothing. But the system can be simpler and you can make more significant changes quicker.

If you think of "the system" as the entire suite of applications across space and time, then the one approach is no more complicated than the other. One involves some effort thinking about backwards compatibility, the other with trying to get a bunch of teams to all commit to the right branch, and then get it integrated at the same time. My experience is that the latter proves far more disruptive to production. One of our groups (the monolith team) has one month code freezes while they integrate all the teams work into the latest monolith.

Our teams really have no limits on the changes they can do. If the change really is so complex that it requires changing every system, then we just build another system with zero dependencies. In fact we did that once. Got it working really fast. Usually branch-by-abstraction resolves any big issues, while updated method objects or just new methods handle most "changes".

Granted, this is with several hundred developers across multiple engineering departments. YMMV.

Post reply on HN