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

Don't start with microservices – monoliths are your friend

arnoldgalovics.com

Post reply on HN
Print view View original

371–380 of 468 posts

Re: Don't start with microservices – monoliths are your friend

#371

Post by indymike »

Managing complexity is hard, no matter the approach to it. Microservices define boundaries around component inputs and output and try to reduce complexity by black boxing functionality. Monoliths try to reduce complexity by managing code (languages, libraries, databases, etc). I'm not sure there really is a good answer between the two because over time:

1. Vendor (and open source) blackboxes get introduced to monoliths, and you end up with a monolith built around a bunch of microservices.

2. Common tooling has a huge benefit, and copy-pasta code gets the job done faster than everything being custom every time. So you end up with microservices that every task ends up importing some giant framework and uses common libraries - so the monolith gets imported to the microservice.

Software gets complex, faster than we all like to believe... It seems like software has gravity, attracts complexity, and ends up being a big ball of mud in the end, almost every time.

Re: Don't start with microservices – monoliths are your friend

#372

Post by tabtab »

mastazi wrote: post #348

Microservices doesn't necessarily mean K8S running on self-managed compute instances as in the example given in the article. The main mistake of the article is that the premise is "microservices" but then the examples are about infrastructure (K8S etc), but the 2 things are not tied, you can have that same architecture cited in the article running monolith instances for example, and it would be every bit as complex a…

"Microservice" is inconsistently defined. One cannot accuse them of using a strawman definition if there is no realman.

Re: Don't start with microservices – monoliths are your friend

#373

Post by misterbwong »

ozim wrote: post #229
KronisLV wrote: post #104

I wonder why no one ever talks about architectures in the middle between those two - modular monoliths. The point in time where you're splitting your codebase up in modules (or maybe are a proponent of hexagonal architecture and have designed it that way from the beginning), leading to being able to put functionality behind feature flags. That way, you can still run it either as a single instance monolith, or a set o…

Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Micro services were not an answer to monolith being bad. Something somewhere went really wrong with people's understanding and there is bunch of totally wrong ideas. That is also maybe because a lot of people did not knew they were supposed to make modules in their code and loads of m…

Agree. IMO modularity/coupling is the main issue. My issue w/ the microservice architecture is that it solves the modularity problem almost as a side effect of itself but introduces a whole host of new ones that people do not anticipate.

Yes, if you, at the outset, say we will separate things into separate services, you will get separated services. However, you do NOT need to take on the extra complexity that comes with communication between services, remote dependency management, and additional infrastructure to reduce coupling.

Re: Don't start with microservices – monoliths are your friend

#374

Post by johnnymonster »

Avoid any advice that touts itself as gospel! Do your own DD for the product or services you’re building. Maybe you’re never going to hit more than 100 users in total or maybe you’re building a static website. Take some time and evaluate the pros and cons of your architecture and seek advice from those who have come before you!

Re: Don't start with microservices – monoliths are your friend

#375

Post by tabtab »

rp1 wrote: post #145
KronisLV wrote: post #104

I wonder why no one ever talks about architectures in the middle between those two - modular monoliths. The point in time where you're splitting your codebase up in modules (or maybe are a proponent of hexagonal architecture and have designed it that way from the beginning), leading to being able to put functionality behind feature flags. That way, you can still run it either as a single instance monolith, or a set o…

There is a more serious downside that you don’t mention: splitting things into modules takes time and involves making decisions you likely don’t know the answer to. When starting a new product, the most important thing is to get something up and running as quickly as possible so that people can try it and give you feedback. Based on the feedback you receive, you may realize that you need to build something quite diff…

> Speed [of delivery] is often the most important factor.

Depends on the org and the app type. If banks "moved fast and broke things" using millions of dollars, they'd be shut down or sued into oblivion. If it's merely showing dancing cats to teeny-boppers, sure, move fast and break things because there's nothing of worth being broken.

Re: Don't start with microservices – monoliths are your friend

#376

Post by Retric »

jameshart wrote: post #367
Retric wrote: post #358

Earlier quoted context omitted.

It’s not that odd. Databases, print servers, or web servers for example do something similar with multiple copies of the same software running on a network with different settings. Using a single build for almost identical services running on classified and unclassified networks is what jumps to mind.

To what end? Code reuse?

It can be. If you have two large services that need 99+% of the same code and their built by the same team it can be easier to maintain them as a single project.

A better example is something like a chain restaurant running their point of sale software at every location so they can keep operating when the internet is out. At the same time they want all that data on the same corporate network for analysis, record keeping, taxes etc.

Re: Don't start with microservices – monoliths are your friend

#377

Post by Gigachad »

drbojingle wrote: post #321

Guy who hates micro services here (worked at a startup that tried to adopt them because the CTO's consulting friend who works in enterprise convinced him of how great it was). From what I can tell, micro services are primarily a solution to an organizational problem and not a technical one and I think people trip over this. If you have 600 developers working on the same back-end then you can benefit from micro servic…

It's not just communication issues. Things like framework and library updates become extremely difficult when the app is so large it is beyond comprehension for a single person. Multiple smaller upgrades are easier than one massive one. Especially when you have people working on it at the same time you try to update it.

Re: Don't start with microservices – monoliths are your friend

#378

Post by [deleted] »

KronisLV wrote: post #104

I wonder why no one ever talks about architectures in the middle between those two - modular monoliths. The point in time where you're splitting your codebase up in modules (or maybe are a proponent of hexagonal architecture and have designed it that way from the beginning), leading to being able to put functionality behind feature flags. That way, you can still run it either as a single instance monolith, or a set o…

[deleted]

Re: Don't start with microservices – monoliths are your friend

#379

Post by mastazi »

tabtab wrote: post #372
mastazi wrote: post #348

Microservices doesn't necessarily mean K8S running on self-managed compute instances as in the example given in the article. The main mistake of the article is that the premise is "microservices" but then the examples are about infrastructure (K8S etc), but the 2 things are not tied, you can have that same architecture cited in the article running monolith instances for example, and it would be every bit as complex a…

"Microservice" is inconsistently defined. One cannot accuse them of using a strawman definition if there is no realman.

I disagree, microservices are an architectural concept related to the software, not to the infrastructure.

Whether you are using containers or VPS or serverless or bare metal for your infrastructure, that's completely unrelated to the concept of microservices: you can deploy either a monolith or microservices in any of the above.

As an example you can deploy a monolith on Lambda[1] or you can deploy microservices on bare metal using one of the several self managed serverless engines available[2].

[1] see e.g. https://claudiajs.com/tutorials/serverless-express.html or https://blog.logrocket.com/zappa-and-aws-lambda-for-serverle...

[2] see e.g. https://fnproject.io/ and https://knative.dev/

Re: Don't start with microservices – monoliths are your friend

#380

Post by IshKebab »

andrewmutz wrote: post #340
notJim wrote: post #312

Earlier quoted context omitted.

> Refactor to separate microservices when either: 1) the team is growing and needs to split into multiple teams I've heard this before, and I just don't get it. I've worked on multiple monoliths where hundreds of engineers contribute, and it's fine. You have to invest a bit in tooling and recommended patterns to keep things from going crazy, but you kind of need to do that either way. > At 35-50 people a common limit…

When you had hundreds of engineers contributing, how did you manage releases? We have a large number of teams working on a shared monolith, and a large number of teams working with separately releasable services. One of our main drivers transitioning to the latter is the productivity gains that the teams get when they can release just a single set of changes on their own and release them on-demand (and during busines…

Presumably the idea is that you make all changes backwards compatible with the currently running version and continuously roll them out in a progressive manner (like 1% of users get the new version, then 10%, etc.).
Post reply on HN