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

201–210 of 243 posts

Re: Why our team cancelled our move to microservices

#201

Post by brunellus »

dwheeler wrote: post #154

Practically every technology decision has pros and cons. I think that if you can't think of a good reason not to use some technology, then you don't understand the technology well enough yet and you shouldn't try to use it in production yet. It may be what you need, but thinking that "everything must switch to this" is usually a huge warning signal that cargo cult engineering is happening instead of real engineering.

This point is reminiscent of the Chesterton’s Fence concept discussed on HN recently

Re: Why our team cancelled our move to microservices

#202

Post by throwaway894345 »

TheOtherHobbes wrote: post #174
throwaway894345 wrote: post #127

Earlier quoted context omitted.

Monoliths are pretty great, and there are tons of valid criticisms of microservices; however, this comment managed to steer clear of all of them. :) > The term "Monolith" was devised by people who wanted to brand microservices as newer and superior. Not everything is a conspiracy. Sometimes it’s just useful to have a word to describe a particular architecture. In this particular case, “monolith” isn’t even disparagin…

>individual teams can’t deploy their code without coordinating with every other team, which yields long user feedback loops and a bunch of other knock-on effects Fine until one of the microservices needs an update with new features -> new API because Something Has Changed, and suddenly... >the whole purpose of containers is to decouple the application from the platform. Are containers not a de facto platform? >Litera…

> Fine until one of the microservices needs an update with new features -> new API because Something Has Changed, and suddenly...

1. Right--you only depend on other teams when you need to

2. Even in this case, you just version your API, deploy your new version at your leisure, and incrementally move people over to the new version while deprecating the old version.

> Are containers not a de facto platform?

Not in any interesting or meaningful sense. Containers are precisely the technology that allow you to pack up and go to a different orchestrator or cloud provider. Note that the original concern was being locked into a cloud provider or PaaS--what does it mean to be "locked into containers"? Who has ever been "locked into containers"?

> Here's a moderately complete list of products. How many are pay-to-play?

You're conflating a lot of things. First of all containers aren't micro services or vice versa. Containers are just an interface for processes, and they enable things like orchestrators. "Containers versus " is orthogonal to "micro services vs monoliths". Secondly, there's nothing about paying for something that implies more lock-in. Whether you're paying or not, it's a lot easier to transition between platforms with micro services than with a monolith (micro services can move incrementally while a monolith has to move all at once or be painstakingly broken into micro services).

> All you're really doing with containers is creating a meta-monolith

With the enormous caveat that microservices can be deployed independently and even on different platforms and use different technologies... Which is to say microservices are nothing like monoliths. :)

> This makes sense at global scale where you're drowning in income and need to handle all kinds of everything for $very_large_number customers.

It makes sense if you have more than a few teams.

> It's complete madness for a small startup that doesn't even have a proven market yet.

There are degrees between "small startup without a market" and "global scale / drowning in income". But yes, I agree that microservices aren't a good fit for the very earliest, smallest-scale companies.

Re: Why our team cancelled our move to microservices

#203

Post by throwaway894345 »

patrick451 wrote: post #168
throwaway894345 wrote: post #127

Earlier quoted context omitted.

Monoliths are pretty great, and there are tons of valid criticisms of microservices; however, this comment managed to steer clear of all of them. :) > The term "Monolith" was devised by people who wanted to brand microservices as newer and superior. Not everything is a conspiracy. Sometimes it’s just useful to have a word to describe a particular architecture. In this particular case, “monolith” isn’t even disparagin…

> Not everything is a conspiracy. Sometimes it’s just useful to have a word to describe a particular architecture. In this particular case, “monolith” isn’t even disparaging, so if Big Microservices we’re trying to disparage monolithic architectures, why wouldn’t they use a term with a negative connotation? This isn't the reality on the ground. Where I currently work, "Monolith" is absolutely used as a pejorative by…

I can't speak to your workplace, but in the broader debate it's never been pejorative. It's always been neutral and descriptive. If they wanted to use a pejorative title, they could have gone with "bulky" or "cumbersome" or "inflexible" or any other number of loaded descriptors.

Re: Why our team cancelled our move to microservices

#204

Post by JetAlone »

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…

This is poetry.

Re: Why our team cancelled our move to microservices

#205

Post by hw »

twblalock wrote: post #155
andrewstuart wrote: post #38

Microservices shift complexity from code to operations - microservices don't remove complexity - they spread it wider, making the whole more complex.

The operations needed to keep a large monolith buildable when a lot of different teams work on it are also highly complex, and increase in complexity relative to the number of contributors to the codebase. It becomes a massive coordination problem at scale. Microservices decouple teams, so they can get their work done without stepping on each other's toes.

Until there needs to be a change in the interface. Now you have N other services to deploy to and coordinate

Re: Why our team cancelled our move to microservices

#206

Post by ironmagma »

throwaway894345 wrote: post #197
ironmagma wrote: post #184

Earlier quoted context omitted.

One function cannot access the memory space of another function any less explicitly than one process can access the memory of another process. Either way, you are just picking different contract enforcement mechanisms. The only way this would be helpful is if your whole goal is to make something (breaking the contract) as hard to do as possible. And in that case, I really have to ask, who are your teammates that you…

> One function cannot access the memory space of another function any less explicitly than one process can access the memory of another process. You're mistaken. The operating system largely prevents cross-process memory access. Of course, CPU vulnerabilities can circumvent these protections, but even then your micro services can run on distinct machines while monoliths can't. > The only way this would be helpful is…

> The operating system largely prevents cross-process memory access.

As do programming languages. Yes, a few languages like C allow you to do anything that's physically possible, but most popular languages including Python and JavaScript make leaking function-internal memory to the outside world either very inconvenient or impossible.

As for memory being shared among processes, it's not only not impossible but quite common in performance-sensitive applications. https://man7.org/linux/man-pages/man7/shm_overview.7.html

> many very profitable organizations do restrict employee access to secrets

For one, code is not secret. Secondly, when was this discussion scoped to profitable organizations? A very, very large chunk of HN readers work in startups.

> in many cases this is required by compliance

This argument weakens the entire stance, because it shifts the goalpost from "this thing is good" to "this thing is legally required." Let's stay focused. There are so many implicit assumptions you're taking as granted, I'm starting to doubt this is even an argument in good faith.

Re: Why our team cancelled our move to microservices

#207

Post by r00tanon »

As with all architectural patterns there are tradeoffs. Microservices for one thing are not functions. Granularity is an important concern.

A DDD approach up front will help with granularity.

The other leg is serverless support. Without that you are stuck with maintaining infrastructure in tandem with all the other considerations, which takes a lot a specialists - lots of engineers.

Definitely a game of scale and not for small organizations.

However, if scale is the key ingredient for success and the value proposition is based on scale, then this kind of architecture is worth looking at.

That said, all shops are not Netflix or AWS...

Re: Why our team cancelled our move to microservices

#208

Post by terrorobe »

jayd16 wrote: post #200
jedberg wrote: post #61

> We have approximately 12 developers spread across 2 feature teams and a support team. If I were consulting for this company, I would have told them to stop right there, microservices are probably not for them. Unless you build from the start for microservices on something like AWS lambda, doing with such a small team would be really hard. And as they eventually discovered, a lot of unnecessary overhead for such a s…

I don't know if I agree. Deploying servers and calling out to services should be a core competency. I don't think it's as drastic as you make it out to be. No ownership is a bigger problem than team size imo. That said, no reason to do it just because it's trendy.

> calling out to services should be a core competency.

What’s the typical failure rate of a method call within a process of a language of your choice?

If it’s not Java2k it will be one or two orders of magnitude lower than any cross-process, host or provider RPC call you’re ever going to make.

At smaller scales, just not having to deal with all the bugs and cleanup work missed error handling brings - and then building proper error handling for all relevant cases - can make a huge difference.

Re: Why our team cancelled our move to microservices

#209

Post by netfl0 »

dwheeler wrote: post #154

Practically every technology decision has pros and cons. I think that if you can't think of a good reason not to use some technology, then you don't understand the technology well enough yet and you shouldn't try to use it in production yet. It may be what you need, but thinking that "everything must switch to this" is usually a huge warning signal that cargo cult engineering is happening instead of real engineering.

Fashion has H&M

Tech has HN

Re: Why our team cancelled our move to microservices

#210

Post by tomc1985 »

mrbungie wrote: post #194
dpark wrote: post #166

Earlier quoted context omitted.

Did you become a marketing mind because they were pitching you? I did not say that marketing isn’t making pitches. I said they aren’t making the decisions. Any company allowing marketing to choose the technical platform for the engineers is going to be very short lived. This is not a real issue.

You're assuming engineers can't be victims of cargo cult, and we all know that's not globally true as it's been discussed multiple times on HN. Marketing teams know that as well, and they exploit that as much as they can.

> Marketing teams know that as well, and they exploit that as much as they can.

They exploit this mercilessly, just as hard as they exploit our curiosity and desire for novelty as engineers.

To the GP, your company's marketing/sales team may not drive internal technical decisions, but I can promise you that other companies' sales teams do. Why do you think they so persistently step on the heads up their first POC so they can be put in touch with C-levels or department heads?

Enterprise sales is a trip, dude

Post reply on HN