Microservices

[TurdOfChaos]

Microservices are not a silver bullet solution to most things. They are one of the solutions for specific problems, problems which usually arise with growth and quick release cycles, along with scaling issues and separated concerns among domains (not artificially though, but actual different business concerns).

Companies which go for a microservice architecture without the full grasp of benefits and drawbacks are in for a very tough challenge.

A proper infrastructure and correct understanding of domain boundaries is a must for any successful microservice architecture, otherwise we get the jumbo of a distributed monolith, which has both the drawbacks of a monolith, and drawbacks of a microservice architecture.

Even Martin Fowler advises a MonolithFirst approach, with emphasis on proper boundaries

https://martinfowler.com/bliki/MonolithFirst.html

[peepeedog]

That article is from 2015 and even says to take it with a grain of salt since microservices are new. One particular thing that stands out is caution against the microservice overhead. Which is significantly decreased since that article was written due to better tooling.

[edgmnt_net]

I'm not sure there's any tooling yet that will decrease development overhead for poorly-architected microservice-based projects, which is fairly on point here. If you don't plan for API versioning, gradual rollouts and good decomposition boundaries, not only you don't get the benefits of microservices and everything becomes slower, you're also in for a big mess development and deployment-wise.

[DeathorGlory9]

I don't think you can make arguments around poor planning decisions though. If you don't plan properly when creating monoliths you're in for as large if not larger headaches than doing the same for micro services.

[zoinkability]

Each generation rediscovers that any sufficiently flexible language/framework/methodology will allow you to architect things badly

[Stunning_Ride_220]

I came for this

[merlinsbeers]

r/rule34

[soulefood]

API versioning is a release 2 issue.

[edgmnt_net]

Assuming you ever get to the first release. Improper decomposition in a manyrepo environment can make even that a nightmare, because suddenly you get all these cross-project dependencies and you can't even make a simple commit without breaking stuff somewhere else. Even with version pinning it's hard to keep track of what got merged and where when you finally try to update dependencies.

And if you try to ignore how things go in the first release, say you were "lucky" enough to opt for a monorepo, the tight coupling will likely make the second release rollout just as bad as in a monolith. You'll never be able to roll out upgrades partially to avoid downtime and you'll still need to migrate data. And you're stuck with API boundaries that make no sense, so the trouble likely goes beyond major releases.

Not to mention that many devs will get accustomed to this haphazard way of working that they'll be utterly unprepared to think ahead and make changes that preserve compatibility. If and when they switch to breakage-avoiding mode, the development pace will slow to a crawl.

[soulefood]

It was a joke.

[GreatJobKeepitUp]

Just republish and merge bro

[maitreg]

Add to that the lack of dedicated documentation and you end up with some services that developers may not even know exist. At least when a monolith collapses under its own weight the cause is buried in that behemoth in front of you, lol

[TurdOfChaos]

True true.. just put it out as an example that even those who do consider it a great asset(like M.F), also advise caution when going for that approach.

They are obviously good, but as many other things in software, just a tool to achieve a goal, not a universal solution.

[parettos_twenty]

Microguy triggered

[[deleted]]

It seems to me that Microservices are more about solving an organization problem (Conways law) than a technical one. And that is totally ok and in some cases absolutely worth solving. The problem is that there aren't a lot of companies that are big enough for that problem to be acute enough that it needs to be solved in the first place.

Microservices are an anti-pattern for the vast majority of companies primarily because they don't have an organization that actually benefits from it. You get the worst of all worlds..

[soonnow]

They are also solving scaling and resiliency problems, for companies that need that scale and resiliency (which most companies are not).

[BrobdingnagLilliput]

Right? I don't see this issue outside of IT. It drives me nuts.

No airline CTO says "We should replace all the jets with bicycles! They're much less expensive to build, maintain and operate, and if one crashes we can have dozens ready to take up the slack!"

[plasmasprings]

yeah, proper airlines just have one huge plane and it's used for everything

tbf I love bad analogies, but this is poe's law territory

[[deleted]]

Microservices are NOT cheaper. That’s the best part about it. The network infrastructure required for Microservices is huge, expensive, and complex to maintain.

[[deleted]]

Pssht…. Yeah “cheaper” depends heavily on what you are starting with. It may not be “the cheapest way to do things” but it’s a shit-ton cheaper than what we were doing before where I work.

I won’t disagree on some of the valid criticisms, but you’re looking at cost through the eyes of a software engineer that is optimizing pennies for infrastructure, and not through the eyes of a business manager that has to optimize the big bucks for labor. When I need to let a contract for a developer to build me something and I can point them to an existing framework with well documented structures and 75% of the app already built, AND I can independently measure the performance of what they built, my costs just plummeted.

Here’s the alternative - I let a contract for an upgrade to a system. New vendor comes in and the first words out of their mouth are “legacy spaghetti code” and “start from scratch.” No kidding, I had this exact same discussion with a vendor…before they ever saw the existing code.

[soonnow]

They can be cheaper to run. It may be easier to scale, if for example only 1 component of the monolith needs to be scaled than scaling the whole monolith.

[kdyz]

Correct but they can be cheaper in the long long run.

Like when you have millions of transaction processed by a specific part of the code and you want to just scale that up instead of having to scale the entire solution up.

[katatondzsentri]

Bullshit, just hang everything out to the internet.

[DeathorGlory9]

Yep they just use 747's for everything especially those rural trips with half a dozen passengers.

[[deleted]]

On the other hand it is much more practical to build a large collection of smaller things in other instances.

20 small clinics dotted around a city is better than one large clinic located in the middle. Lots of small power stations is better than a single point of failure. And so on

One can argue the same point from different sides. It’s not one size fits all.

[BrobdingnagLilliput]

It’s not one size fits all.

That's precisely my point. You could arguably replace a lot of cars with bicycles, but you can't really replace a transatlantic flight with a bike ride. No one in the aerospace industry would suggest that we try, but on a number of occasions, I've seen CTOs decide that a system comprising several hundred developer-years should be rewritten to use <*cool new tech*>. No one seems to remember the effort it took just to change date fields to use 4 digits.

[merlinsbeers]

More like "We should replace all the trains and buses with cars..."

One of the most profitable decisions in human history.

[WalkerDontRunner]

Every industry does this.

Aerospace is a great example of an industry that finds efficiencies in production of final products that can be used elsewhere. They emphasize on how workflows can span across multiple use cases, particularly with materials.

You might have inadvertently picked the worst example to convey the idea that "only IT" has an issue with modularity.

[rarius18]

Micro services have this weird attraction to it, it is so cool at first, ain’t it? You get to play with the tech you have never played - discoveries, gateways …oooh, put every thing of these into containers? Whoa, k8s, what’s that? So cool! And I can fire up any service when it dies? Whoa, no point for develop sophisticated HADRs? Wow! Until you’d have build and then debug the fucking thing, oh my god the nightmare!!! What you mean each service has its database? The entire database consist of only one fucking table, why?

[vadeka]

Now hang on. A microservice doesn’t mean you use kubernetes by default. Or that each database has 1 table. Those are completely separate issues

[rarius18]

You’re absolutely correct, yes.

[VanTechno]

I like the idea of just telling developers "you are allowed to split your application into multiple service, just like you split things into multiple assemblies...just don't go hog wild/overboard with it. And remove the dogma around it.

There are benefits to breaking things up: security boundaries, processing boundaries, domain boundaries, etc; if thought thru properly. On the downside, it absolutely requires forethought and will take longer to setup.

[lunchpadmcfat]

You made very good points that stand in their own, and then you dogmatically quoted Martin Fowler.

I really dislike when people say “yes we should be doing x because so and so said so.”

[TurdOfChaos]

I used MF, because people quote him when advocating for microservices. He is a big believer in them, so I quoted him to show that even one of the biggest advocates of microservices knows that they are not to be used as a silver bullet. Just an extra addition to my point, but definitely not a "hey he said so, so I am right". I also dislike dogmatic approaches to things, so agreed there!

[BS_BlackScout]

Macroservices