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

451–460 of 468 posts

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

#451

Post by blippage »

There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity. -- Fred Brooks

Sussman summed up the problem nicely: "We really don't know how to compute!" So we latch onto whatever semi-plausible idea some consultant cooks up, like flowcharts, structured programming, agile, object-oriented programming, test-driven development, microservices, and countless other things.

Microservices impose a transport layer over whatever it is you were doing before. So that's one extra point of failure that you've got to contend with. Complex problems require complex solutions. Sure, there are better and worse ways of doing things, but there are no miracles.

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

#452

Post by bayesian_horse »

mbrodersen wrote: post #445
bayesian_horse wrote: post #118

Earlier quoted context omitted.

I think you didn't quite get the point of engineers of different levels of quality, talent and opinions working on the same monoliths. Eventually they tear down any boundary, even those in the build system. Developer discipline is something that eludes many companies for lack of enough high quality engineers and awareness for the problem in upper management. It's easier to quibble over formatting guidelines.

So your argument is that bad developers will mess things up. I am sure most would agree with that argument. What does that have to do with monolith vs. micro-services? Bad developers will make a mess of micro-services as well.

Yes, the original argument was that boundaries can't be enforced. Arguably, it is easier to enforce boundaries between microservices.

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

#454

Post by zbentley »

jameshart wrote: post #354
KronisLV wrote: post #311

Earlier quoted context omitted.

This actually feels like a good example of the modularity that i talked about and feature flags. Of course, in some projects, it's not what one would call a new architecture (like in my blog post), but rather just careful usage of feature flags. > But all those data sources are connected to from the same runtime, right? Surely you could have multiple instances of your monolithic app: # Runs internally app_instance_1_…

You're talking about something very odd here... a monorepo, with a monolithic build output, but that... transforms into any of a number of different services at runtime based on configuration? Is this meant to be simpler than straight separate codebase microservices?

This is actually quite a nice sweet spot on the mono/micro spectrum. Most bigger software shops I've worked at had this architecture, though it isn't always formally specified. Different servers run different subsets of monolith code and talk to specific data stores.

The benefits are numerous, though the big obvious problem does need a lot of consideration: with a growing codebase and engineering staff, it's easy to introduce calls into code/data stores from unexpected places, causing various issues.

I'd argue that so long as you pay attention to that problem as a habit/have strong norms around "think about what your code talks to, even indirectly", you can scale for a very long time with this architecture. It's not too hard to develop tooling to provide visibility into whats-called-where and test for/audit/track changes when new callers are added. If you invest in that tooling, you can enforce internal boundaries quite handily, while sidestepping a ton of the organizational and technical problems that come with microsevices.

Of course, if you start from the other end of the mono/micro spectrum and have a strong culture of e.g. "understand the service mesh really well and integrate with it as fully as possible" you can do really well with a microservice-oriented environment. So I guess this boils down to "invest in tooling and cultivate a culture of paying attention to your architectural norms and you will tend towards good engineering" ... who knew?

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

#455

Post by zbentley »

sbysb wrote: post #292
rco8786 wrote: post #257

Earlier quoted context omitted.

> Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Yes! Thank you. The "modular monolith" is just "decent separation of concerns in your code" and should be there from the start.

I would actually disagree - to me you can have "decent separation of concerns in your code" but still have only built the app to support a single entry point. "Modular monolith" to me is a system that is built with the view of being able to support multiple entry points, which is a bit more complex than just "separating concerns"

If your concerns are well separated in a monolith (in practice this means being able to call a given piece of functionality with high confidence that it will only talk to the data stores/external resources that you expect it will), adding new entry points is very easy.

Now, it's not trivial--going from, say, a do-everything webserver host to a separation of route-family-specific web servers, background job servers, report processing hosts, and cron job runners does require work no matter how you slice it--but it's a more or less a mechanical or "plumbing" problem if you start from a monolithic codebase that is already well behaved. Modularity is one significant part of said good behavior.

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

#456

Post by hakfoo »

I feel like a lot of microservice advocates fail to price in the overhead introduced when you split stuff up into multiple independent communicating units.

Example: Replacing a simple database query (effectively instant) and relaying the data as a local variable, with poking a seperately hosted microservice which ends up adding 20ms of overhead doing a HTTPS request, encoding and de-encoding the result in JSON, etc.

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

#457

Post by lucian1900 »

randomswede wrote: post #416
stickfigure wrote: post #365

Earlier quoted context omitted.

My theory is that microservices became vogue along with dynamically typed languages. Lack of static types means that code becomes unmanageable at a much lower level of complexity. So the complexity was "moved to the network", which looks like a clear win if you never look outside a single component.

The archetypical "microservice" ecosystem I am aware of is Google's production environment. It was, at that point, primarily written in C++ and Java, neither very famous for being dynamically typed. But, it was a microservice architecture built primarily on RPCs and not very much on message buses. And RPCs that, basically, are statically typed (with code generation for client libs, and code generation for server-side…

Or you can deploy your monolith several times, for each scaling profile.

That’s not a reason to do micro services.

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

#458

Post by nijave »

staticassertion wrote: post #391
api wrote: post #366

Earlier quoted context omitted.

I've wondered if it's not a ploy by cloud vendors and the ecosystem around them to increase peoples' cloud bills. Not only do you end up using many times more CPU but you end up transferring a lot of data between availability zones, and many clouds bill for that. A microservice architecture also tends to lock you into requiring things like Kubernetes, further increasing lock-in to the managed cloud paradigm if not to…

> I've wondered if it's not a ploy by cloud vendors and the ecosystem around them to increase peoples' cloud bills. Not only do you end up using many times more CPU but you end up transferring a lot of data between availability zones, and many clouds bill for that. Disagree. I'd argue that microservices are inherently more cost effective to scale. By breaking up your services you can deploy them in arbitrary ways, es…

Yeah, the ops side of microservices is important.

More granular scaling. Scaling up instances of 8, 16, 32GB or even larger instances is much more expensive than 1,2,4GB instances. In addition, monoliths tend to load slower since there's more code being loaded (so you can't scale up in sub minute times)

Obviously there's lazy loading, caching, and other things to speed up application boot but loading more code is still slower

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

#459

Post by nijave »

Gigachad wrote: post #377
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.

Not only that, extremely risky. It's an "all or nothing" approach versus starting at low risk and moving up.

I think this is really important to remember with log4j and other vulnerabilities cropping up. It really sucks updating a single dependency version and having your dependency tree explode in conflict. It sucks even more when that prevents you from updating all your apps since they're all part of the same monolithic codebase

Post reply on HN