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

141–150 of 243 posts

Re: Why our team cancelled our move to microservices

#141

Post by throwaway894345 »

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.

Also, security. Each component has an identity and it’s own set of permissions so the custom emoji widget doesn’t have access to the payments system or the health data.

Re: Why our team cancelled our move to microservices

#142

Post by Kalium »

candiddevmike wrote: post #122
Kalium wrote: post #72

Earlier quoted context omitted.

I agree that microservices shift complexity, but I'm not sure that this inherently results in an overall increase in complexity. For example, using highly automated ops tools like autoscaling and load balancing can enable smooth handling of problems that can be challenging to handle in code.

Instead of shuffling data between things via shared memory/function args, you're doing it over the network. This will always be more complicated.

Yes, it shifts communication to over the network, but this comes with the benefit of making system boundaries much clearer. It's been my experience that this can allow different parts to evolve separately and make the choices best for their own needs, which can sometimes result in a paradoxical reduction of complexity as one all-in-one system turns into a series of simpler tools. Suddenly the part of the system that does background ETL work and the part of the system that serves up the admin panel can use different tools.

I will agree that networks are inherently complicated, but your system or systems probably use networks anyway. Using them internally often forces you to grapple with the complexity you were already facing. Plus, it's been my experience that networks are easier for most to reason about than shared memory and mutexes.

Let's not forget providing an easy set of dials to turn to scale a given part of the system. That's a point of complexity, but it can be an immensely useful one. Complexity is not always the enemy - a power drill is more complex than a manual screwdriver and this complexity is pretty useful.

Re: Why our team cancelled our move to microservices

#143

Post by drewcoo »

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.

This. And now "microservices" is a rallying cry to avoid any kind of architecture organizing.

Because the broke you know isn't called "broke."

Re: Why our team cancelled our move to microservices

#144

Post by mindcrime »

Microservice architecture isn't "better".

Monoliths aren't "better".

Because the whole idea of "better" makes absolutely no sense without context. Sometimes microservices are better in a certain context. Sometimes a monolith is better in a different context. And sometimes, one or the other is "better" but not by enough of a margin to care about.

It's the oldest cliche in the book, but one that this industry seems to hate with a passion: "Pick the right tool for the job."

Sadly, in our world, the received wisdom sometimes seems to be "Use the newest, shiniest, most hyped tool that is what everyone is talking about."

Re: Why our team cancelled our move to microservices

#145

Post by drewcoo »

Graffur wrote: post #87
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

Well, back in the oughts, I think maybe 2001 . . .

https://2001.fandom.com/wiki/Monolith

Re: Why our team cancelled our move to microservices

#146

Post by yongjik »

giaour wrote: post #31

> Microservices allow your team to have control over the full stack they require to deliver a feature. This is honestly pretty rare, at least in my experience. What I have seen is that organizations will buy in to the microservices hype, then dictate to their teams what stacks, deployment paradigms, etc. (sometimes even down to the sprint cadence) are acceptable.

Honestly, "every team in the same company having full control over what kind of stack they want to use" sounds like a nightmare. Soon you have services running in Python, C++, Java, Go, and node.js, with five different internal libraries talking to MySQL, all slightly incompatible with each other. (Let's hope someone doesn't start up a PostgreSQL server.)

Re: Why our team cancelled our move to microservices

#147

Post by foxyv »

dasil003 wrote: post #100
foxyv wrote: post #96

Going from a monolith to a micro-service setup is essentially my idea of a Christian hell. Swirling depths of pain and uncertainty interspersed with screaming and urgency. There is no rest. No one knows when it will end. I think this is because our monoliths are so complicated they hide away our technical debt like monstrous Jack-In-The-Boxes. When you start breaking it into chunks all of these issues come exploding…

Agreed, however I've experienced something worse: trying to refactor domain models across an SOA that was poorly factored to begin with, and then layered 10k eng-years of incremental feature development driven by a fractured product team with short average tenures.

Sounds like a second circle. Jeeze, my condolences.

Re: Why our team cancelled our move to microservices

#148

Post by nchi3 »

kgeist wrote: post #120

We have a hybrid model: modular monolith + microservices. It has worked well so far. The core of the product is found in the monolith. We use bounded contexts ("modular monolith") with strictly separated concerns. There are no immediate plans to split the core into microservices (unless absolutely necessary) because the logic between modules is too intertwined and coupled. Splitting the core into microservices would…

> We use bounded contexts ("modular monolith") with strictly separated concerns.

>because the logic between modules is too intertwined and coupled.

That doesn't sound very modular? If your bounded contexts are intertwined, I don't think they can be considered bounded contexts. A modular monolith would only communicate between contexts through well-defined and non-leaky APIs, and that's the opposite of intertwined.

Re: Why our team cancelled our move to microservices

#149

Post by dpark »

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…

> that's why I don't buy into buzz words at all.

Clearly you do, because this is mostly nonsense driven by your knee jerk reaction to “microservices”. Very little you’ve written here is substantive. It’s all emotional appeal covering ignorance.

> If it's not broken, don't fix it...

But it is broken. Engineers often experience significant pain from monoliths so they look for a solution. They often also experience significant pain from microservices so the pendulum returns. Hopefully during all of this we learn enough that at least some pain is reduced, whether we land on microservices or monoliths or hybrid solutions.

> We need to stop disparaging … and focus on what works

Here I agree. Focus on what works and stop engaging in low value attacks on solutions that clearly work for some.

> The more we allow marketing minds to take control of our IT decisions…

What “marketing minds” are making decisions about service architecture? This seems like an imaginary issue.

Re: Why our team cancelled our move to microservices

#150

Post by winternett »

serial_dev wrote: post #102
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 make sense in some scenarios. I work at a large retail company with who knows how many developers. We have different teams for payment, promotions, product search, account, shipping and more. All of them working on a single codebase with coordinated deployments would be a nightmare. Previously, I joined a startup (previous coworkers of mine), a developer and a business guy. The developer "drank the micr…

This is agreeably congruent with my original statement,

The main problem I have with microservice marketing:

It is often promoted to clients that do not have applications that are large or critical enough to warrant leveraging them.

That buyers often are properly warned about their inability to easily migrate if they invest in platform-specific microservices too heavily.

And clients are often not aware of the operational costs that can rise over time for each component of the distributed architecture.

"Monolithic" solutions have also not stagnated... They can be run in distributed methods, they can leverage microservices in parts, they can also leverage containers, they are far from obsolescence because they are using the same languages that microservice architectures use, just with less distribution overall.

The term monolithic is often used to indicate that less-distributed solutions are somehow "out of date", "obsolete" and "not innovating" inaccurately, when the real story is that the business case usually dictates which solution will fit best.

Post reply on HN