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