Lessons Learned While Building Microservices
blog.runnable.com
Lessons Learned While Building Microservices
1–10 of 27 posts
Re: Lessons Learned While Building Microservices
#2Yup, and even better when you aren't even tied to any language.
Re: Lessons Learned While Building Microservices
#3My current company learned this a couple of years ago - on their first Node project after deciding to move away from .Net, it ended up a giant monolith, and so 4 years ago or so they decided to move towards microservices. The burden of trying to upgrade a monolith is colossal, and it is where microservices shine.
Re: Lessons Learned While Building Microservices
#4So while I'm not anti-microservices, from the developer's perspective sometimes there's just way too many moving parts.
one code change+one test change back in the "monolith" days (and if the change broke the existing tests you know right away) now becomes an ordeal.
Tracking down the client services/altering their code + tests+ simulators (not to mention that you now have to check the code out from bazillions of repos, run it locally etc) and then waiting for their respective build plans to pass, wait for the integration tests to pass etc.
Re: Lessons Learned While Building Microservices
#5So while I'm not anti-microservices, from the developer's perspective sometimes there's just way too many moving parts. one code change+one test change back in the "monolith" days (and if the change broke the existing tests you know right away) now becomes an ordeal. Tracking down the client services/altering their code + tests+ simulators (not to mention that you now have to check the code out from bazillions of rep…
I've done a lot of work on monoliths, and a fair amount with microservices. I've never observed the perceived simplicity of the former to bear out in practice; there's just as much complexity, but instead of being reasonably well contained and prevented from spilling across service boundaries, it's smeared all over the application, so being confident you've tracked down and addressed all of it is much more difficult than it has to be.
It sounds like you may be having problems not because the architecture is designed the way it is per se, but because it's poorly documented and hard to discover. There's nothing about the monolithic style which prevents that, or even makes it less likely to occur.
Re: Lessons Learned While Building Microservices
#6So while I'm not anti-microservices, from the developer's perspective sometimes there's just way too many moving parts. one code change+one test change back in the "monolith" days (and if the change broke the existing tests you know right away) now becomes an ordeal. Tracking down the client services/altering their code + tests+ simulators (not to mention that you now have to check the code out from bazillions of rep…
I've done a lot of work on monoliths, and a fair amount with microservices. I've never observed the perceived simplicity of the former to bear out in practice; there's just as much complexity, but instead of being reasonably well contained and prevented from spilling across service boundaries, it's smeared all over the application, so being confident you've tracked down and addressed all of it is much more difficult…
As I see it (and I haven't been convinced otherwise), the only advantage microservices have over monoliths is that they can scale horizontally more easily, and a slight advantage is that they pressure you to write cleaner interfaces.
There's nothing preventing a monolith from being as modular as a microservices architecture, only without all the headaches that come with monitoring tens of services and sticking a network between them. There is NOT just as much complexity in a monolith, because you have no network of services to monitor, there's only one service.
Sure, your business logic is going to be the same in either approach, but you're comparing badly written monoliths to well-written microservices. There's nothing that says microservices can't be a mess (and I've seen multiple people completely botch it and have all the services talk to the same database).
Re: Lessons Learned While Building Microservices
#7Earlier quoted context omitted.
I've done a lot of work on monoliths, and a fair amount with microservices. I've never observed the perceived simplicity of the former to bear out in practice; there's just as much complexity, but instead of being reasonably well contained and prevented from spilling across service boundaries, it's smeared all over the application, so being confident you've tracked down and addressed all of it is much more difficult…
As I see it (and I haven't been convinced otherwise), the only advantage microservices have over monoliths is that they can scale horizontally more easily, and a slight advantage is that they pressure you to write cleaner interfaces. There's nothing preventing a monolith from being as modular as a microservices architecture, only without all the headaches that come with monitoring tens of services and sticking a netw…
Well, I've seen a lot of badly written monoliths. Whether or not that's coincidental is a point worth considering.
Re: Lessons Learned While Building Microservices
#8So while I'm not anti-microservices, from the developer's perspective sometimes there's just way too many moving parts. one code change+one test change back in the "monolith" days (and if the change broke the existing tests you know right away) now becomes an ordeal. Tracking down the client services/altering their code + tests+ simulators (not to mention that you now have to check the code out from bazillions of rep…
I've done a lot of work on monoliths, and a fair amount with microservices. I've never observed the perceived simplicity of the former to bear out in practice; there's just as much complexity, but instead of being reasonably well contained and prevented from spilling across service boundaries, it's smeared all over the application, so being confident you've tracked down and addressed all of it is much more difficult…
Microservces enforce some separation of concerns, but Monoliths can use the same approach without nearly as much complexity. Overall, I find microservices to add a huge range of new failure modes for little net gain. The sweet spot seems to be services where large chunks of the application operate independently. 10 services are manageable, 100 are not.
Re: Lessons Learned While Building Microservices
#9So while I'm not anti-microservices, from the developer's perspective sometimes there's just way too many moving parts. one code change+one test change back in the "monolith" days (and if the change broke the existing tests you know right away) now becomes an ordeal. Tracking down the client services/altering their code + tests+ simulators (not to mention that you now have to check the code out from bazillions of rep…
I've done a lot of work on monoliths, and a fair amount with microservices. I've never observed the perceived simplicity of the former to bear out in practice; there's just as much complexity, but instead of being reasonably well contained and prevented from spilling across service boundaries, it's smeared all over the application, so being confident you've tracked down and addressed all of it is much more difficult…
[deleted]
Re: Lessons Learned While Building Microservices
#10Earlier quoted context omitted.
I've done a lot of work on monoliths, and a fair amount with microservices. I've never observed the perceived simplicity of the former to bear out in practice; there's just as much complexity, but instead of being reasonably well contained and prevented from spilling across service boundaries, it's smeared all over the application, so being confident you've tracked down and addressed all of it is much more difficult…
Microservces enforce some separation of concerns, but Monoliths can use the same approach without nearly as much complexity. Overall, I find microservices to add a huge range of new failure modes for little net gain. The sweet spot seems to be services where large chunks of the application operate independently. 10 services are manageable, 100 are not.
> Monoliths can use the same approach without nearly as much complexity
Do they?
> The sweet spot seems to be services where large chunks of the application operate independently.
Which could be said to be a design choice in many cases, perhaps even most.