Microservices – State of Developer Ecosystem 2022 (JetBrains) | Hacker News Reader

Microservices – State of Developer Ecosystem 2022 (JetBrains)

jetbrains.com

69 pointsnullxone45 comments

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.

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

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

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

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.

Thankfully there are ESB like solutions for microservices. /s

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.

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

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

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.

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.

So 63% of market still to be captured by microservices. I think it is great for boosting profit at cloud vendors, APM vendors, service mesh and so on.

If I had made big tech level money, there is no better time to retire and move away from tech for me.

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.

Do we really want another religious war over microservices vs monoliths?

Count me out. I'll adopt each for appropriate use cases.

> Do we really want another religious war over microservices vs monoliths?

I guess not since microsevices have won already.

From where I stand it's the opposite. 5 years ago microservices were cool, now it's just the banks and telecomms adopting them, while the others realise sometimes they're useful, sometimes a monolith is useful, sometimes a service-oriented architecture (not micro) is useful.

Yea, I think they "won" out in the discourse over the last ~5 years, but I'm convinced it was another ZIRP phenomenon that will quickly fade as belts get tightened. When money rains down like mana from the heavens, sure, go ahead and hire half a dozen Ops folks to run your big ball of mud that maxes out at 8 req/s and has a 6 figure monthly AWS spend. I think things are going to swing back the other way, purely because efficiency will more important than it was over the last decade.

I must have missed that award ceremony.

Just look for the smears of shit over everything. They're over there.

Take time out and you may risk getting left behind on the likely shift to AI augmented coding

A monkey could work that out in thirty minutes.

Hopefully not otherwise all our jobs are at risk

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.

This is a sub-section of the survey, shown only to people who responded with `Yes` to the `Do you develop microservices?` question.

I still don't understand how 19% of respondents picked 'Monolith' as a system design approach. Perhaps they coexist?

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.

Contrary to what seems to be the rough consensus here, ESB/SOA (+ SOAP + WSDL + XML + ...) the 'correct way to do microservices' is probably something more like Self-Contained Sytems (SCS)

https://scs-architecture.org/

I'm shocked Java is the most popular language. I thought it was primarily a Node market.

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.

Additional: Some languages really do lean on IDEs. Java and C# are prime among those languages.

Writing Java or C# without an IDE is painful.

Writing Python or C without and IDE simply lacks creature comforts.

So any demographics used for a survey of an IDE company will skew for "IDE focused" languages. All else being equal.

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.

Are there pieces of microservice architecture that are zero-cost abstractions and can be used in even the smallest side project?

I wonder if they are going to do one for 2023?

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

Well, if the survey is conducted by JetBrains, I guess it's still far down the list?

Why? They have a (new) Rust IDE, and have had by far the best Rust support in any other IDE for years now.

Reply on news.ycombinator.com