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

91–100 of 106 posts

Re: Make microservices look like monoliths

#91

Post by friendly_chap »

anilakar wrote: post #70

Monolithic microservices look like a perfect anti-pattern. Worst of the both worlds, so to say.

Not much is monolithic about this tbh. It's just trying to hide the architecture implementation detail (monolith vs microservices) instead of exposing it like most existing frameworks.

IMHO the monolithic microservice (or distributed monolith) is when you don't have firm service boundaries - eg. services can read each other data if they want, sidestepping endpoints/handlers.

Actio avoids that mistake. Each service has its own database.

Re: Make microservices look like monoliths

#92

Post by papito »

mabbo wrote: post #15
civilitty wrote: post #11

How about just stop making microservices and go back to monoliths? Then you don’t have to shoehorn two things at the same time!

I spent a decade at Amazon (SOA all the things!) and then a year and a half at Shopify (single Rails monolith for all the things!). I think both strategies have pros and cons. But critically, you need a company culture that supports whichever choice you've made. If you have a company where each team gets to totally decide how they want to implement their stuff, sharing a monolith between teams can create a mess. Owne…

I have yet to work at a company where teams were so discipled in their silo with API version control and backward compatibility that it did not require cross-team alignment. This is largely a theory and a myth.

Re: Make microservices look like monoliths

#93

Post by wizofaus »

jamesfinlayson wrote: post #62
wizofaus wrote: post #43

Earlier quoted context omitted.

Are there actually many real-life examples of large-scale microservices architecture operating successfully with a range of different languages in use? I did (briefly) work at such a shop, I can't say the experience was particularly rewarding, but I was expected to be on top of ALL said languages/stacks and their various idiosyncrasies etc., and much of the code was pretty poorly written. Arguably the biggest challen…

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?

Re: Make microservices look like monoliths

#94

Post by StackOverlord »

danjac wrote: post #84
88913527 wrote: post #52

Earlier quoted context omitted.

Most (successful) paths lead to balkanization. Just one acquisition can do it, much less 2 or N more. And the pace of these changes can outpace your ability to respond to it, which makes fighting it a losing battle.

That's a "nice to have" problem down the line. What I've seen is the insanity of microservices being adopted by one-pizza-team startups.

Been there, except I was the pizza being eaten by 5 microservices.

Re: Make microservices look like monoliths

#95

Post by RamblingCTO »

migf wrote: post #88
RamblingCTO wrote: post #87

Why on earth would you use javascript for that? There are way better alternatives out there like Go, Erlang, Kotlin, or any other of the typical backend languages. Is it too much to ask for frontend devs to learn a new language?

Works great for applications where you spend most of the time waiting for a database. The dynamic type system makes it easier to write testable code with less abstraction overhead. Faster to train up junior devs. That said, you * must * set up the codebase with appropriate guard rails or bad things can happen.

> Works great for applications where you spend most of the time waiting for a database.

You mean callback hell? :P

> The dynamic type system makes it easier to write testable code with less abstraction overhead.

My biggest issue with js/ts is that there's nothing really enforcing good code, unless you decide to adhere to it. Also: npm is utter garbage.

> Faster to train up junior devs. I think go is better in that regard, less random happenings.

But yeah, in general I get what you mean!

Re: Make microservices look like monoliths

#96

Post by gumballindie »

civilitty wrote: post #11

How about just stop making microservices and go back to monoliths? Then you don’t have to shoehorn two things at the same time!

Even better, why not go back to modularity? Many microservices could be just that: self contained modules that you can swap in and out as you see fit.

Re: Make microservices look like monoliths

#97

Post by tail_exchange »

civilitty wrote: post #11

How about just stop making microservices and go back to monoliths? Then you don’t have to shoehorn two things at the same time!

It's really disappointing to see this kind of lazy oversimplification being the top comment on HN, as if monoliths were perfect and microservices didn't have any advantages over them.

Yes, maybe the company you work at does not have a good reason to use microservices. But this doesn't mean the same goes for the rest of the industry. Being a nay-sayer and rejecting microservices in any circumstances is just as unreasonable as rejecting monoliths.

Re: Make microservices look like monoliths

#98

Post by civilitty »

tail_exchange wrote: post #97
civilitty wrote: post #11

How about just stop making microservices and go back to monoliths? Then you don’t have to shoehorn two things at the same time!

It's really disappointing to see this kind of lazy oversimplification being the top comment on HN, as if monoliths were perfect and microservices didn't have any advantages over them. Yes, maybe the company you work at does not have a good reason to use microservices. But this doesn't mean the same goes for the rest of the industry. Being a nay-sayer and rejecting microservices in any circumstances is just as unreaso…

> 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 dozen companies. They’ve got a worse track record than techbro management. Literally the only time I’ve seen the architecture work well was when I was working at Azure on cloud infrastructure with a dozen teams working on a single product. The vast majority of developers never work on a project of that size and yet try to cargo cult microservices into companies with less than a dozen devs, let alone teams.

Maybe your company is one of the few companies where microservices make sense (or you haven’t come to grips with the stockholm syndrome yet), but the hype around microservices have been a disaster for many more companies than they have helped in my career

Re: Make microservices look like monoliths

#99

Post by tail_exchange »

civilitty wrote: post #98
tail_exchange wrote: post #97

Earlier quoted context omitted.

It's really disappointing to see this kind of lazy oversimplification being the top comment on HN, as if monoliths were perfect and microservices didn't have any advantages over them. Yes, maybe the company you work at does not have a good reason to use microservices. But this doesn't mean the same goes for the rest of the industry. Being a nay-sayer and rejecting microservices in any circumstances is just as unreaso…

> 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 seen momentum being killed by microservices in smaller startups, and I've also seen large organizations operating with microservices wonderfully.

My beef with this kind of comment is that it kills any interesting discussion about architecture into a "don't use microservices" circlejerk, which is not helpful to people who actually want to dive into this kind of architecture. As you said yourself, microservices do work well for large companies, so why pretend it doesn't?

Re: Make microservices look like monoliths

#100

Post by twisteriffic »

thrtythreeforty wrote: post #51
wizofaus wrote: post #44

Earlier quoted context omitted.

Out of curiosity, do the microservices at Amazon typically call each other in an orchestrated fashion (i.e. microservice A knows it needs some particular functionality and knows to call microservice B to get it), or is in more asynchronous/"choreographed", where requests are available to a general pool of services, each of which handles as they need? It's hard to see how a library like the one posted about here would…

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?"
Post reply on HN