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

Make microservices look like monoliths

github.com

Post reply on HN
Print view View original

101–106 of 106 posts

Re: Make microservices look like monoliths

#101

Post by jamesfinlayson »

wizofaus wrote: post #93
jamesfinlayson wrote: post #62

Earlier quoted context omitted.

I've worked at a place where it was a case of choose what you want - there's lots of C#, Python and Javascript, some Go but there's still Scala and CoffeeScript lurking around, as well as some other more esoteric stuff that seemed like a good idea at the time.

Would you describe it as a "large-scale microservices architecture operating successfully" though?

Yes and no - it definitely runs and makes a lot of money, but sometimes things mysteriously go wrong and no one quite knows why (service x is running slowly because service y is running slowly because service z is running slowly and no one knows why service z is running slowly), and it's reached a point where most new work is done in yet another microservice, so headcount keeps slowly growing (usually throwing more offshore contractors at it) to deal with the problem.

Re: Make microservices look like monoliths

#102

Post by civilitty »

tail_exchange wrote: post #99
civilitty wrote: post #98

Earlier quoted context omitted.

> Being a nay-sayer and rejecting microservices in any circumstances is just as unreasonable as rejecting monoliths. No. No no no no! Monoliths (modular or otherwise) are the default and if you have to ask, you don’t need microservices. Period. That’s not a lazy oversimplification, that’s hard earned experience. In over 15 years I’ve seen microservices singlehandedly kill the engineering momentum at nearly half a doz…

> No. No no no no! Monoliths (modular or otherwise) are the default and if you have to ask, you don’t need microservices. Period. That’s not a lazy oversimplification, that’s hard earned experience. But this is not what I am arguing. Yes, monoliths are the default, and unless you reached the point where you have thousands of engineers and teams working completely independently, you don't need microservices. I've also…

> As you said yourself, microservices do work well for large companies, so why pretend it doesn't?

Same reason we don't teach people anything about driving an 18 wheeler when they apply for their regular driver's license. A small minority of drivers will ever even have to think about the topic and when they do, they'll seek out a specialized trucker school or their employer will guide them through the process using institutional knowledge. There is zero value to exposing people with learner's permits to the nuances of driving massive trucks.

Unlike the truckers, however, tech bloggers have hyped up the concept of microservices as a panacea to all developers, resulting in a disastrous cargo cult. There is no interesting conversation to be had about microservices in this context. That discussion is going to be had with all the other senior-most engineers in an organization because any org incapable of such an in-depth discussion internally should not be using microservices.

Re: Make microservices look like monoliths

#103

Post by ecshafer »

twisteriffic wrote: post #100
thrtythreeforty wrote: post #51

Earlier quoted context omitted.

It is definitely the first one. Microservices at AWS typically grow boundaries at team boundaries, even if it would make much more technical sense for them to be combined. Each team knows which other team provides the APIs they need. (Under the hood, the service may in fact be distributed to a large pool of resources. But a microservice doesn't shout into a void "hey could someone please handle a LaunchInstanceInRegi…

How do they avoid cycles in calls to dependencies? Some golden rule of "thou shalt only call services that are less abstract than thyself?"

In my experience building these type of microservices, it just doesn't really happen often. Team A is responsible for customer data, Team B is responsible for inventory data, so you are usually don't have situations where A calls B and vice versa. The checkout service knows to call A and B.

Re: Make microservices look like monoliths

#104

Post by ecshafer »

mjr00 wrote: post #29
ars wrote: post #21

My issue with microservices isn't the network calls, it's the extra work to keep the source code up to date. New spring library? Have fun applying the same changes to 14 different microservices. Microservices might make sense with completely different teams developing them - but multiple microservices in the same team, with the services talking to each other, really doesn't make sense.

> New spring library? Have fun applying the same changes to 14 different microservices. On the flip side, at some point monoliths can get large enough that upgrading libraries or runtimes becomes an incredibly difficult problem. When I was at Amazon a major service was finally getting upgraded from Java 7 to Java 8. Took a cross-functional team 6 months (!) to make it happen due to the massive amounts of existing cod…

The trick is to always be keeping your monoloith up to date on the latest tech. Shopify's monolith is always on the latest Ruby and Rails versions. I have worked at a place where the monolith was on Java 6 while Java 9 was out, so it is a valid concern. But if you are doing constant updates, it makes it more manageable.

Re: Make microservices look like monoliths

#105

Post by javanonymous »

ars wrote: post #21

My issue with microservices isn't the network calls, it's the extra work to keep the source code up to date. New spring library? Have fun applying the same changes to 14 different microservices. Microservices might make sense with completely different teams developing them - but multiple microservices in the same team, with the services talking to each other, really doesn't make sense.

At one of my previous jobs, they had a "BOM" that each service inherited from. This contained most of the core dependencies (Spring, database drivers, logging, monitoring, auth, service discovery etc.) with a default configuration that worked in all environments. This was built on top of Spring Boot, so if you needed to use Postgresql, you just added the basic database configuration to your property file and the BOM would make sure that the necessary beans and service discovery was loaded.

This meant upgrades were usually as simple as increasing the version, as the infrastructure team had already made sure that the other dependencies had been tested. Each team were free to ignore this and do whatever they wanted, but the benefits were too great to ignore for most teams.

At my current job we don't have this type of shared configuration, which makes micro services much harder to maintain.

Re: Make microservices look like monoliths

#106

Post by javanonymous »

Quekid5 wrote: post #67
wizofaus wrote: post #45

Earlier quoted context omitted.

One major criticism I have of the way modules work in many stacks is that the dependencies between modules are hard to visualise and/or manage. Certainly in the C#/.NET world it's very easy to accidentally end up with one module depending on another that depends on the initial module via some chain of dependencies. And it's too easy to add extra dependencies to some low-level module that's supposed to be a "core" bas…

Exactly. On the JVM (at least, dunno if C#/.NET has a similar mechanism) you can technically get away with using OSGi which can load things into separate classloaders along with all implementation-dependencies such that you can truly separate the API of a dependency from its implementation. Alas, support for OSGi in the general ecosystem is abysmal, and the next best thing seems to be microservices. Honestly, I find…

Spring Modulith is trying to enforce strict module boundaries.

I haven't yet tried it myself, but it looks promising:

https://spring.io/blog/2022/10/21/introducing-spring-modulit...

Post reply on HN