Hacker News Reader

Comment by jokethrowaway | Hacker News Reader

Microservices can be done right - but then they're just Service Oriented Architecture.

As a concept, they have been one of the most toxic concepts to be released on the tech world.

I remember a conference where some influential person had a slide "if your service doesn't fit on a slide, it's too big".

I've seen literal devastation in multiple companies coming from inept technical leaders who drank the microservices koolaid and ended up with 10 services per team, slower services and having to do implement JOINs over network.

Those teams not only had to 10x the maintenance work, they also had to solve new problems they wouldn't have with the right service split.

Ignore buzzwords and influential speakers who stopped coding in 90s. Split services based on how your people are split across teams.

It seems like people are coming back on their senses though, we must be in the plateau phase of the hype cycle.

View on HN

> Microservices can be done right - but then they're just Service Oriented Architecture.

True.

> As a concept, they have been one of the most toxic concepts to be released on the tech world.

Sadly, I have to agree.

One of the problems is that people assume that Microservices "should be as small as possible" when they should be "Small enough that a small team can own them"

> I've seen literal devastation in multiple companies coming from inept technical leaders who drank the microservices koolaid and ended up with 10 services per team, slower services and having to do implement JOINs over network.

I just joined this team (7 developers). We have 48 components with 48 repos. Engineers are VERY competent on an individual level but the maintenance burden is huge. It is a configuration management nightmare. We are replacing a super critical system. It is burning out the team.

> Ignore buzzwords and influential speakers who stopped coding in 90s. Split services based on how your people are split across teams.

I think it is the younger engineers that think this is the only way because that is what they have seen all their careers. (Since 2012 or so). Some corporate Architects are building great careers out of this chaos. Their architecture diagrams look very impressive. I don know if they are aware or not of the damage.

> It seems like people are coming back on their senses though, we must be in the plateau phase of the hype cycle.

Hopefully. I don want to spend the last five years of my career dealing with this mess.

> One of the problems is that people assume that Microservices "should be as small as possible" when they should be "Small enough that a small team can own them"

I don't know what people should do. It is named as micro service after all.

It is same with Agile cult with endless sprints, stories, epics, sagas, daily scrums, scrum of scrums, scrum master of ceremonies, and what not, people are then told "Do what works in your situation, silly." I mean yeah, it is so simple and straightforward now why didn't everyone think of it before.

I think the failure of most group processes is the leadership's failings. They need the wisdom and technical knowledge to make the right choices, the organizational skill to implement those choices, the authority to implement those choices, and the charisma to bring the team along with them.

I know a lot of people get mad and lash out at Agile in particular, but I don't think the alternative is any more straightforward. Group work is hard.

> I don't know what people should do. It is named as micro service after all.

Totally agree.

They are "micro" only from the point of view of a company that has an application with millions of LOCs and thousands of developers working on it.

> but then they're just Service Oriented Architecture.

This is a disappointment I have, when you mention "normal" services/SOA in past 5-10 years, younger devs assume you mean tiny microservices, and you get caught between monolith vs microservices holy war.

Larger domain services are a huge benefit to many shops, but it has felt like a losing battle recently. Like being a centrist between Democrats vs Republicans in the US.

Having worked on a greenfield microservices project, the joins over the network problem is real (and may indicate bad domain splits).

> Microservices can be done right - but then they're just Service Oriented Architecture.

Thanks for saying this out loud.

Silly me always thought Microservices was just a new word for SOA. What was the difference supposed to be?

You've then been fortunate enough to have never worked at a place where something simple like a "join" requires a call to a separate service.

Suddenly something trivial becomes buzzword-filled chaos. Observability, apm, monitoring, kubernetes, scaling, events, pub sub, api contracts, Kafka, streams, multi repos, build pipelines, github workers, eventual consistency and so on.

> Silly me always thought Microservices was just a new word for SOA.

Lucky you. You were using “Microservices” the right way all the time, without even realising it.

a capital 'M' microservice is a service that is entirely self-contained with its own datastore and everything. It's an architecture that makes sense if you are talking about the 'Orders' component of an e-commerce website but starts to get really weird if you need to share any kind of data between the microservices.

Yep, it can be done right. I’ve been in a team where we had more services than people yet most of the services were just chugging along with little to no maintenance (thanks to most being in a monorepo with few dependencies so the spam of dependencies getting out of date was manageable).

It was a constant uphill battle though, my time was largely spent on trying to prevent the creep of services born out of trying to enforce Conway’s law rather than to contain it’s impact. When people put in the effort of shaping the team/organization around the most optimal architecture rather than shaping out the architecture to fit the organization, it works out rather nicely and yields good productivity and an efficient system. Luckily at the time even ICs like me had enough sway to keep things at check.

SOA is a specific architecture, not a generic pattern name.

It implies things such as an ESB, etc. microservice is a distinct architecture.

Microservices is what you get when you couple the four views explained in the "4+1 architectural view model" paper. Nothing more, nothing less. It's a bad idea, typically.

You can do SOA without an ESB. You don't have to use ESB everywhere to have SOA architecture.

That's true but SOA without an ESB is a very small solution. As that solution grows an ESB will be created whether or not the team thinks of it as an ESB.

When you need an ESB, you can add one to the mix, but it still doesn't mean that you should use it for everything, even if it's not needed.

I agree with that, I'm just pointing out that ESB is a mainstay of SOA but not microservices. The idea that SOA and microservices is the same is a common misconception borne from the idea that SOA is a generic pattern rather than a specific architectural philosophy.

Thankfully there are ESB like solutions for microservices. /s

Reply on news.ycombinator.com