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

51–60 of 243 posts

Re: Why our team cancelled our move to microservices

#51

Post by [deleted] »

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…

[deleted]

Re: Why our team cancelled our move to microservices

#52

Post by dagss »

pc86 wrote: post #41
jokethrowaway wrote: post #25

Earlier quoted context omitted.

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.

"just picked a bad service boundary" -- well that's the thing isn't it. If you always pick the right boundary up front, something that is perfect both now and also anticipates any kind of future crazy feature request -- if you can pull that off I'd say any architecture will work well.

But most people get boundaries wrong some times. Sometimes very badly wrong. Sometimes the boundaries are historical, set by product owners without technical input, set by junior developer, set by superficial attributes, and sometimes even the most experienced developer-architect just does a mistake.

And the whole point of not doing microservices is you don't have a huge investment in your boundaries, it's more feasible to change them once you inevitably now and then realize you got them wrong.

Re: Why our team cancelled our move to microservices

#53

Post by lemmsjid »

pc86 wrote: post #34
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.

How?

The 'monolith' (which I find a silly term but I'll use it here) can expose different parts of itself as services. As long as those services can be versioned and are backwards compatible, you can deploy the monolith using any schedule or notification mechanism you like.

If the monolith is composed of modules with a DAG-like dependency structure (e.g. maven projects), then pieces of the monolith can be deployed alongside the dependencies they need.

Re: Why our team cancelled our move to microservices

#54

Post by [deleted] »

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…

[deleted]

Re: Why our team cancelled our move to microservices

#55

Post by zoover2020 »

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…

And still done! Fully agree.

Re: Why our team cancelled our move to microservices

#56

Post by pythux »

> 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 looking for a nail, and they had no such nail.

Edit: typo

Re: Why our team cancelled our move to microservices

#57

Post by FridgeSeal »

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.

It’s about trade offs I think.

Monolith can Microservices are so often presented as “x is better than y”, but it should be “which is more applicable for the team size, product and operational concerns”.

Monoliths are a great choice for certain team sizes and applications, want stricter isolation and blast-radius between different teams and products and need to scale different things differently? Micro services are probably a better choice.

Re: Why our team cancelled our move to microservices

#58

Post by noogle »

kgeist wrote: post #46
bilalq wrote: post #14

Earlier quoted context omitted.

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

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

Re: Why our team cancelled our move to microservices

#59

Post by ironmagma »

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.

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?

Re: Why our team cancelled our move to microservices

#60

Post by mykowebhn »

> It is useful to bear Conway’s law in mind when considering the shape of your architecture. It states that your software’s architecture grows in a way that mimics how your organization and teams are structured.

I had always assumed that it was the other way around. Good to be made aware of the alternative.

Post reply on HN