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