Live data from Hacker News

Why our team cancelled our move to microservices

steven-lemon182.medium.com

21–30 of 243 posts

Re: Why our team cancelled our move to microservices

#21
post #2

> A benefit of microservices is that each team can be responsible for releasing their services independently and without coordination with other teams. Sounds almost sarcastic. How do you deliver API changes without alerting other teams?

That's why finding the right boundaries between services (yes, services, microservices is a harmful buzzword) is important, so that you minimise having to communicate and coordinate with other teams.

Re: Why our team cancelled our move to microservices

#23

It took me a while to accept that microservices are better. Not in every case, but in a surprising number of cases. They really shine when combined with serverless computing. Clear seperation of code by a networking call is the next logical step in the encapsulation principle of object oriented programming. We hide the implementation details and only expose an interface, which creates seperation and forces us to stop…

I think the catch is that "Services" are typically the scope at which encapsulation should stop.

They don't need to be "Micro".

Re: Why our team cancelled our move to microservices

#25

It took me a while to accept that microservices are better. Not in every case, but in a surprising number of cases. They really shine when combined with serverless computing. Clear seperation of code by a networking call is the next logical step in the encapsulation principle of object oriented programming. We hide the implementation details and only expose an interface, which creates seperation and forces us to stop…

I hope you're trolling.

If not, enjoy implementing joins across services.

Re: Why our team cancelled our move to microservices

#28

It took me a while to accept that microservices are better. Not in every case, but in a surprising number of cases. They really shine when combined with serverless computing. Clear seperation of code by a networking call is the next logical step in the encapsulation principle of object oriented programming. We hide the implementation details and only expose an interface, which creates seperation and forces us to stop…

> Clear seperation of code by a networking call is the next logical step in the encapsulation principle of object oriented programming.

You can have clear separation at the import/library level though. No need to add that extra latency to every call.

Re: Why our team cancelled our move to microservices

#29
post #2

> A benefit of microservices is that each team can be responsible for releasing their services independently and without coordination with other teams. Sounds almost sarcastic. How do you deliver API changes without alerting other teams?

That's why finding the right boundaries between services (yes, services, microservices is a harmful buzzword) is important, so that you minimise having to communicate and coordinate with other teams.

100%. Boundaries are extremely important, and if you're a service onto which 7 other teams rely on, there's an issue with your teams and the way you've setup your services. Bounded contexts!

Re: Why our team cancelled our move to microservices

#30

The term "Monolith" was devised by people who wanted to brand microservices as newer and superior. It's almost as if in order to succeed these days you need to discredit and disparage your competition rather than simply having a better product, and that's why I don't buy into buzz words at all. If it's not broken, don't fix it... Microservices are relatively new and unproven. The way the world has rushed to dive into…

[deleted]
Post reply on HN