Microservices – State of Developer Ecosystem 2022 (JetBrains) (opens in new tab)

> 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.

> 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.

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.

I'm taking time out of the industry and doing other stuff. When it finally works out that it's not a viable approach for perhaps 90% of the products out there I'm going to come back and sell exit strategies.

It is all the rage on enterprise products now, see headless CMS and MACH architecture, coupled with product vendors SaaS offerings instead of on premises installations.

The percentages don't add up to 100%. Multiple answers were allowed, so it is possible that one developer works on both monolithic and microservice based projects.

Perhaps more people have read and understand the "4+1 architectural view model" paper than I had hitherto realised.

You may be surprised, but in Europe, it's difficult to find a company that doesn't use Java (or .Net).

Node does exist, but it's not where the money is.

This is a survey conducted by JetBrains, whose primary product is a Java/Kotlin IDE. They do support other languages, but their audience is almost certainly skewed toward JVM users.

I would be eager to see if Rust starts to show up on the list too.