Why our team cancelled our move to microservices • Hacker News Board

Re: Why our team cancelled our move to microservices

#111

Post by henryfjordan » Tue, Jan 25, 2022, 10:54 PM UTC

Softcadbury wrote: post #43

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.

Can you say more about that ? I'm a DotNet developer and I don't see how this could be possible without having several applications

If a monolith has routes /a and /b, you can deploy the whole service to 2 servers with a proxy where all of the requests for /a goes to server 1 and all the requests for /b go to server 2. Server 1 has all the code to respond to /b but will never see that request.

Re: Why our team cancelled our move to microservices

#112

Post by staticassertion » Tue, Jan 25, 2022, 10:57 PM UTC

duxup wrote: post #108

staticassertion wrote: post #101

Earlier quoted context omitted.

ISBN-13: 978-1491950357 ISBN-10: 1491950358 Here you go, you can read this book and it explains.

I know what the terms means, but I think in common language people mean different things when you find out what they are doing.

Oh, sure. People are wrong a lot.

Re: Why our team cancelled our move to microservices

#113

Post by edude03 » Tue, Jan 25, 2022, 10:57 PM UTC

dvt wrote: post #67

A few points I'd like to make: 1. You can't "migrate" to microservices from a monolith. This is an architectural decision that is made early on. What "migrating" means here is re-building. Interestingly, migrating from microservices to a monolith is actually much more viable, and often times just means stick everything on one box and talk through function calls or IPC or something instead of HTTP. Don't believe me? S…

> Microservices does not mean Kubernetes. The idea that to properly implement microservices, you need to set up a k8s cluster and hire 5 devops guys that keep it running is just flat-out wrong.

You don’t need to use kubernetes but I strongly believe it’s the best choice if you’re not using FaaS. If you pick nomad or bare vms you’ll spend a lot of your time building a framework to deploy/monitor/network/configure etc your services whereas kubernetes has “sane” defaults for all of these

That said - you should use managed kubernetes and not deploy it from scratch

Re: Why our team cancelled our move to microservices

#114

Post by jedberg » Tue, Jan 25, 2022, 10:59 PM UTC

wpietri wrote: post #104

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…

One of the questions I like asking developer pals is what ratio their company has between engineers and services/deployable units. Anybody reading this care to share? For me, that number says a lot more about the day-to-day life of devs than the microservices vs monolith label does.

I don't remember the hard numbers, but on average each service at Netflix was maintained by about 4 people but there were outliers in both directions. Sometimes there were four or five services maintained by one person, and sometimes there was one service backed by a team of 25+.

The other important number was that about 25% of engineering was dedicated to building the tools to manage the microservices. We didn't work on customer facing software -- the other engineers were our customers. And I found that number to be pretty consistent amongst any company that was fully invested into microservices.

Re: Why our team cancelled our move to microservices

#115

Post by Melatonic » Tue, Jan 25, 2022, 11:02 PM UTC

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…

Pretty sure "Monolith" was originally designed by a weird team of space aliens who left one on the Moon and Europa :-)

Re: Why our team cancelled our move to microservices

#116

Post by edude03 » Tue, Jan 25, 2022, 11:03 PM UTC

wpietri wrote: post #104

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…

One of the questions I like asking developer pals is what ratio their company has between engineers and services/deployable units. Anybody reading this care to share? For me, that number says a lot more about the day-to-day life of devs than the microservices vs monolith label does.

We are currently between 3-7 services per dev depending on how you count (~40 services developed in house, ~70 if you include third party micro services we run)

It would likely be insurmountable if not for using kubernetes, we choice the idiomatic options (gke/GitHub actions/Argo/Prometheus/etc) so starting with micro services wasn’t too bad

Re: Why our team cancelled our move to microservices

#117

Post by fleddr » Tue, Jan 25, 2022, 11:04 PM UTC

An example to show you how easily the idea of "boundaries" breaks down...

We need to show customers a list of products they registered in a scrollable list. The product registration data is basically a product ID, the user ID and date of registration. It does not contain actual product details.

The product registration data is in one database whilst the product details data is in another. Each has their own data store, API and team.

So it's a classic join problem. To show the customer a list of their registered products including the product name and a thumbnail of it, a call has to be made to get the list of product registrations, plus several dozens of individual calls to get the product details (name, picture), one call for each item.

It's terrible UX. Slow and jumpy.

Yes, I know...a monolith would also struggle with this scenario as the data sources are split for organizational reasons not relevant to discuss here. You might also create a new service that somehow joins these data sources, although I'm sure that might be an anti pattern.

What is the best solution isn't really my main point, rather that boundaries are not typically respected, whether it is at data level or at service level. The real world doesn't care because data and services are not products. Furthermore, when designing these boundaries you absolutely can not foresee how they're going to be used.

As such, it is incredibly common that for an app/web developer, the API fails to meet needs. It doesn't have the data, you get too much of it, or combinations of data are not efficient to get. In my experience, this is the norm, not the exception.

There's another downside. Now that your services are maintained by autonomous teams, guess what...they really are autonomous. That extra data that you need...sorry, not on our roadmap. Try again in 6 months. Sorry, another team is building a high prio mobile app, their needs come first.

A boundary is not a feature. A boundary is a problem. It makes everything inefficient, slow and complex.

I'm not closed minded, there's a time and place for micro services but I would consider it a last resort. Only do it when having explored all options to avoid it and when things really are bursting at the seams.

Re: Why our team cancelled our move to microservices

#118

Post by giaour » Tue, Jan 25, 2022, 11:05 PM UTC

beebmam wrote: post #33

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.

My experience is the opposite of yours. Teams I've worked with get massive freedom to implement their services with any (reasonable) language + framework: Rust, Python, Java, Go, C++, C#, and so on. Seems like an organizational decision

My experience was mostly at small companies with dedicated ops personnel and in government. I worked with a large number of teams that had been chartered with implementing microservices within government agencies, and every single one of them was told what stack they were going to use, either by agency leadership or by infosec personnel.

There was slightly more freedom of choice when I was at AWS, but compliance requirements and tooling support basically strongly encouraged everyone to adopt a standardized stack.

All of which is to say, I get that what you're describing is in theory what microservices are supposed to allow, but I have yet to see it actually work that way in practice.

Re: Why our team cancelled our move to microservices

#119

Post by noway421 » Tue, Jan 25, 2022, 11:06 PM UTC

From what I gather microservices architecture works in a large enough organization where there are enough teams to manage each individual microservice. If your business logic allows for nicely isolated modules, which can almost act as separate "products" that each individual team builds and then the rest of organization dogfoods, then sure. But if there's a single underlying dependency, that won't work. If there're complex interdependencies, it won't work (as nicely). If you have a small team, it won't work. If requirements frequently change, it won't work.

Ultimately works well if you have something very high scale with enduring set of requirements.

Re: Why our team cancelled our move to microservices

#120

Post by kgeist » Tue, Jan 25, 2022, 11:07 PM UTC

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 overcomplicate everything for us, and the performance would suffer.

As for microservices, we usually use them for:

1) critical infrastructure which needs to be fast and scalable (for example, the auth service)

2) isolated helper services, for example a service which allows to integrate with third-party platforms

3) isolated features/products which minimally interact with the rest of the system; for example, we have an optional feature which shares the UI with the rest of the application, and uses some of its data, but ultimately it's a product of its own, it's developed separately with its own codebase, and integrated into the monolith

So I think it's a false dichotomy that you either have a monolith, or microservices. You can use both, they can complement each other.