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

121–130 of 243 posts

Re: Why our team cancelled our move to microservices

#121

Post by fendy3002 »

ryan_j_naughton wrote: post #82
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!!

Looks like OP talked about serverless / google cloud run, where rather than traditional server deployment, it use specific provider's implementation. Additionally it may also means CI/CD pipeline where usually it's different between provider.

Re: Why our team cancelled our move to microservices

#122

Post by candiddevmike »

Kalium wrote: post #72
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.

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.

Re: Why our team cancelled our move to microservices

#123

Post by vmception »

feoren wrote: post #47
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."

if I meant to say that, I would have said that

for anybody else passing by, the people still doing things like a LAMP stack on a single compute instances are getting the same user experience issues under load that we solved for over the last decade or so. I’m just not running into people that have looked at a system design tutorial in the last 10 years that thought “ah this is the use case where I can reject all these guidelines because I’m so experienced”

Re: Why our team cancelled our move to microservices

#124

Post by fendy3002 »

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…

Well if the problem domain and scope is very-very well defined, developing a service as microservice is good / better than monolith. I can't imagine google map API to be developed inside the monolith app instead of running as their own service.

The problem that many developers fall on is sometimes some problem domains feel like they're well separated. However in practice those domains are tightly coupled into each other, that merging them together is better.

Re: Why our team cancelled our move to microservices

#125

Post by pjmlp »

jbverschoor wrote: post #83
Clubber wrote: post #40

Earlier quoted context omitted.

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

I miss dealing with Websphere every time I am fixing Kubernetes spaghetti.

Re: Why our team cancelled our move to microservices

#126

Post by thebean11 »

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

You need to talk to the other teams. Usually the change isn’t so drastic, I often made the change myself in the other teams service and sent them a review.

Re: Why our team cancelled our move to microservices

#127

Post by throwaway894345 »

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…

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 disparaging, so if Big Microservices we’re trying to disparage monolithic architectures, why wouldn’t they use a term with a negative connotation?

> If it's not broken, don't fix it... Microservices are relatively new and unproven.

The microservices people would argue that monoliths are broken for many use cases. In particular, 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. Microservices exist to support nimble organizations by helping to remove technical coupling between teams. This is all 101-level stuff but the microservices critics always ignore it in their criticism.

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

I don’t think you could be more incorrect :). Microservices are almost universally built atop containers, and the whole purpose of containers is to decouple the application from the platform.

> We have also seen enough failures and pain points within microservice and even cloud architectures over the past two years alone to raise questions about whether or not it it indeed a better solution.

Microservices are typically more robust than monoliths if only because components are isolated—a failure in a superficial component doesn’t bring the whole app down. Moreover, monoliths are less secure as well because there’s no way to regulate permissions within the process—anything one component can do, the whole system can do.

> The more we allow marketing minds to take control of our IT decisions over reasonable technical minds

Literally laughing out loud at the idea that marketing people are behind microservices.

Re: Why our team cancelled our move to microservices

#128

Post by habibur »

dzhiurgis wrote: post #39
linuxdude314 wrote: post #5

Earlier quoted context omitted.

Do you not version APIs you design? When engineering an API meant for consumption by disparate services it’s imperative to provide back words compatibility. This is pretty basic stuff anyone designing a serious API should be taking into account.

Sure we do, it's been /v1.0/ for the last 2 years!

All API that I am running had been v1 the whole time.

Re: Why our team cancelled our move to microservices

#129

Post by xtracto »

hdjjhhvvhga wrote: post #74
Clubber wrote: post #40

Earlier quoted context omitted.

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…

Well, SOA is such a broad term. If you include CORBA, you could say it's terrible. On the other hand, gRPC is a pleasure to work with if you need to deal with different environments.

> On the other hand, gRPC is a pleasure to work with if you need to deal with different environments.

I remember doing RPC via Java RMI and Jini at some point early in my career in the late 90s. It was really nice and gRPC reminded me of that.

Re: Why our team cancelled our move to microservices

#130

Post by throwaway894345 »

staticassertion wrote: post #99
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…

> 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. Meh. In order to sound smart on HN it's easiest to point at something and call it "hype". > Microservices are relatively new and unproven SOA is old as fuck. Microservices are also fairly old, but especially when you cons…

That’s exactly what Big Microservices wants you to think.
Post reply on HN