Exactly my thoughts

Microservices is a newer term than SOA.

They are not the same thing! Microservices is a discount version of SOA with a new coat of paint.

Clearly. But it’s also SOA taken to the extreme!

Exactly, just use well-factored services of any size and smack anyone saying "micro..." with a wet towel for they are just parroting some barely-profitable silicon valley money sinks.

I don't want to get too tied up in the terminology, but "microservices-first" does not seem to be the problem the post is describing:

One way to mitigate the growing pains of a monolithic backend is to split it into a set of independently deployable services that communicate via APIs. The APIs decouple the services from each other by creating boundaries that are hard to violate, unlike the ones between components running in the same process

Without getting tied up in the whole "every language except assembly, Python and possibly JavaScript already solved this problem by forcing people to adhere to module-level APIs" argument, I think the crux of the issue is that the article just defines microservice architecture as any architecture consisting of multiple services, and explicitly states "there doesn’t have to be anything micro about the services". Which imho is watering down the term microservices too much. You don't have microservices as soon as you add a second or third service.

I think we should start calling this Pendulum Blindness.

We just go from 'one' to 'too many' as equally unworkable solutions to all of our problems, and each side (and each person currently subscribed to that 'side') knows the other side is wrong. The assumption is that this means their side is right instead of reality, which is nobody is right.

The moderates are right, but their answers are wiggly and they're too busy getting stuff done to argue with the purists. But the optics are bad so here we go again on another swing of the swingset.

'Some Services' is probably right, but it varies with domain, company size, and company structure (Conway's Law). And honestly developer maturity, so while 7 may be right for me and my peers today, in a year it might be 6, or 9. There's no clever soundbite to parrot.

I've been looking for a concise soundbite (ironically) for this exact issue and Pendulum Blindness definitely fits what I've been trying to summarize.

Going to definitely yoink it for next time I have this discussion. It applies to so many things!

> There's no clever soundbite to parrot.

Introducing the Revolutionary "Ten Service Applications" – because Ten is the Magic Number!

Tired of the endless debates about how many services your applications should have? Frustrated with the constant struggle to find the "Goldilocks" number of services? Look no further! The future of software design is here, and it's as easy as 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10!

The "Ten Service Applications" model is here to rescue you from your software design woes. We're not messing around with random numbers like 7 or 12 services. No, we've cracked the code, and it's all about that perfect "ten." You don't need any more services, and you definitely don't need any less. Ten is the answer to all your architectural problems!

So, are you ready to embrace the simplicity, predictability, and coolness of the "Ten Service Applications" model? Join the revolution today and experience software development like never before!

Act now, and we'll even throw in a bonus "Top 10 Services" list to inspire your next project. But remember, you only get 10 services, no more, no less—because why mess with perfection?

You have for sure worked in sales before, amazing write-up

You might like "Software Architecture: The Hard Parts." Though you already describe some of the points of the book. There isn't a magic bullet and every decision to split something apart or which parts to combine has various trade-offs.

The book isn't perfect. The use of afferent and efferent terminology and some of the arbitrary methods to put numbers on decisions weren't ideal. Most of the concepts are sound. The fact that almost every decision has cost/benefit and real world implications for a living product was refreshing. That a monolith can't be cut over instantly with zero effort to a perfect system is absolutely true.

It's good food for thought for anyone considering slicing up a monolith, but maybe don't follow it to the letter.

For some reason, most of the people I've worked with recently are either fully into monoliths or lots of fine grained, interdependent microservices.

They don't seem to understand there's a useful middleground of adding fewer, larger data services, etc. It's like SOA isn't a hot topic so people aren't aware of it.

I've been using the term 'macro-services' to describe this middle ground.

We used to just call them, "services"

Microliths

Start with a monolith and scale out the parts as needed.

This is why I prefer the old term "service oriented architecture" over "microservices". "Microservices" implies any time a service gets too big, you split it apart and introduce a network dependency even if it introduces more problems than it solves.

It's a pretty common issue. If you have 2-3 services, it's pretty easy to manage. And if you have 1000, you likely have the infra to manage them and get the full benefit.

But if you have 20 engineers and 60 services, you're likely in a world of pain. That's not microservices, it's distributed monolith and it's the one model that doesn't work (but everyone seems to do)

A "microservice" solves scaling issues for huge companies. If you have 60 microservices, you should probably have 600 engineers (10 per) to deal with them. If you're completely underwater and have 10 services per engineer, you're 100% absolutely play-acting "web-scale" for an audience of really dumb managers/investors.

It's not clear to me what you mean by dealing here. Do you mean developing? If so, I completely agree. If you mean deployments, a small number of engineers can manage hundreds of them easily.

I ended up getting into a few arguments at work with the over excited engineer in my last place. He wanted microservices. I said it was just going to add complexity. The app was already a mess, adding network calls rather than function calls wasn't going to help. We had a small teas - 3 backend devs, one of them doing mostly devops and two frontend.

With proper devops tooling and a half decent design, even a junior engineer can manage several microservices without issues. Since microservices are about scaling people as much as they are about scaling tech, 10 people in one service is a lot to me in that world.

The best company I worked at had about 5-10 deployable per engineers on average and it worked really well. They were small, deployed almost instantly, dependencies were straightforward, etc.

Monoliths work fine too, it's just different tradeoffs.

It depends on how you do it. We have 5 engineers and around 50 services and it’s much easier for us to maintain that than it was when it was monolith with a couple of services on top.

Though to understand why this is, you would have to know just how poorly our monolith was designed. That’s sometimes the issue with monoliths though, they allow you to “cut corners” and suddenly you end up with this huge spiderweb mess of a database that nobody knows who pulls what from because everyone has connected some sort of thing to it and now your monolith isn’t really a monolith because of it. Which isn’t how a monolith is supposed to work, but is somehow always how it ends up working anyway.

I do agree though, that the “DevOps” space for “medium-non-software-development” IT departments in larger companies is just terrible. We ended up outsourcing it, sort of, so that our regular IT operations partner (the ones which also help with networking, storage, backups, security and so on) also handle the management part of our managed Kubernetes cluster. So that once something leaves the build pipeline, it’s theirs. Which was surprisingly cheap by the way.

I do get where you’re coming from of course. If we had wanted to do it ourselves, we’d likely need to write “infrastructure as code” that was twice the size of the actual services we deploy.

> designed. That’s sometimes the issue with monoliths though, they allow you to “cut corners”

I find this hard to relate to, the idea you have the discipline and culture to do microservices well if you can't do it with a monolith.

More likely is you migrate away from the monolith you never invested in fixing, and once you get to microservices you either call it a mistake and migrate back, or you have to eventually finally invest in fixing things.

Perhaps your microservice rewrite goes well because you now know your domain after building the monolith, that is another option.

With the microservice architecture it’s easier to lock things down. You can’t have someone outside of your team just give access to a dataset or similar because excel can’t get a connection directly into your DB. Which is an argument you could rightfully make for monoliths, except in my experience, someone always finds a sneaky way into the data on monoliths, but it’s too hard for them to do so with MicroServices.

If you gave me total control over everything, I’d probably build a couple of monoliths with some shared modules. But every time the data is centralised, it always somehow ends up being a total mess. With MicroServices you’ll still end up with a total mess in parts of the organisation, but at least it’ll be in something like PowerBI or even your datawarehouse and not directly in your master data.

Or to put it differently, for me MicroServices vs monoliths is all most completely an organisational question and not a technical one.

It's not like microservices don't also give you chances to mess your data up. It's hard to do transactions across boundaries, you have to deal with eventual consistency, sometimes there is no single source of truth.

I struggle to see how microservices fix this for people; having worked primarily with them for the past 6 years.

The thing with microservices is that shit doesn't have to infect everything. If someone in another team is clueless, they'll mess up their microservices but not anyone else's. If they are in a monolith, it's 50/50 based on how much clout they have (either they mess it up for everyone, or they get talked down and don't get to mess up their stuff either).

Unless it's a shared library, which is why good microservices architecture limit the shared surface as much as possible.

> it's 50/50 based on how much clout they have (either they mess it up for everyone, or they get talked down and don't get to mess up their stuff either

This still happens with microservices though; people can still make terrible architecture decisions and standup terrible services you depend on.

A distributed monolith isn't based on how many services you have, a better question is, how many services do you need to redeploy/update to make a change.

Yes, by the time you get to thousands of services you hopefully have moved past the distributed monololith, if you built one.

>> That's not microservices, it's distributed monolith and it's the one model that doesn't work (but everyone seems to do)

I called ours a macrolith.

I have worked with a company that had around 8 developers and 30 'microservices'. They wanted the front end team (fully remote, overseas, different language, culture) to go micro front end. They are awesome at presentations and getting funded tho. A common theme in European startups.

Actually, you are wrong. Microservices are surely not about defaulting to new microservices, but to capture a specific context into one service. There is no rule about how big a context is. A context can contain other context's. There can be technical reasons to split deployments into different microservices, but that's not the norm. What you describe is what happens, when people get microservices wrong.

In the end, i like the viewpoint that microservices are a deployment pattern, not so much an architecture pattern. Usually, you can draw a component diagram (containing an OrderService and a DeliveryService, etc.) and without technical details (execution environment, protocols), you couldn't tell if it's describing multiple microservices or multiple components in one service.