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

261–270 of 468 posts

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

#261

Post by sokoloff »

ravenstine wrote: post #238
ozim wrote: post #229

Earlier quoted context omitted.

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…

> monolith was always supposed to be MODULAR from the start Well, that certainly is sensible, but I wasn't aware that someone had to invent the monolith and define how far it should go. Alas, my impression is that the term "monolith" doesn't really refer to a pattern or format someone is deliberately aiming for in most cases, but instead refers to one big execution of a lot of code that is doing far more than it shou…

> or is reasonable for one repository to manage

The amount of code one repository can reasonably manage is quite large. (Linux, Google, Microsoft, Facebook, and others...)

https://en.wikipedia.org/wiki/Monorepo

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

#263

Post by Kiro »

sdevonoes wrote: post #40
jhoelzel wrote: post #9

There is a lot of talk about monoliths vs microservices lately.. I just want to throw into the ring that you can do both at the same time. easily. And noone is going to kill you for it either. maybe we are getting caught up in sematics because its christmas, but "monorepo/monolith/microservices/etc" is -just- the way you organize your code. Developing a montolith for years but now you have written a 15 line golang ht…

> Developing a montolith for years but now you have written a 15 line golang http api that converts pdfs to stardust and put it into on a dedicted server in your office? welp thats a microservice. But the 15 lines of Golang are not just 15 lines of Golang in production. You need: - auth? Who can talk to your service? Perhaps ip whitelisting? - monitoring? How do you know if you service is up and running? If it's down…

You don't need any of that stuff.

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

#265

Post by SkyPuncher »

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…

> Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start.

Unless you're in a large established org, modulatity is likely a counter-goal. Most startups are looking to iterate quickly to find pre-PMF. Unless you write absolutely terrible code, my experience is you're more likely to have the product cycle off a set functionality before you truly need modularity. From there, you either (1) survive long enough to make an active decision to change how you work (2) you die and architecture doesn't matter.

"Modular monolith" is a nice framing for teams who are at that transition point.

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

#267

Post by chasd00 »

dboreham wrote: post #214
daitangio wrote: post #120

Earlier quoted context omitted.

Thank you for sharing, and I agree with you- In my humble opinion microservices are "hot" because in theory you can scale a lot with them if you are able to do cloud provisioning. Microservices needs DevOps+Orchestration Service. A good example of microservices architecture is how K8s is designed: I think it is an overkill for most average needs, so think twice before entering in microservice trip tunnel.

Microservices solve pretty much one problem: you have a larger organization (> 10 devs, certainly > 100) and as a result the coordination overhead between those devs and their respective managers and stakeholders is significantly limiting overall forward progress. This will manifest in various concrete ways such as "microservices allow independent component release and deployment cycles" and "microservices allow fine…

i always think of microservices as a product an organization offers to itself. If you don't have the team including managers and even marketing to run an internal product then you probably shouldn't be doing the microservice thing.

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

#268

Post by trunnell »

Former Netflix engineer and manager here. My advice:

Start a greenfield project using what you know (unless your main goal is learning) keeping things as simple as possible.

Microservices is more often an organization hack than a scaling hack.

Refactor to separate microservices when either: 1) the team is growing and needs to split into multiple teams, or 2) high traffic forces you to scale horizontally.

#1 is more likely to happen first. At 35-50 people a common limiting factor is coordination between engineers. A set of teams with each team developing 1 or more services is a great way to keep all teams unblocked because each team can deploy separately. You can also partition the business complexity into those separate teams to further reduce the coordination burden.

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

#269

Post by bborud »

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…

In my experience, long build times mostly come from not caring about build times. Not from large codebases. A surprising number of developers don't think build times (including running all the tests) are important. They'll just go "ok, so now it takes N minutes to build" rather than thinking "hold on, this shouldn't take more than a few seconds - what's going on here?"
Post reply on HN