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

Ten Years and Counting: My Affair with Microservices

blog.allegro.tech

Post reply on HN
Print view View original

31–40 of 52 posts

Re: Ten Years and Counting: My Affair with Microservices

#31

Post by cqqxo4zV46cp »

threeseed wrote: post #28
jmugan wrote: post #5

I assume Hacker News has a bot that automatically posts this skit for every microservice article, but it case it doesn't https://www.youtube.com/watch?v=y8OnoxKotPQ . We should all know Galactus' pain.

From experience this happens just as often inside monoliths. It's a symptom of over-engineering and building for the future rather than anything inherent to microservices. Java had a whole decade of being obsessed with design patterns e.g Facade, Decorator that resulted in the same spaghetti architecture.

Microservices invite over-engineering more than monoliths do. Monoliths are more prone to inviting a lack of a structure. That’s kind of…a big potential advantage of microservices, I guess.

Re: Ten Years and Counting: My Affair with Microservices

#32

Post by unclebucknasty »

jmugan wrote: post #5

I assume Hacker News has a bot that automatically posts this skit for every microservice article, but it case it doesn't https://www.youtube.com/watch?v=y8OnoxKotPQ . We should all know Galactus' pain.

The pinned comment on that video is from 4 years ago:

>I'm a junior backend developer and this inspires me a lot to study frontend

Re: Ten Years and Counting: My Affair with Microservices

#33

Post by rpastuszak »

jmugan wrote: post #5

I assume Hacker News has a bot that automatically posts this skit for every microservice article, but it case it doesn't https://www.youtube.com/watch?v=y8OnoxKotPQ . We should all know Galactus' pain.

I always find watching this video surreal because I worked on a microservice called Galactus

Re: Ten Years and Counting: My Affair with Microservices

#34

Post by hmeh »

jokethrowaway wrote: post #18

I've been through similar transformation (just 250 microservices) and I'm not sure the end result was actually better. Microservices are ok if things go well and you can maintain a large army of developers - which you didn't really need in the first place. In my case: Fast forward 5 years and the business growth didn't materialize; the board made working in the content unpleasant enough so that all the good and expen…

For what it's worth, what you are describing is a pretty well known failure mode. It was known in the days of CORBA and DCOM, and then again in the days of SOAP web services. Microservices as a distributed monolith is not how you partition things if you want to gain productivity and be successful. Literally everything you mention other than updating shared libraries are problems that our team does not have and yet we have around 100 autonomous back end components and over 20 web applications maintained with a team of around 15. We've never felt like there were too many, because usually you don't have to touch most of them. You only have to touch the one or ones that are relevant to your work.

Imagine eliminating network joins (make sure all the data is where it needs to be and/or share a database for reads, which is totally doable)... and eliminating dead letter queues (make sure your service goes offline/retries indefinitely if there is a failure and fix it. Don't tolerate failures. See jidoka)... and don't let services talk to each other (see pub/sub and event sourcing). Oh, and also limit the number of times updating a single library must be applied to all services by getting things as close to right as you can and respecting the physics of software design (see afference and efference).

Re: Ten Years and Counting: My Affair with Microservices

#35

Post by nadermx »

jmugan wrote: post #5

I assume Hacker News has a bot that automatically posts this skit for every microservice article, but it case it doesn't https://www.youtube.com/watch?v=y8OnoxKotPQ . We should all know Galactus' pain.

For some reason that video's genius reminds me this, https://m.youtube.com/watch?v=b6LKNTJN3Ug

Re: Ten Years and Counting: My Affair with Microservices

#36

Post by AtlasBarfed »

pylon wrote: post #17

Having 1000+ services seems like an overkill for an ecommerce company. I certainly hope they aren't doing something silly like a service for each payment type or a service to manage inventory and another service to manage orders.

Amazon probably has 10,000 services or more.

Re: Ten Years and Counting: My Affair with Microservices

#37

Post by bobthepanda »

cqqxo4zV46cp wrote: post #31
threeseed wrote: post #28

Earlier quoted context omitted.

From experience this happens just as often inside monoliths. It's a symptom of over-engineering and building for the future rather than anything inherent to microservices. Java had a whole decade of being obsessed with design patterns e.g Facade, Decorator that resulted in the same spaghetti architecture.

Microservices invite over-engineering more than monoliths do. Monoliths are more prone to inviting a lack of a structure. That’s kind of…a big potential advantage of microservices, I guess.

the theoretically nice thing about microservices is that because the API boundary should be well defined, any possible application that can fulfill that API, whether it's Java, Rust, or three raccoons in a trench coat can become the new microservice fairly easy.

Re: Ten Years and Counting: My Affair with Microservices

#38

Post by claytongulick »

rezonant wrote: post #9

I missed the part where the person describes that they have a very large development team which justified a non-monolithic architecture. True microservices (with independent development and inter-service contracts) are a reflection of the makeup and scale of the development team. Using true microservices for performance reasons is a misnomer these days: A modular monolith (one codebase that can be deployed into multi…

> True microservices (with independent development and inter-service contracts) are a reflection of the makeup and scale of the development team.

Conway's Law [1]:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

— Melvin E. Conway, How Do Committees Invent?

[1] https://en.m.wikipedia.org/wiki/Conway%27s_law

Re: Ten Years and Counting: My Affair with Microservices

#39

Post by brtkdotse »

threeseed wrote: post #28
jmugan wrote: post #5

I assume Hacker News has a bot that automatically posts this skit for every microservice article, but it case it doesn't https://www.youtube.com/watch?v=y8OnoxKotPQ . We should all know Galactus' pain.

From experience this happens just as often inside monoliths. It's a symptom of over-engineering and building for the future rather than anything inherent to microservices. Java had a whole decade of being obsessed with design patterns e.g Facade, Decorator that resulted in the same spaghetti architecture.

At least with a monolith, all of your ball of mud is in-process.

Re: Ten Years and Counting: My Affair with Microservices

#40

Post by javanonymous »

cqqxo4zV46cp wrote: post #31
threeseed wrote: post #28

Earlier quoted context omitted.

From experience this happens just as often inside monoliths. It's a symptom of over-engineering and building for the future rather than anything inherent to microservices. Java had a whole decade of being obsessed with design patterns e.g Facade, Decorator that resulted in the same spaghetti architecture.

Microservices invite over-engineering more than monoliths do. Monoliths are more prone to inviting a lack of a structure. That’s kind of…a big potential advantage of microservices, I guess.

That's why moduliths are becoming more popular. These are basically monoliths that enforce structure. The other advantage is that each "module" can be extracted as a micro-service later without much work.
Post reply on HN