Live data from Hacker News

Why our team cancelled our move to microservices

steven-lemon182.medium.com

91–100 of 243 posts

Re: Why our team cancelled our move to microservices

#91
post #34

Earlier quoted context omitted.

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

I think the problem is there's no popular framework that makes this easy (or is there?)

Re: Why our team cancelled our move to microservices

#92
post #63
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.

It will eventually happen even if you manage to create the perfect boundaries, e.g for report & statistics.

Reports and statistics, especially on material that crosses service boundaries (but even on single-service information, to keep services single-responsibility) are their own logical services, which operate on copies of data received from (often multiple) upstream services. (In many real world cases, you’ll want this functionality in a data warehouse, but there are some cases where some of it may be in something that looks like normal services, whose data that can change other than by push from other services deals with reporting and report-delivery configuration, not the business data on which reporting is done.)

Re: Why our team cancelled our move to microservices

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

Yeah, honestly this should be the entire content of the article. Not only do they only have two small teams but they all overlap completely anyway. There is no reason even a significantly larger org - say 40+ people in 8-10 teams cannot work effectively in a single repository and monolith architecture. Beyond that there are certain growing pains and if you don't effectively manage those then I could see how you end up going with micro-services.

Beyond scaling a large development org the primary benefits of micro-services accrue to consultants who bill by the hour.

Re: Why our team cancelled our move to microservices

#94

I'm not speaking from experience here, but it seems like rather than "moving to a microservices architecture" it would perhaps be better to think more in terms of "splitting out specific functionality X into an independently deployable and hostable service, which should alleviate the specific problem Y that we've been experiencing due to their being too closely coupled" and if there are no obvious X and Y then maybe…

For sure. Find a problem first, then look at solutions. Try one out, see if it helps. If not, try a different solution.

Man-with-a-hammer syndrome is dangerous.

Re: Why our team cancelled our move to microservices

#95
post #9
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?

Generally speaking if you're adding another field to a JSON or something, that doesn't really break the parser [1] or affect downstream. While you should still probably let the downstream teams know, it's not necessarily going to break anyone's code. [1] I'm aware that that's not always true (e.g. adding a field that's ridiculously large choking up the parser).

or you have a customer that has strict validation on and adding a field breaks their ability to deserialize.

Re: Why our team cancelled our move to microservices

#96
Going from a monolith to a micro-service setup is essentially my idea of a Christian hell. Swirling depths of pain and uncertainty interspersed with screaming and urgency. There is no rest. No one knows when it will end.

I think this is because our monoliths are so complicated they hide away our technical debt like monstrous Jack-In-The-Boxes. When you start breaking it into chunks all of these issues come exploding out of them. Suddenly huge bugs that no one noticed or cared about are showing up in testing. Old libraries that sat dormant wake from their crypts to harass and torture junior developers. Forgotten binaries whose source code was lost with the changeover from ancient source control software to GIT starts showing up security issues in VeraCode.

Really, a well coded monolith is just a bunch of micro-services on the same server communicating through memory. In reality it's more of a Lich who's eyes shine with the light of the tortured souls of fallen QA testers and developers.

Re: Why our team cancelled our move to microservices

#98
post #85
post #42

Why would you consider microservices if you are only 12 developers?

Most of the conversation so far has focused on the development benefits of microservices (decoupling deployments, less coordination between teams, etc). Small teams don't really have this problem, but there are other benefits to microservices. One of the biggest is scaling heterogeneous compute resources. Suppose, for example, your webapp backend has to do some very expensive ML GPU processing for 1% of your incoming…

So sure, maybe make the ML model a separate service, but you don't really have the same driver for other services; state-less server processes tend to need the same type of resources only in different amounts, and you don't really gain anything by splitting your work load based on the words used in your domain description.

Real-world monoliths often do have some supporting services or partner services that they interact with. That doesn't mean you need a "micro-service architecture" in order to scale your workload.

Re: Why our team cancelled our move to microservices

#99

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 consider they're really just SOA + dogma.

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

No? Not at all.

> Instead of being charged for one single server annually, on microservices you can be charged for many individual components that run your app independently, and when usage skyrockets, it's a sticker shock that you can only stop by going offline.

Alternatively phrased: If you only use one service you only pay for it, not for the whole suite of features you don't need or want.

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

And plenty of success stories.

> We need to stop disparaging traditional (non-cloud) hosting and solutions that aren't obsolete at all in this manner, and focus on what works, what is secure, and what is cost effective in order to stay sustainable into the future.

Microservices work, are secure, and are cost effective.

Honestly your post contains no useful information and is satirically close to a "return to traditional family values!" speech.

Re: Why our team cancelled our move to microservices

#100
post #96

Going from a monolith to a micro-service setup is essentially my idea of a Christian hell. Swirling depths of pain and uncertainty interspersed with screaming and urgency. There is no rest. No one knows when it will end. I think this is because our monoliths are so complicated they hide away our technical debt like monstrous Jack-In-The-Boxes. When you start breaking it into chunks all of these issues come exploding…

Agreed, however I've experienced something worse: trying to refactor domain models across an SOA that was poorly factored to begin with, and then layered 10k eng-years of incremental feature development driven by a fractured product team with short average tenures.
Post reply on HN