That's why it's important to keep the number of devs low, it makes it less likely that one starts talking about microservices.
In my opinion it makes the backend way more resilient than a monolith.
Don’t kill me for this opinion please ;)
There'll always be critical microservices that keep your app running. It doesn't matter if all your other services are running if the one serving up core functionality goes down.
If your engineering rigor is so poor that you can't get reliable failovers with a monolith, god help you keeping microservices running.
Of course when you replace function calls with network calls, make everything asynchronous and eventually consistent, there is a lot of work to do to not end up with a less reliable system.
A monolith doesn't force a single process. IPC is still simpler and cheaper than network calls.
A monolith doesn't force never having an external service for a specialized use case, or FFI.
I specifically called out the extra complexity of network calls in microservices, not sure if you read the full comment.
> A monolith doesn't force a single process
I'm not convinced; if my small/specific code has it's own process, I would say it's a microservice. Sure, we can have replicas for redundancy, that doesn't mean I won't have reliability issues when my process is crashed.
> A monolith doesn't force a single database.
> A monolith doesn't force never having an external service for a specialized use case, or FFI
True, sadly it doesn't usually work this way. People take the path of least resistance.
Also once you add multiple DBs you start to get into eventual consistency; which is one of the harder parts of microservices.
Calling out networking doesn't preclude me from mentioning IPC. IPC isn't limited to network calls, it can be as simple as shared memory and hit millions of OPS: github.com/OpenHFT/Chronicle-Map
> I'm not convinced; if my small/specific code has its own process, I would say it's a microservice.
And you'd be wrong. A core tenant of microservices is being able to individually deploy your microservices. If I spin up a new process for some high risk, highly memory intensive process I've introduced a fraction of the operational complexity of a seperate server and retained the core value proposition of reducing its blast radius if things go south.
Of course again, if you're having so much trouble handle writing software that's reliable that you being to consider isolating instability as a top benefit from your IPC setup instead of a tiny value add... it might be a sign you're not ready for microservices.
_
> True, sadly it doesn't usually work this way. People take the path of least resistance.
> Also once you add multiple DBs you start to get into eventual consistency; which is one of the harder parts of microservices.
You're making my point: If you don't have the engineering chops as a team to make a robust monolith, you definitely don't have the skills and resources to start looking at microservices.
Eventual consistency is not inherent to having multiple databases. If I have an oft changing ephemeral set of data that only affects one feature and it's creating an impedance mismatch with our main datastore, nothing is stopping us from pulling in Redis for all the queries we were previously sending to Postgres, and as far as anything relying on that feature is concerned, nothing at all changed.
With even half decent engineering, Redis going down doesn't break any differently than it would have for a microservice: you define the same error boundaries as before and the failure case ends up the same.
I mean seriously, if your team can't handle having a second data store, imagine the bedlam when you're trying to handle multiple languages across multiple data sources in a non-centralized manner?
_
Microservices are a pattern for companies where a "microservice" gets the kind of development and devops support that would justify spinning off a new mid-sized enterprise.
When you're Netflix your `api/movies/[movieId]/subtitles` endpoint is serving the kind of traffic most companies will never see in their lifetime and needs optimizations that maybe 100 companies in the world will ever need.
For the rest of us EC2 has 224C/488T CPU 24,000 GB RAM machines with 38 GBPs I/O bandwidth. If your business ever scales so far that you outgrow that, throw some of that X Billion dollar valuation money at the problem and build your microservices.
You made the same point I made as though it was in contradiction to what I said. Adding a network call adds complexity, yes.
> A core tenant of microservices is being able to individually deploy your microservices.
And why would you not want this to be independently deployable?
> You're making my point: If you don't have the engineering chops as a team to make a robust monolith, you definitely don't have the skills and resources to start looking at microservices.
Firstly, you never made that point. Also, I never argued against it, in fact I agree completely.
> Microservices are a pattern for companies where a "microservice" gets the kind of development and devops support that would justify spinning off a new mid-sized enterprise.
Disagree, netflix has >1000 microservices.
Ah, wait it is.
> And why would you not want this to be independently deployable?
Because FAANG has more engineers devoted to managing deployment/observability/version skew/DX/scaling/security than you have engineers. Simplifying your needs in those realms helps you greatly.
And to top that off, it 100% can be independently deployable if it's a big enough separate concern: that's just SOA without the 90's XML/SOAP/RPC spin that was ESB: https://aws.amazon.com/compare/the-difference-between-soa-mi...
_
> Disagree, netflix has >1000 microservices.
That says exactly nothing. At Netflix scale their most random "trivial" endpoints are easily doing scale that entire SMEs won't ever deal with.
When FAANG is your case study in any technical discussion in a public forum, you're default wrong. I work at an AV company, I'm not about to start telling people the insane architecture we need to support ingesting petabytes of data is something that anyone else needs.
Any useful technical discussion needs to be grounded in what the 99% need, and microservices are not it.
Again, at no point did I make an argument for microservices.
> that's just SOA
Absolutely not, from your own reference:
> Each service provides a business capability.
Spinning a high memory task off into it's own process is not a business capability. Microservices are more granluar than SOA services, your describing a microservice.
> That says exactly nothing. At Netflix scale their most random "trivial" endpoints are easily doing scale that entire SMEs won't ever deal with.
You said microservices are for when a microservice would have the support equivelant to a medium enterprise, this is not true even at netflix scale. They absolutely have services owned by very small teams, or else they wouldn't have more than 1000.
> When FAANG is your case study in any technical discussion in a public forum, you're default wrong.
Well who do we use as a case study on microservices then?
> Any useful technical discussion needs...
A technical discussion requires nuance, not turning into a black and white one side versus the other.
Yes, you can have multiple DBs in a monolith, but you tend not to. In microservices you are basically forced to.
It's a crude and expensive way to force modularisation. However, that is still what it often achieves, it gives you infra that you can keep other people away from and lets you be in charge.
But when your design relies on many services to provide a wide variety of features you need to break out this design to allow teams to operate independently.
Mini monoliths are more popular today than traditional monoliths of the old.
Not necessarily, because if you scale only one of your services all the other services do not benefit at all.
Having microservices would only be better in that instance if they actually consume the resources they are given.
It's important to keep in mind that this isn't a technical problem. It's an organisational problem. In fact, there is no technical reason why monoliths would be an anti-pattern, which is likely why they are still being taught as though they weren't at many universities where professors still naively think that the MBA's aren't going to cost-cut IT at every opportunity even though their entire organisation is made up of employees who spend 100% of their working time on IT devices of some form. Similarily, Microservices, aren't really the "technical" response to this. It's how IT and digitalisation had to evolve to keep up with business demands and better generate value. The simpler and more decoupled you keep things, the better you'll be able to respond to business needs. Sure, there are a gazillion different ways to do Microservices wrong, and if you do it wrong, then you'll likely be in the same mess that you would be with a monolith, only so much worse, because now you have 9 million tiny monoliths and shared databases.
Luckily we still live in a world where everyone is somehow still OK with IT not working. We went to an appointment that isn't relevant the other day, and they had a tablet where you could register your license plate to avoid getting a parking ticket. It didn't work, so we talked with the receptionist who was like "yeah, it does that all the time, don't worry, if the systems are down then they can't give out tickets"... Fine for us, but think about that... It turned out the system was down in my entire city, which means that all those hundreds of employees who are out handing out tickets had nothing to do while their IT system was being fixed, hell, the entire company wasn't generating income for my city while their IT was down, and this was a regular occurrence? What my point with this is, is that you can do things really wrong, and still be a "successful" company, it's just that the companies who manage to generate value better (which is frankly always microservices of some form) tend to simply do better. But like I said. You can do "microservices" in a million different ways. Running two different django backends to handle different parts of Instagram could be considered having two microservices after all. The importance is how you deal with the needs of your organisaiton in a rapid fashion.
But for anything where there's healthy competition, this completely changes. Errors, bugs, conceptual problems, etc absolutely will have an extremely negative impact.
As an example I once worked for a company selling tickets online, but there were numerous bugs, and the system would often crash under load. Long story short, we lost many users to competitors, that company is no longer independent, and all that code is now legacy.
Compare with the monopoly situation of Ticketmaster, they are far worse than this company ever was, and are quite successful, with a large user base. That hates them ;-)
Same thing happens in microservices too. You just need good planning an organizing.