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

181–190 of 243 posts

Re: Why our team cancelled our move to microservices

#181

Post by lelandbatey »

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.

Where I currently work, there are 10 services per developer, actively running (if we're counting in the least charitable manner, maybe 4 per dev with most charitable counting). Our ratio is this huge due to large changes in company size over time. Consolidation is very helpful at this stage. If there's one thing I recommend to everyone who encounters this situation, you absolutely must keep a copy of all the source for all the repos on your computer, all at the same time, to make cross-repo grepping easy. For this purpose I recommend ghorg[0], but however you do it, it'll make everything easier.

[0] - https://github.com/gabrie30/ghorg

Re: Why our team cancelled our move to microservices

#182

Post by TameAntelope »

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.

More people can do operations, and more operations work is parallelizable, so yeah it's a tradeoff but there is upside to that tradeoff.

Re: Why our team cancelled our move to microservices

#183

Post by pc86 »

dagss wrote: post #52
pc86 wrote: post #41

Earlier quoted context omitted.

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

Isn't the point of making services as small as possible so that you can easily shift boundaries? Isn't DDD (a common companion of microservices) all about constantly shifting business domains?

We've gotten boundaries wrong tons of times. We change them, which includes a migration script to move historical data from one service to another, if possible. Yes, it's work, but it's not any more work than having everything crammed into the same monolith and having to deal with all the downsides therein.

Re: Why our team cancelled our move to microservices

#184

Post by ironmagma »

throwaway894345 wrote: post #169
ironmagma wrote: post #152

Earlier quoted context omitted.

This would be true in a monolith as well unless configured otherwise. Functions don’t just start talking to each other; you have to explicitly connect them via a function invocation. I’m not sure how an architecture would change that.

It’s pretty straightforward. In a monolith everything is in the same memory space, so the payment system credentials and routines are available to the whole monolith. In a microservice architecture, one service can’t access the memory or routines of other services.

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 trust them so little as to literally enforce separation this way? No healthy organization should have to resort to this kind of civil war.

Re: Why our team cancelled our move to microservices

#185

Post by TameAntelope »

scottious wrote: post #165
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, but all of that is a cost which you don't have to pay with a monolith. Versioning APIs and having to constantly think about backwards compatibility with independently moving services is not trivial. Sometimes the cost is worth it. Most of the time it's not

Oh, you absolutely have to pay that cost with a monolith, it's just less clear and obvious because you can change all of the consumers when you make a change to an interface.

Re: Why our team cancelled our move to microservices

#186

Post by tentacleuno »

> Because we couldn’t isolate any of our services properly, this was going to mean that we would be left with a significant amount of duplication. For example, we identified one particularly complicated and essential piece of business logic that would have to be copy-pasted and maintained across 4 of the planned microservices.

Wouldn't this piece of business logic be best placed in an import-able module? Then, that module would be imported by those 4 microservices and problem solved ...? I don't really understand this argument.

Re: Why our team cancelled our move to microservices

#187

Post by Twisol »

karmakaze wrote: post #153
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 came looking for this in the comments. Invalidates the rest of the post, really.

The post is very explicitly coming from a perspective of "we didn't know what we were getting ourselves into". The story begins after the decision to move to microservices was made, and the backstory of the decision isn't dwelt on (beyond allusions to top-down pressure from management).

The important lessons here are on how they recognized the mistake before they had fully committed. Having worked on a team with a similar story, it all rings very true.

Re: Why our team cancelled our move to microservices

#188

Post by staticassertion »

tentacleuno wrote: post #186

> Because we couldn’t isolate any of our services properly, this was going to mean that we would be left with a significant amount of duplication. For example, we identified one particularly complicated and essential piece of business logic that would have to be copy-pasted and maintained across 4 of the planned microservices. Wouldn't this piece of business logic be best placed in an import-able module? Then, that m…

Or moved into its own microservice and then RPC'd to from those other services. But yeah.

Re: Why our team cancelled our move to microservices

#189

Post by wafer-bw »

tentacleuno wrote: post #186

> Because we couldn’t isolate any of our services properly, this was going to mean that we would be left with a significant amount of duplication. For example, we identified one particularly complicated and essential piece of business logic that would have to be copy-pasted and maintained across 4 of the planned microservices. Wouldn't this piece of business logic be best placed in an import-able module? Then, that m…

Perhaps the language/stack they were using wasn't condusive to this but honestly I can't think of one where this would be a problem they couldn't solve with a module/package the performs the essential business logic piece.

Re: Why our team cancelled our move to microservices

#190

Post by edgyquant »

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…

Right but the term monolith was used in at the latest in the 80s to describe kernels (monolithic v micro) so it’s a fairly standard term in software.
Post reply on HN