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

151–160 of 243 posts

Re: Why our team cancelled our move to microservices

#151

Post by karmakaze »

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.

2 Pizza-sized per service is the rule of thumb. I'm happy with even somewhat less, as long as the scope narrows accordingly and there's CI/CD/infrastructure support experience deploying many services.

Re: Why our team cancelled our move to microservices

#152

Post by ironmagma »

throwaway894345 wrote: post #141
whimsicalism wrote: post #62

Earlier quoted context omitted.

> What have you gained? Separation of responsibilities? Easier to analyze because you only have so many inputs and outputs to a simpler system? Debugging something that touches a lot of paths in a monolith can be quite nightmarish as well.

Also, security. Each component has an identity and it’s own set of permissions so the custom emoji widget doesn’t have access to the payments system or the health data.

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.

Re: Why our team cancelled our move to microservices

#153

Post by karmakaze »

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.

Re: Why our team cancelled our move to microservices

#154

Post by dwheeler »

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.

Re: Why our team cancelled our move to microservices

#155

Post by twblalock »

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.

Re: Why our team cancelled our move to microservices

#156

Post by ironmagma »

whimsicalism wrote: post #103
ironmagma wrote: post #81

Earlier quoted context omitted.

> you only have so many inputs and outputs to a simpler system? Doesn't a function only have so many inputs and outputs too? Scope capturing/global variables aside.

> Doesn't a function only have so many inputs and outputs too? Scope capturing/global variables aside. Sure, and a microservices architecture to me implies a larger movement towards function-esque, idemopotency, analyzability and away from global state. To me, monolithic architecture implies global shared state that is difficult to reason about.

It’s been mentioned elsewhere in this thread, but the lack of microservices doesn’t imply a global shared state. There’s a big difference between a large service that has well isolated modules, and a large service where all the state is contained in one struct, for example. I feel this issue is pitched as a false dichotomy.

Re: Why our team cancelled our move to microservices

#159

Post by throwaway894345 »

winternett wrote: post #150
serial_dev wrote: post #102

Earlier quoted context omitted.

Microservices make sense in some scenarios. I work at a large retail company with who knows how many developers. We have different teams for payment, promotions, product search, account, shipping and more. All of them working on a single codebase with coordinated deployments would be a nightmare. Previously, I joined a startup (previous coworkers of mine), a developer and a business guy. The developer "drank the micr…

This is agreeably congruent with my original statement, The main problem I have with microservice marketing: It is often promoted to clients that do not have applications that are large or critical enough to warrant leveraging them. That buyers often are properly warned about their inability to easily migrate if they invest in platform-specific microservices too heavily. And clients are often not aware of the operati…

You’re confusing “microservices” with dependencies on a particular platform (presumably cloud providers). Microservices aren’t more likely to have these dependencies, as monoliths are often also deployed on cloud providers and assume a particular database, etc.

Anyway, if you’re dealing with microservices “lock-in” isn’t a real problem—you just move one service over to your new platform at a time. Good luck doing that with your monolith without decomposing it into services (and frankly, if you can feasibly decompose your monolith into services, your architecture is probably cleaner than 95% of monoliths out there).

Re: Why our team cancelled our move to microservices

#160

Post by [deleted] »

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…

[deleted]
Post reply on HN