> So what's the point of all that? Seriously, one server with 16 cores and the memory bandwidth and storage speed of SSD drives should be able to serve many thousands of simultaneous requests and millions of users per month. I can't help but feel that the cloud infrastructure and microservice movement of the 2010s was.. a scam.
You're just missing the whole point of why you need n>1 instances. You're focusing on what might be the least compelling reason for the majority of applications, which is scalability.
Reliability and fault tolerance is a major selling point, and you can't simply expect to have adequate performance in more than one region if you're providing your services out of a single box in a single data center. The laws of physics ensure your quality of service will suck.
Operations also compell you to have multiple instances, ranging from blue/green deployments to one-box deployment strategies. And are you going to allow your business to be down for significant amounts of time whenever you need to update your OS? How would you explain all that downtime to your boss/shareholders? Are the tens of dollars you save on infrastructure a good tradeoff?
Also, security is also a concern. You're better off isolating your backend from frontend services, and software-defined networks aren't a silver bullet.
And in the end, are the tradeoffs of not designing your web services the right way really worth it?
Agreed entirely for most. I have seen so many insanely complicated and eye wateringly expensive architectures for what are simple web apps on the big clouds. Often the team don't really understand the intricacies of all these services and how they interrelate which causes often cause a lot of stability problems.
Even if they don't, there is usually a huge tax on developer productivity with these architectures, which often outweighs any improved stability over the long term.
Let's keep in mind that modern hardware and software is very stable, generally.
Agreed - I worked for a company with 30 people dedicated entirely to managing the mess they'd created in AWS - and their AWS account manager somehow managed to keep convincing them to use more and newer AWS services to dig them in even further.
People talk about resume-driven development, which is definitely a factor, but there's also fear-driven development - you have a hunch the architecture could be a lot simpler and cheaper, but you don't want to make any criticism in case the others in your team think you are technically ignorant, inexperienced, out of touch etc.
>Let's keep in mind that modern hardware and software is very stable, generally
Not at any significant scale. dimm will fail, power will be down, disks will need replacement.
It is all about risks after all. If you are ok to have couple of hours of downtime if one of the memory sticks stops working - good for you. But generally any large enough business won't tolerate such risks.
I'm not saying that the cloud is the answer, but I don't see any future for single instance solution. And if you design your system like this, you are taking much more risks than necessary.
It's less insidious than that. Engineers like using AWS at startups because it benefits their future careers at larger companies. Startups also get $100k-$500k in free AWS credits. So there's no short term downside.
Ultimately it's the CTO/Technical Founders fault that this goes on. Avoid cloud services like the plague unless you really actually need them. They will slow you down and eat your wallet in the long run.
You're just missing the whole point of why you need n>1 instances. You're focusing on what might be the least compelling reason for the majority of applications, which is scalability.
Reliability and fault tolerance is a major selling point, and you can't simply expect to have adequate performance in more than one region if you're providing your services out of a single box in a single data center. The laws of physics ensure your quality of service will suck.
Operations also compell you to have multiple instances, ranging from blue/green deployments to one-box deployment strategies. And are you going to allow your business to be down for significant amounts of time whenever you need to update your OS? How would you explain all that downtime to your boss/shareholders? Are the tens of dollars you save on infrastructure a good tradeoff?
Also, security is also a concern. You're better off isolating your backend from frontend services, and software-defined networks aren't a silver bullet.
And in the end, are the tradeoffs of not designing your web services the right way really worth it?