21–30 of 106 posts
New spring library? Have fun applying the same changes to 14 different microservices.
Microservices might make sense with completely different teams developing them - but multiple microservices in the same team, with the services talking to each other, really doesn't make sense.
How about just stop making microservices and go back to monoliths? Then you don’t have to shoehorn two things at the same time!
Microservices: Software complexity solutions to human organisation problems. Remember when microservices were pitched as 'allowing you to use the right language for the job'? What a wonderful life the person who thinks a balkanised tech stack is good must have had. They're one undisciplined developer away from having production prolog.
How about just stop making microservices and go back to monoliths? Then you don’t have to shoehorn two things at the same time!
I agree 100%. However after spending 10 years doing microservices everyone wants me to do microservices, despite me telling them what you just said. It's a positive feedback loop.
This project is just an exploration of providing teams with a low (no?) cost way of doing microservices - I also kinda enjoy hacking on things like this. Still in progress though so use it at your own risk.
Earlier quoted context omitted.
Because all these idiots who pitched microservices super hard need to undo the mess they've created while self promoting themselves into new thought leadership roles.
Is it the fault of the thought leader, or the loads of juniors asked to implement the architecture but don't really understand it? If everyone had better system design knowledge, it wouldn't be so bad. 90% of the engineers in my organization don't understand the function of an API Gateway, for example. So the thought leader does propose a reasonable solution, but then it doesn't work because the organization doesn't…
However, I've definitely seen this problem even with legitimately strong, seasoned technical leadership, where the vision is great, but the team just doesn't have the skills to pull it off. You can't have good macro-engineering without good micro-engineering. The problem with the cambrian explosion of tech is that it obfuscates the basics that engineers need to understand. Junior engineers end up struggling just to stay on top of incidental complexity and many come to the conlusion that building good software is just about learning enough languages and tooling, when in reality they are barely keeping their head above water and never learn the deeper lessons of what works and doesn't in software systems.
I’d rather compose my systems with widely understood and commonly used components that make hiring and maintaining over time more of a puzzle problem than a, “learn a new framework” problem. This feels like we make our jobs harder than they have to be, sometimes…
OP here. Fortunately the authors of the components you use didn't get discouraged by comments like this otherwise they would've never been written ; )
Earlier quoted context omitted.
Microservices: Software complexity solutions to human organisation problems. Remember when microservices were pitched as 'allowing you to use the right language for the job'? What a wonderful life the person who thinks a balkanised tech stack is good must have had. They're one undisciplined developer away from having production prolog.
One of the pros of microservices is that each individual microservice is so simple that it really doesn't matter what language it's written in because it can be easily rewritten.
It's like we're advocating for the outcome of the Tower of Babel tale.
I think this is directionally correct. Services should just be standard language classes, and whether that service is hosted inside process 1 host 1 or process 7 host 5 is up to the autoscaling component. The industry is verrryy slowly getting there.
Yeah in part my motivation for open sourcing this was the fact I kept reading on HN how microservices should be an implementation detail etc. in the past 6 months. I totally agree with that sentiment, hence Actio. For the direction I can take some responsibility but not for the details (yet) ;).
My issue with microservices isn't the network calls, it's the extra work to keep the source code up to date. New spring library? Have fun applying the same changes to 14 different microservices. Microservices might make sense with completely different teams developing them - but multiple microservices in the same team, with the services talking to each other, really doesn't make sense.
On the flip side, at some point monoliths can get large enough that upgrading libraries or runtimes becomes an incredibly difficult problem. When I was at Amazon a major service was finally getting upgraded from Java 7 to Java 8. Took a cross-functional team 6 months (!) to make it happen due to the massive amounts of existing code. And these are AWS engineers who are much technically stronger than average.
I don't condone the 500 LOC style of true microservices, but people tend to go back to the extreme of "just make everything run in the same process with the same runtime and same dependency chain" as if that doesn't come with its own set of headaches.
(also for what it's worth -- in correctly done SOA, you don't need to upgrade libraries in lockstep. So that Spring upgrade can be done on a per-service basis as needed.)
How about just stop making microservices and go back to monoliths? Then you don’t have to shoehorn two things at the same time!
I spent a decade at Amazon (SOA all the things!) and then a year and a half at Shopify (single Rails monolith for all the things!). I think both strategies have pros and cons. But critically, you need a company culture that supports whichever choice you've made. If you have a company where each team gets to totally decide how they want to implement their stuff, sharing a monolith between teams can create a mess. Owne…
So do microservices.