>Monolyth retards think that microservices and the basics of cloud computing are a scam.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.
My server has a better uptime than either Google or Cloudflare.
>>106510030They 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.
>>106510130you can have multiple replicas of your monolith runningthere 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
>>106510130your 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.
>>106510130Microservice niggers think monolith means a single server running in your basement.
>>106510130The "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.
>>106510126My server's kernel can be patched without reboot (e years uptime)
>>106510030What 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.>>106510130Samefag.
>>106510030You 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 contractsretards? they pay 4x the price. you better follow through.
>>106510030>tfw my shit PHP+Node single server service only has 99.99% uptimefeels bad man
>>106510030>decoupledbad for latency, more complexity, API-change coordination dev overhead, adds networking as additional points of failure>redundantmonolith 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>microservicesThere'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 contractsUnless 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.
>>106511870Exactly. 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).
>>106510130is this ai generated?
