Don't start with microservices – monoliths are your friend • Hacker News Board

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

#381

Post by notJim » Thu, Dec 16, 2021, 11:32 PM UTC

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…

At the place where this worked well, we released small changes throughout the day. We released the monolith around 50 times per day. Developers release their own changes in small groups. We deployed the main branch, and only used short-lived (< 1-2 weeks max) branches. Used feature flags to control when customers actually saw the features (as needed.)

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

#382

Post by [deleted] » Thu, Dec 16, 2021, 11:34 PM UTC

actually_a_dog wrote: post #344

outworlder wrote: post #333

Earlier quoted context omitted.

> Micro services were not an answer to monolith being bad Micro services today are mostly used for one purpose: to be able to ship your corporation's org chart.

> Micro services today are mostly used for one purpose: to be able to ship your corporation's org chart. And, this is not necessarily a bad thing.

[deleted]

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

#383

Post by notJim » Thu, Dec 16, 2021, 11:40 PM UTC

trunnell wrote: post #327

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…

Ok, maybe a better way to say it is that having teams independently develop services is a good way to reduce the coordination tax if you have high coordination costs. If your environment doesn't have that problem I guess this doesn't apply. Coordination between engineers was a frequent activity everywhere I've been regardless of how well built the systems were. For example: a new requirement for the customers signing…

> Independent teams (each developing independent services and acting without top-down approval) is a different way to coordinate development that values productivity (keeping everyone unblocked) and innovation (finding better ways of doing things).

I've had the opposite experience. In the monolith, anyone can make the necessary changes, because it's all one codebase that everyone is familiar with. At most, you might need some help/pairing/approvals from experts in particular areas, but in general any team can work independently.

By comparison, in the microservices world, many teams either don't want you to touch their service, or are using a tech stack so unfamiliar to you that it would take too long to be productive. And there's a rat's nest of interdependent microservices, so you end up begging other teams to adjust their roadmap to fit you in.

> Independent teams can pursue very different patterns without needing to agree with each other.

I see this as more downside than benefit. If everyone is using different tech stacks, it's harder for people to move between and contribute to different teams. And you end up with situations where one team uses Java, while another uses Scala, which brings in extra complexity to satisfy what are essentially aesthetic preferences.

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

#384

Post by dmux » Thu, Dec 16, 2021, 11:41 PM UTC

One problem I've never seen mentioned regarding microservices is what happens when the organization that produced them has moved from growing to stagnating and finally into decline. If microservices ship the org-chart, what happens when that organization fails to attract engineers?

I worked for a company that microserviced themselves into a pit. We had a huge layoff which completely killed the morale of the remaining engineering staff. Over the next 3 years, more and more engineers left and the company refused to replace them. What started out as teams (~5 people) responsible for ~3 microservices ended up as teams of ~3 people responsible for ~6 microservices.

It was kind of cool to be responsible for more architecture and see how it all fit together, but the sad reality was that too many of the microservices that had been stood up were stitching together disparate data from other microservices to then perform what a single SQL query against a RDBMS was doing.

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

#385

Post by phlakaton » Thu, Dec 16, 2021, 11:54 PM UTC

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…

The problem with modular monoliths is the relative difficulty of managing dependencies in the code. It’s easy to hack the modular interfaces or expose internals, which can make it hard to maintain and painful to pull out into another service down the road.

“But I would never hack an interface like that!” you say. Oh, you sweet summer child.

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

#386

Post by [deleted] » Fri, Dec 17, 2021, 12:27 AM UTC

[deleted]

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

#387

Post by rtpg » Fri, Dec 17, 2021, 12:56 AM UTC

__jem wrote: post #254

rtpg wrote: post #222

Earlier quoted context omitted.

one strong operational reason I have seen recently is resource management. The monolith where most API endpoints are instant and use constant memory, but some use much more memory and can be slower... is tough.Like if you just give a bunch of memory to each process now you're overprovisioning and if you try to be strict you run into quality of service issues. If you split out homogenous API endpoints into various gro…

At the same time, you have to be at a pretty huge scale before resource over-provisioning really hurts the bottom line. You can buy a lot of compute for the price of a single engineer's salary, and it usually takes more than one engineer to support a microservice architecture. Most applications hit problems scaling the database vertically long before they exhaust resources at the application level.

Hmm I get what you’re saying of course but in certain domains (think B2B SaaS) you might be running some compute-intensive stuff enough to where the differential is an issue.

Imagine 95% of your workload can run in 100 megs but 5% requires 1000 megs. You can overprovision of course but in a world of containers if you can isolate the 5% and route it you’re going to have a lot less in terms of operational headaches

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

#388

Post by Seb-C » Fri, Dec 17, 2021, 12:56 AM UTC

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…

Absolutely agree. The point of microservices is to separate the concerns from an organizational point of view, not for technical reasons.

Most of the advantages attributed to microservices can also be achieved with a monolith architecture using a sane and rigorous design.

I find it frustrating at work when I see teams of 50 people having issues coordinating work because they have a monolith, while we often unnecessarily spread a team of 5 people among 10 microservices.

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

#389

Post by ezekiel68 » Fri, Dec 17, 2021, 1:02 AM UTC

I've been a professional programmer since the late 1990s. What I observe is that many people flocked to microservices because they had only known monoliths and they were sick of the limitations inherent to them. Now we have a generation of engineers who have only known (or been taught) microservices and a backlash has developed because they are sick of the limitations inherent to them.

This is my reading of the anti-OOP / anti-inheritance movement as well. To spice up Bjarne Stroustrup (inventor of c++), "There are only two kinds of programming languages: those that don't make it and those that people bitch about."

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

#390

Post by [deleted] » Fri, Dec 17, 2021, 1:08 AM UTC

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…

[deleted]