My server has a better uptime than either Google or Cloudflare.

>>106510030
They cry “scam” because they’ve never run real infra. Monolith dies once, you’re screwed. Microservices keep chugging, you swap the dead part out. 99.999% uptime doesn’t happen with a single fat binary.

>>106510130
you can have multiple replicas of your monolith running

there are tons of examples of microservices going completely down because there are still a few critical services which can be taken down by a bad update

>>106510130
your discord bot on Kubernets isn't "real infra"

pro tip:
The big corpos, with their distributed servers, themselves do not run on microservices.
You fell for a scam.

>>106510130
Microservice niggers think monolith means a single server running in your basement.

>>106510130
The "monolith" is still behind a webserver like nginx and still talks to a database.
So in a modern SPA, where javascript renders everything and the server only provides APIs, it doesn't have to do anything else than taking a request, querying a database, and respond.

What benefit does a microservice provide? Except that it becomes far more expensive when you have a high amount of users.

Microservices are unironically only useful if you can leech off a free tier. So they are the exact opposite of what you claim: They are for shitty hobby projects, while everything that becomes large has to fuck off as soon as possible.

>>106510126
My server's kernel can be patched without reboot (e years uptime)

>>106510030
What does monolith vs microservices have to do with uptime and redundancy? You sound like an absolute retard who fell for a meme and thinks that a monolithic codebase has to run on a single server.

>>106510130
Samefag.

>>106510030
You seem very confused about the purpose of microservice architectures. Microservices aren't a redundancy technique - you can just run several copies of a monolith and in fact, that's what some of the most redundant systems on Earth do. Microservices aren't a technique to make code more understandable - they actually make the system way harder to understand. Microservices also aren't a performance technique - adding network hops to an operation won't magically make it faster.
In reality, microservices are an organizational technique and nothing more. You take on extra technical complexity in the hopes that it will be outweighed by gains at the people management layer. Everything else is just midwits cargo culting large companies like Google.

>>106510030
>litigious retards that sign the 99.999% uptime contracts
retards? they pay 4x the price. you better follow through.

>>106510030
>tfw my shit PHP+Node single server service only has 99.99% uptime
feels bad man

>>106510030
>decoupled
bad for latency, more complexity, API-change coordination dev overhead, adds networking as additional points of failure

>redundant
monolith refers to code, you can still instantiate it N times, at least as long as it doesn't rely on critical in-memory state that somehow can't be replicated.

>monolith
>microservices
There's a middleground. just services. Split just those things that must be split. orchestrator + leaf services if you need to scale to many machines. perhaps backend + database if you sqlite isn't good enough. Having a separate watchdog running is fine too.

You don't need to on-demand-start leftpad it in its own serverless function.

>That's like begging to be sued by one of those litigious retards that sign the 99.999% uptime contracts
Unless you're operating critical infrastructure, medical devices or stuff like that customers rarely really care about the uptime. They SAY they want all the nines, but when you show them the pricetag then suddenly they'll tolerate a day or two of downtime over the year.

>>106511870
Exactly. The optimal choice for the vast majority of businesses (not FAANG-scale) is the "boring technology" stack: nginx reverse proxy -> monolith in a popular backend language -> Postgres. If you want more performance and redundancy, you replicate Postgres, stand up several copies of the monolith, and use nginx as a load balancer. You stand up extra services when you really need to use a different technology (maybe your backend is in Java but you have a problem for which the library ecosystem is far better in Python or C++) or when you need a completely independent service (maybe it's an internal system for HR).

>>106510130
is this ai generated?

>>106510030
Microservices are the DLL Hell of web shit.

https://www.youtube.com/watch?v=y8OnoxKotPQ

>>106510030
Extremely high uptime systems usually aren't microservice-based. They are Erlang monoliths. It's all about making the error kernel as small as possible and not about following the latest architectural fads.

File: Preacher.png (55 KB, 268x377)

55 KB PNG

>>106510030
We thank you, oh Monolith, for revealing the cunning plans of your enemies to us.
May your light shine down on the souls of the brave soldiers who gave their lives in service to your will.
Onward warriors of the Monolith, avenge your fallen brothers, blessed as they are in their eternal union with the Monolith.
Bring death to those who spurned the holy power of the Monolith.

>>106510275
Because when you run real software you want to scale it up and down based on demand. The microservices allow you to scale only the parts of the application that need scaling, as opposed to the whole monolith stack. It reduces redundancy.
Also >>106511347 is right. In reality it's mostly for encapsulating and isolating the application.

>>106511870
>monolith refers to code
Wrong. That's monorepo.

>There's a middleground. just services. Split just those things that must be split. orchestrator + leaf services if you need to scale to many machines. perhaps backend + database if you sqlite isn't good enough. Having a separate watchdog running is fine too
You just described microservices you dummy. You just used a different word for the same thing.
Also no real company uses sqlite. The DB itself is another microservice you can scale.

I feel this whinge was posted because Orange Reddit has had a large number of stories and posts lately regarding de-clouding and moving back on-prem. Everything is much faster, we're talking tens to thousands of times faster than serverless. Storage can be duplicated and sent to a failover server, just in case of an outage or failure. And it's dirt fucking cheap compared to cloud.

Why don't you surf on over to that site, OP, and read why people are starting to look at serverless cloud-native garbage as wasteful. There are shit loads of posts about it now. We could explain it to you but I'd rather have you see that your whinge-posting isn't going to catch and flies here and you certainly know you're not catching them elsewhere. Nice try tho.

>>106516768
>Wrong. That's monorepo.
I hope you're trolling and not legitimately retarded

What causes the phenomenon of kids who clearly aren't programmers and don't even understand the question coming to forums and arguing about software architecture like it's some kind of brand war? It's like the drunks from my street suddenly had strong opinions about elliptic curve versus lattice based encryption.

Shitty CIOs pushed things to the cloud because it changes the conversation from
>why is your shit down
to
>oh no Google is down can't be helped
The better CIOs didn't really do this and they only leveraged clould where it was actually the best and most cost effective solution to a problem.
Also don't forget the predatory pricing of the cloud providers back in the early years. They were selling this as a loss leader, burning money, knowing that once you collapsed your racks and paid them for 5 years you were up shit creek and they were free to renegotiate with you for big money. What are you going to do, spend 5 years of capex in 1? Good luck getting the board to sign off on that one.

>>106517254
Partly this, partly because they wanted to kill off the Unix greybeard sysadmin types. Last thing a company wants is a highly specialized couple of tech nerds who can't just be fired and replaced on a whim.

>>106510030
>Why would you hate having a decoupled and redundant infrastructure
it's a nightmare to develop, test and (especially) debug.

File: microservices.png (69 KB, 986x585)

69 KB PNG

>>106510030
ask amazon.

>>106510030
>Why would you hate having a decoupled and redundant infrastructure. That's like begging to be sued by one of those litigious retards that sign the 99.999% uptime contracts.

If you had real, real experience with a 24x365 system that needed to have at least 99.99% WITH kubernetes and microservices, you'd understand you're full of shit, a fewer amount of services or just a handful of monoliths makes high availability easier.

You clearly lack experience on real life stuff.

>>106510130
>Monolith dies once, you’re screwed.

lol who would run a single instance of a monolith?

don't be a tard

>>106510175
>your discord bot on Kubernets isn't "real infra"

based

>>106510207
>pro tip:
>The big corpos, with their distributed servers, themselves do not run on microservices.
>You fell for a scam.

based

>>106511200
>You sound like an absolute retard who fell for a meme and thinks that a monolithic codebase has to run on a single server.

based

>>106511347
>Microservices aren't a technique to make code more understandable - they actually make the system way harder to understand.

very based

>>106515110
>Extremely high uptime systems usually aren't microservice-based. They are Erlang monoliths. It's all about making the error kernel as small as possible and not about following the latest architectural fads.

extremely based chad

>>106510126
and torrents have better uptime than both.

>>106516991
Declouding was always inevitable.
There are immutable reasons why the mainframe industry died.

>>106510030
>adding network latency and request validation overhead to basically every function call
Decoupling and redundancy are nice, but what's also nice is performance and not wasting money on unnecessary compute. Plus microservices are basically a scheme to nickel and dime you, like videogame dlc.

I'd like to see some examples of similar applications that are implemented with both a microservice architecture and a monolithic architecture and see how they compare.

>>106516696
What is """ real""" software?
Google isn't running on microservices, Facebook isn't doing it either. So what is this "real" you are talking about?
Is "real" whatever some scammer told you? And if you don't do the same, you are not "real"?

Scaling has nothing to do with microservices. You can scale your mysql, postgres, redis or even mongodb if you feel like it. There is no problem here.
Why would you outsource this to a database-as-a-service provider who rapes your asshole? It doesn't make it any easier.

>>106517254
This.
It is shifting responsibility and badly run companies love to outsource responsibility.

I personally experienced that microservices have much higher downtime.

>>106510030
>Monolyth
ESL moment

>>106510030
Bro I love paying a bunch of money and doing five times the work to get my built-in-public SaaS SPA off the ground. Yeah I only have five users and a $10/mo VPS could've run my entire project if I made it a monolith but like lmao who codes monoliths now???

microservices make network bandwidth your bottleneck
monoliths are bottlenecked at RAM, which is way faster