Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why our team cancelled our move to microservices

steven-lemon182.medium.com

Post reply on HN
Print view View original

11–20 of 243 posts

Re: Why our team cancelled our move to microservices

#11

Post by wging »

nurettin wrote: 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?

Not all changes result in a change to the way your service is called, and even those changes can (with some effort and care) be made backwards-compatible. Performance-level changes are one obvious one - for example, I wouldn't expect to have to keep my caller in the loop if I decrease my API's latency by 50ms, even though it might be a good idea.

But other behavior changes are also not necessarily something that requires a team to be alerted. A good design provides an abstraction where the caller shouldn't have to care about the underlying implementation or details of how a request is fulfilled.

Re: Why our team cancelled our move to microservices

#12

Post by luhego »

I think that moving a monolith to a microservices architecture is only justified if the organization size is large enough, so there are different business teams/departments. In that scenario, each team/department will own a microservice and this will speed up the development on each team. Still, every time there is a change in any microservice API, that will require coordination. For a small company(12 developers), I can't see the benefit.

Re: Why our team cancelled our move to microservices

#13

Post by winternett »

fdgsdfogijq wrote: post #6

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…

A size 20 shoe is better for a large foot... But not better for a size 15 or size 10 foot.

Saying Microservices are better is the same as me saying "a size 20 shoe is better than any other shoe"... for everyone.

It's not a viable statement in any use case, except for people with size 20 feet.

The business need is what determines the solution necessary.

Re: Why our team cancelled our move to microservices

#14

Post by bilalq »

nurettin wrote: 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?

This is how things were done at Amazon quite successfully. The golden rule is to never break API backwards compatibility. If you must, create a new version of the API and leave the old version functional. If you need to shut down old functionality, it becomes a campaign you have to drive to move your dependents off of it. One little thing that people often overlooked but was very important was to have API operations for describing your enums rather than just putting them in the docs. This allowed for easier adoption of them by API consumers and forced them to consider what to do in the case of an unrecognized value being encountered.

Re: Why our team cancelled our move to microservices

#16

Post by fdgsdfogijq »

winternett wrote: post #13
fdgsdfogijq wrote: post #6

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…

A size 20 shoe is better for a large foot... But not better for a size 15 or size 10 foot. Saying Microservices are better is the same as me saying "a size 20 shoe is better than any other shoe"... for everyone. It's not a viable statement in any use case, except for people with size 20 feet. The business need is what determines the solution necessary.

I know its not a catch all. But more often than I would like to admit they bring simplicity and reduce complexity. The more I develop software, the less I can stomach monoliths running on some big server. The other day I was considering deploying an MVP I have written on Django, and instead just ripped it apart and pushed the pieces into their own seperate lambdas. Deploying some monolith API like that was nerve wrecking, updates are, the blast radius is higher, and the composability of components is easier with smaller microservices.

Re: Why our team cancelled our move to microservices

#17

Post by shuntress »

nurettin wrote: 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?

> Sounds almost sarcastic. How do you deliver API changes without alerting other teams?

Sounds almost sarcastic. To deliver API changes without alerting other teams you, of course, simply deploy the changes without sending a message to the other teams.

The non-sarcastic answer is that sometimes you want to make changes that will not affect an APIs users in any significant way. Of course you would still document these changes in a change log that the consumers of the API may or may not check. Or you may want to hype/market these changes for clout reasons.

Maybe it's an API that services multiple sets of users with different partially-overlapping requirements and they don't all need to know about the new change.

Maybe it's a soft launch for a surprise feature that's going to be announced later.

Maybe the other team is on vacation and you just want to get changes out the door before some holiday.

Re: Why our team cancelled our move to microservices

#19

Post by root_axis »

nurettin wrote: 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?

Never break the API. If you need a new API contract use API versioning so that consumers can upgrade when it's convenient. Additionally, use contract testing.

Re: Why our team cancelled our move to microservices

#20

Post by glintik »

winternett wrote: post #7

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…

> Microservices are relatively new and unproven.

They are so old, buddy, actually. Splitting monolith into services(not always been micro) is a natural evolution for any software.

Post reply on HN