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

81–90 of 243 posts

Re: Why our team cancelled our move to microservices

#81

Post by ironmagma »

whimsicalism wrote: post #62
ironmagma wrote: post #59

Earlier quoted context omitted.

Examining behavior in the limit (a la physics) is interesting. Imagine a system where every function call goes out to a separate process. Suddenly you have a lot of processes waiting around to be called. Debugging requires special tools. Profiling becomes a nightmare. Even determining if the system is fully running becomes difficult. What have you gained?

> What have you gained? Separation of responsibilities? Easier to analyze because you only have so many inputs and outputs to a simpler system? Debugging something that touches a lot of paths in a monolith can be quite nightmarish as well.

> you only have so many inputs and outputs to a simpler system?

Doesn't a function only have so many inputs and outputs too? Scope capturing/global variables aside.

Re: Why our team cancelled our move to microservices

#82

Post by ryan_j_naughton »

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…

> Microservice architecture is also inherently designed to lock a customer into very specific tools that make future migration to any other platform a very costly decision in most cases... Thereby locking a customer into platform-specific dependency

Can you elaborate on this? Examples? Thanks!!

Re: Why our team cancelled our move to microservices

#83

Post by jbverschoor »

Clubber wrote: post #40
glintik wrote: post #20

Earlier quoted context omitted.

> 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.

It was SOA (Service Oriented Architecture) where you would split them up, that predates Microservices by quite a bit. I remember doing that in the early 2000s. What I think he is saying is that Microservices people pitch their service against monolith as better, but monolith hasn't been in vogue for 20 years. I saw the same tactic with scrum people pitching against waterfall which hadn't been in vogue for quite a whi…

Although clunky to implement, EJB had really well thought out concepts, architecture and roles

Re: Why our team cancelled our move to microservices

#84

Post by LASR »

pythux wrote: post #56

> Recently our development team had a small break in our feature delivery schedule. Technical leadership decided that this time would be best spent splitting our monolithic architecture into microservices. Maybe redesigning the architecture of the product just because there is time vs. there is a pain point/problem that needs solving is already a red flag. In this context it feels like “micro services” was a hammer l…

Exactly.

Microservices can solve for some problems, eg: scaling infrastructure in a non-uniform manner or scaling development velocity non-uniformly across many teams.

But there are also tons of other ways to solve these problems. The mistake is in assuming that you need microservices to do x, without really critically thinking about what is actually stoping you from having x right now.

The move to microservices (or any similar kind of rewrite efforts) should be undertaken only when it's painfully obvious that it's needed.

Re: Why our team cancelled our move to microservices

#85

Post by bhuber »

rydgel wrote: post #42

Why would you consider microservices if you are only 12 developers?

Most of the conversation so far has focused on the development benefits of microservices (decoupling deployments, less coordination between teams, etc). Small teams don't really have this problem, but there are other benefits to microservices. One of the biggest is scaling heterogeneous compute resources.

Suppose, for example, your webapp backend has to do some very expensive ML GPU processing for 1% of your incoming traffic. If you deploy your backend as a monolith, every single one of your backend nodes has to be an expensive GPU node, and as your normal traffic increases, you have to scale using GPU nodes regardless of whether you actually need more GPU compute power for your ML traffic.

If you instead deploy the ML logic as a separate service, it can be hosted on GPU nodes, while the rest of your logic is hosted on much cheaper regular compute nodes, and both can be scaled separately.

Availability is another good example. Suppose you have some API endpoints that are both far more compute intensive than the rest of your app, but also less essential. If you deploy these as a separate service, a traffic surge to the expensive endpoints will slow them down due to resource starvation (at least until autoscaling catches up), but the rest of your app will be unaffected.

Re: Why our team cancelled our move to microservices

#86

Post by jacobsenscott »

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?

Also, this (independent deployability) is simply not a feature of microservices. It is a feature of any well architected code base.

I've always worked on monoliths, and I've almost never needed to coordinate a release with anyone. I just merge my branch and deploy. Github and shopify talk about merging and deploying monoliths hundreds of times per day without coordination.

The case where you would need to coordinate a release in a monolith is exactly the same case where you would need to coordinate a release in microservice app. That's the case where your change depends on someone else releasing their change first. It doesn't matter if their change is in a different service, or just in a different module or set of modules in the same application.

Now, most application are not well architected - micorservices or monoliths. In the case of a poorly architected app deploying a monolith is much easier anyway. Just merge all that spaghetti and push one button, vs trying to coordinate the releases of 15 tangled microservices in the proper order.

Re: Why our team cancelled our move to microservices

#87

Post by Graffur »

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…

> The term "Monolith" was devised by people who wanted to brand microservices as newer and superior.

I am interested in hearing more history on this

Re: Why our team cancelled our move to microservices

#88

Post by kgeist »

noogle wrote: post #58
kgeist wrote: post #46

Earlier quoted context omitted.

>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-…

How can accumulation of versions be prevented? Now the same team has to maintain two products, and the underlying mechanism is still limited by the older version. Anecdotally, a robust backward-compatibility has been seen as a hinderance to e.g. Java's progress (so much that a newer language, Kotlin, was created to break free from that burden).

Well we usually coordinate between the teams. I.e. we don't force other teams to make changes as soon as possible (they have their own plans) but we agree to add relevant changes to their backlog, so that it was fixable in a 1-2 month window.

Re: Why our team cancelled our move to microservices

#89

Post by contextfree »

I'm not speaking from experience here, but it seems like rather than "moving to a microservices architecture" it would perhaps be better to think more in terms of "splitting out specific functionality X into an independently deployable and hostable service, which should alleviate the specific problem Y that we've been experiencing due to their being too closely coupled" and if there are no obvious X and Y then maybe the "monolith" is fine?

Re: Why our team cancelled our move to microservices

#90

Post by shroompasta »

Their architecture didn't provide any clear boundaries to be sufficient for microservices, however that isn't the case for many medium to larger sized projects.

(By the way, just because there's still quite a bit of coupling between services, doesn't mean there aren't clear boundaries - Microservices can communicate with one another all the time and still be justified in being decoupled)

There isn't an absolute answer to monolith vs microservices - It depends case by case.

Instagram was built using Django and I'm unsure of ig's architecture today, but it remained monolithic for a very long time (at least till late 2019), and if that architecture sufficed for Instagram, I'm sure it would suffice for many other projects.

However, still, it's not a this or that as many of the comments here would seemingly imply - Again, it's HEAVILY dependent on the case.

Post reply on HN