Seems to me the problem is the shared libraries. Yes, without sharing it means you have to repeat a fair amount of code, but in most cases the representation that each service cares about is not necessarily the same, which reduces the value of these shared libraries. It seems that they would have solved a lot of the really critical issues by simply not sharing as much code.
Goodbye Microservices: From 100s of problem children to 1 superstar
41–50 of 782 posts
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#42I've always said if the Linux kernel can be a giant monolith, in C no less, than there's maybe 100 web applications in the world that need to be split into multiple services. I've worked with microservices a lot. It's a never-ending nightmare. You push data consistency concerns out of the database and between service boundaries. Fanning out one big service in parallel with a matching scalable DB is by far the most sa…
People look at microservices as a solution to the Big Ball of Mud, and then confuse "a solution" with "the solution".
You really do have to modularize. In some languages, you can even use separate compilation units for separate modules to enforce the separation.
You can do all of that but get simultaneous deployment, which cuts out whole classes of integration nightmares.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#43I've always said if the Linux kernel can be a giant monolith, in C no less, than there's maybe 100 web applications in the world that need to be split into multiple services. I've worked with microservices a lot. It's a never-ending nightmare. You push data consistency concerns out of the database and between service boundaries. Fanning out one big service in parallel with a matching scalable DB is by far the most sa…
"Need to" and "sane" are among my favourite subjective terms! (Further below, I'll go into in which contexts I'd agree with your assessment and why. But for now the other side of the coin.) In the real world, current-day, why do many enterprises and IT departments and SME shops go for µservice designs, even though they're not multimillion-user-scale? Not for Google/Netflix/Facebook scale, not (primarily/openly) for h…
Are you telling me you chose micro services just to enforce coding standards and allow devs to be more comfortable?
The legacy concerns I don’t see being true, as it’s mainly a requirements/documentation problem and you can achieve the same effect with feature toggles.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#44Earlier quoted context omitted.
"Need to" and "sane" are among my favourite subjective terms! (Further below, I'll go into in which contexts I'd agree with your assessment and why. But for now the other side of the coin.) In the real world, current-day, why do many enterprises and IT departments and SME shops go for µservice designs, even though they're not multimillion-user-scale? Not for Google/Netflix/Facebook scale, not (primarily/openly) for h…
Is there any evidence of this being true? Do they actually force a discipline? Do people actually find swapping languages easier with RPC/messaging than other ffi tooling? And do they really attract talent?! You make some amazing claims that I have seen no evidence of, and would love to see it.
> "You make some amazing claims that I have seen no evidence of"
I'm just relaying what I hear from real teams out there, not intending to sell the architecture. So these are the beliefs I find on the ground, how honest and how based-in-reality they are are harder to tell and only slowly over time at any one individual team.
A lot of this is indeed about hiring though, I feel, at least as regards the enterprise spheres. Whether you can as a hire really in-effect "bring your own language" or not remains to be seen, but by deciding on µs architecture for in-house you can certainly more credibly make that pitch to applicants, don't you think?
Remember, there are many teams that have suffered for years-to-decades from the shortcomings and pitfalls of (their effectively own interpretation of / approach to) "monoliths" and so they're naturally eagerly "all ears". Maybe they "did it wrong" with monoliths (or waterfall), and maybe they'll again "do it wrong" (as far as outsiders/gurus/pundits/coachsultants assess) with µs (or agile) today or tomorrow. The latter possibility/danger doesn't change the former certainties/realities =)
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#45I've always said if the Linux kernel can be a giant monolith, in C no less, than there's maybe 100 web applications in the world that need to be split into multiple services. I've worked with microservices a lot. It's a never-ending nightmare. You push data consistency concerns out of the database and between service boundaries. Fanning out one big service in parallel with a matching scalable DB is by far the most sa…
"Need to" and "sane" are among my favourite subjective terms! (Further below, I'll go into in which contexts I'd agree with your assessment and why. But for now the other side of the coin.) In the real world, current-day, why do many enterprises and IT departments and SME shops go for µservice designs, even though they're not multimillion-user-scale? Not for Google/Netflix/Facebook scale, not (primarily/openly) for h…
Except the language argument, don't you get all that by just having modules in your code (assuming a statically typed language since the boundaries are type checked)?
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#46As with J2EE EJBs, microservices conflates two things:
- a strong API between components
- network calls
The former is a very good idea that should be implemented widely in most code bases, especially as they mature, using techniques like modules and interfaces.
The latter is incredibly powerful in some cases but comes at a huge cost in system complexity, performance and comprehensibility. It should be used sparingly.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#47Too many smart folks that I've worked with, for some reason, just stop thinking critically when it comes to certain ideas. I was a product manager on a team of really rockstar developers. They all earn at least $200k a year. Instead of demanding more ambitious projects, you could keep about 99% of them happy by just letting them use the new framework of the week to build their next web app. Their excitement when they…
Sounds like you really don't understand development if you think getting to use React isn't a big deal. React (and others like it, e.g. Vue) really is a huge win and solves a ton of pain points common to front end development. It still has its own pain points, but it's hard to overstate how much of an improvement it is over other older approaches like jQuery.
What does react have to do with jquery?
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#48Too many smart folks that I've worked with, for some reason, just stop thinking critically when it comes to certain ideas. I was a product manager on a team of really rockstar developers. They all earn at least $200k a year. Instead of demanding more ambitious projects, you could keep about 99% of them happy by just letting them use the new framework of the week to build their next web app. Their excitement when they…
> Too many smart folks that I've worked with, for some reason, just stop thinking critically when it comes to certain ideas.
Because doing something new is much more fun that doing something effective. And most software developers don't really get into this job out of doing things effectively - we're get into it out of the sheer fun of it, altough we would never admit it to our bosses and often even to ourselves.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#49Not that I disagree with microservices easily going awry, the problem here seems to be traced to shared library code. Each microservice should be as standalone as possible. Your contract with that service is the service contract. Not some shared library. As soon as you have shared library, you now have coordinated deployments. And that is just not fun and will cause problems. The trick here is that this does mean you…
There is commonality across those 140 services that they extracted into a shared library so they weren’t copying that commonality 140 times.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#50So they split everything apart because their tests were failing and they didn't want to spend time fixing them, and they they merged it back together by spending time fixing and improving their tests? It seems like the problem here was bad testing and micro repos, not microservices.
I agree, and their conclusion even features this salient bit: >However, we weren’t set up to scale. We lacked the proper tooling for testing and deploying the microservices when bulk updates were needed. As a result, our developer productivity quickly declined. My impression after reading this post was that microservices were symptoms of problems in how their organization wasn't set up to implement them effectively,…
[deleted]