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

41–50 of 243 posts

Re: Why our team cancelled our move to microservices

#41

Post by pc86 »

jokethrowaway wrote: post #25
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…

I hope you're trolling. If not, enjoy implementing joins across services.

Doesn't this just mean you picked a bad service boundary? You shouldn't have to join across services, ever.

Seems like a straw man.

Re: Why our team cancelled our move to microservices

#43

Post by Softcadbury »

GrumpyNl wrote: post #24

There is a big misconception that a monolith has to be fully deployed every time. A well designed monolith can be partially deployed.

Can you say more about that ? I'm a DotNet developer and I don't see how this could be possible without having several applications

Re: Why our team cancelled our move to microservices

#44

Post by ozim »

glintik wrote: post #20
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.

I don't think it was "splitting monolith" it was more like connecting separate applications.

Like you had a payroll in your enterprise of 1000 employees and you needed that same data in 5 applications in 3 different departments. So you would wrap payroll into a service and have that data accessible in multiple places.

I think that is still a valid approach to build monolith app and use multiple services if they are internal apps.

For customer facing and quickly changing stuff you might want to add microservices to be able to build new features quickly when ideally microservice should have its own database with what it needs to operate.

Re: Why our team cancelled our move to microservices

#45

Post by cyberge99 »

vmception wrote: post #27

I think many microservice implementations are more complex than necessary but I also am extremely skeptical of someone’s competence if the database is on the same compute instance as everything else

I’m skeptical because they’re on IIS in 2022.

Re: Why our team cancelled our move to microservices

#46

Post by kgeist »

bilalq wrote: post #14
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…

>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

It also helps with zero-downtime deployments:

1) spawn a new instance of the service with the new API, side by side with the old one

2) now incoming traffic (which still expects the old API) is routed to the new instance with the new API, and it's OK, because it's backward-compatible

3) shut down the old instance

4) eventually some time later all clients are switched to the new API, we can delete the old code

Re: Why our team cancelled our move to microservices

#47

Post by feoren »

vmception wrote: post #27

I think many microservice implementations are more complex than necessary but I also am extremely skeptical of someone’s competence if the database is on the same compute instance as everything else

Rephrasing: "this person, who is probably solving a very different problem with different design constraints than me, is doing things differently than the handful of ways I have ever seen in my limited career, and is therefore stupid."

Re: Why our team cancelled our move to microservices

#48

Post by jeffbee »

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?

Don't ever change APIs. It's pretty simple. I don't know why the monolith people believe this is such a gotcha.

If you really need to change the API, give the new API another name. You may choose to think of this as "versioned APIs", if you want, but "versioned" and "renamed" are the same thing.

Re: Why our team cancelled our move to microservices

#50

Post by kirse »

I always start with a monolith while keeping microservices in mind. Have clear communication boundaries, avoid shared state as much as possible, consider asynchronous and parallel processing needs, etc.

Actor systems are a natural fit for this eventual de-coupling. What starts as a simple actor w/ a mailbox can eventually grow to a standalone REST service with minimal headache in architectural refactoring.

Post reply on HN