Big corp wins while their customers create DevOps and other buzzword teams and the majority of IT world loses the capability to actually administer systems and becomes users addicted to ever-changing vendor offerings that complicate learning useful stuff outside.

I always can't help but to think most of these articles are written by engineers working at 30 people startups or something. And there's definitely a lot of org-size and structure between the startup and a faang-sized tech giant.

A garbled knot of interdependent microservices with timing issues, bad extensibility, and unpredictable flow.

An ornate matroyshka set of wrapper functions calling each other spreading over multiple directories making any modification a large error prone effort.

Event systems, probably multiple, without any real difference between just a function call other than your debugger getting very confused by it.

Database schemas with table names that exude the narcissism of small differences with nitpicky rules that make it explode if any flexibility is demanded

Aws bill that's 10x more than any reasonable expectation given the problem set.

An object oriented design that looks like some kind of fetishized exercise of every feature possible, where defects cascade to action at a distance and unintended consequences with tight coupling that can't be extricated leading to a rewrite, just like it did last time

They are the people who create the waterfall of dozens of levels of div tags for no functional reason other than to accommodate their incompetency

They are the ones that want to pollute your entire day with needless meetings over irrelevant things that will not be acted upon.

Of course there's no useful comments or tests or documentation. The git comment messages are single words like "fix" and "rewrite". There's no versions in the deploy or a reasonable approach to logging that allows a successful audit and the thing is too state dependent to reproduce bugs.

Then there's dependencies, loads of them just picked seemingly at random, written by people who think like them with the same disregard for documentation, compatibility or testing. But they have very pretty websites which says they're painless, simple and easy, so I guess it's all ok right?

The problem with microservices is the same problem with anything else and changing paradigms won't fix it. The approach needs to change, not the technique. It's a different kind of budo.

The power of a concept isn't in the need but in how well it optimizes the process.

Microservices instantly looked like a fad. Two classes of fad apply. One is a "move stuff around and complexity will magically go away" fallacy fad. The other is a "way to promote vendor lock-in or higher cost" fad.

Other major classes of fads are: consultant self promotion fads, re-invention fads of all kinds in which devs speed run the history of some aspect of computing to arrive at the same place, magic pixie dust fads where sprinkling some buzzword on things makes everything better, management "methodology" panacea fads, etc.

Avoiding fads is a superpower. It tends to save a whole lot of money and wasted time.

The test of whether something is a fad is whether it reduces incidental complexity, enables something categorically new, or genuinely boosts developer velocity.

Incidental complexity is the complexity that creeps into our designs that is not essential to the problem but an artifact of how we got there or some prior limitation in how things are done. A genuine innovation will make incidental complexity actually go away, but not by pretending that essential complexity doesn't exist.

A categorically new thing would be e.g. deep learning or an actually practical and useful provably-safe language (Rust).

Boosting developer velocity means actually speeding up time to ship without doing so by adding a ton of technical debt or making the product suck.

If something doesn't do at least one of those things well, it's a fad.

Edit: For more context, this opinion is more about "the art of developer management", not much about infra, security, scalability stuff

The service scorecard asks a bunch of reflective questions about the ramifications of making some set of functions a unique service and points its benefits or lack thereof on a scale.

You can isolate pieces of your architecture and simplify them. A lot of issues with microservices inside the system (not user facing) comes from the expectations of what the microservice deals with, the enforced boundry of the microservice, intention of it, and the fact that anyone can connect to it.

Think about streaming data systems. These allow for multiple components connecting to durable queues (with maintence polices) that will process data and pass it along. This is more for data that may take longer, and shouldn't be done in the same request.

Slight personal rant: The crap that I've seen people expect of microservices to do in a request is excessive. (If you're doing more than taking a request, reading+writting into a database.. you're doing too much and your performance is terrible) Additionally there is very little consideration about what happens when a microservice performs badly.

It lets you develop, deploy, and execute AWS Lambda functions from your Laravel application.

The theory here is that sometimes you need some other language/infrastructure beyond what you're comfortable devops-ing yourself, and Lambda is actually quite good at providing you with an entire stack of stuff you don't have to own.

So if you need a single Node, Python, or Ruby function you can put just that part on Lambda and still call it from Laravel as if it were a native PHP function. No API gateway or anything to muck about with, either.

Is it a true microservice? Not really, although who knows what that actually means. It does allow you to take advantage of some parts of microservices without the pain though!

[1] https://github.com/hammerstonedev/sidecar

It is true that probably any monolith can be break down into components, that won't prevent the full redeployment (and all the risks that it brings) though.

I think in reality no one needs Microservices, or Monolith for that matter. You would pick the poison that adjust the best to your needs.

I don't think the answer is as easy as "you don't need microservices". I think the answer is "you can effectively use both".

Monolith is an unfortunate term by which everyone seems to mean something different. So is any application whose parts do not communicate via network interfaces a "monolith"? Is an application where the majority of the function calls are not realized as a series of network transactions (like CORBA at that time) a less good application than one where different classes and modules on the same machine communicate directly with each other?

We should stop using the term, nor assigning blanket value attributes to it. "Monolyth" is not the antonym to "Microservices", as suggested by the article. From a certain distance, every system looks like a monolith; that has more to do with the viewer than the system.

I dunno but when I see odds are $X I read unproved and perhaps unprovably, my opinion is $X

We have something like 19 different components. Insane.

Yes, but it also comes with a cost. Microservices might still fail in a cascade manner and bringing such system up under significant load is even more challenging.

You can just shoot a couple of the offending microservices dead and replace them with better implemented versions.

[Assuming there are at least 6 developers]

It's madness. The solution is to avoid the polyglot issue by fiat and to ensure that there is some actual planning and rationale around when it makes sense to add a service. Most groups I've talked to don't even have a good answer to "why is this in a separate service from that?" when asked, and I've talked to a lot of them.

Whereas when microservices were overhyped, they were introduced into orgs/companies that didn't have the brain power/experience to implement these properly or just to be able to say an informed no.

A lot of people, especially smart people, like going "everyone says X, I'm going to try to appear smart by arguing not-X".

And that's how you end up with people in the west going "Russia is the victim of the war in Ukraine! Nato encroachment!", or "they haven't tested the vaccines!"

In the right circumstances, a microservices architecture can absolutely boost developer velocity. You can reduce development/mental model complexity, reduce blocking internal dependencies, increase performance of tooling and deployment, and allow more consistent and less risky deployments. There are certainly costs: infrastructural complexity, a new network boundary between services, increased risk of techincal/product drift.

For orgs where the benefits outweigh the costs, due to scale/org structure/perf concerns/etc it can be an enormous win for velocity. For other orgs it can be a huge velocity killer. It just depends.

This is a great description of microservices

You can have spatial and temporal memory safety by writing single threaded code in any GC language.

I would only seriously consider a move to microservices for deployment/perf reasons.

Moreover, code quality isn't just encumbered by junior devs--in fact, in my experience it's more often managers pressuring developers to take shortcuts (e.g., taking a dependency on another system's private internals in the name of expedience, while swearing up and down that we will totally clean it up in a future iteration) or other organizational hurdles that make it difficult/impossible to fix it the right way, so shortcuts are taken instead (with microservices, the organization has to confront those issues, they can't be easily papered over by bypassing official interfaces).

Another reason to prefer microservices is security--not putting every secret in a single process's memory space is a great way to minimize blast radius if a service is compromised.

Another reason is reliability--if one system has a catastrophic failure mode, it won't take out all other systems. Of course, if the failing system is a core service, then it may not matter, but at least you're not bringing everything down when some service on the architectural periphery goes haywire.

I do question how microservices manage that, though? Tightly coupled microservices ie "the distributed monolith", are a still real danger for teams that don't have enough engineers that know "know how to make loosely coupling architecture"

But if you're a company of 10-20 people all pretty much working on the same code? Microservices just adds complexity and overhead. Deployment, telemetry, documentation, version synchronization, tracing -- everything becomes more complex when you start creating boundaries between sub parts of your system.

For me, microservices are about boundaries. The question is what benefit that boundary provides for the team. For large companies where there are many discrete teams following different processes and release cadences, microservices might be worth the overhead. For small companies, it is wasted effort.

Breaking up an app into microservices is total overkill in this instance...

> Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

If we apply this law backwards, microservices reflect an organizational structure with many teams working on different things so they'd make more sense in that context rather than within a small team.