One of them did a bunch of stuff that made use of AWS - but it didn't deliver any value to our customers, and probably made our product substantially worse. It cost $30k a day, and unquestionably was not worth the cost, and everyone on the team was fired after a few months.
A lot of companies are fine just using a handful of VPSes.
I think the biggest problem with starting on AWS is engineers are extremely susceptible to playing with new toys - for better or worse.
Engineers are going to try all AWSes new stuff, which is fine. The problem stems from engineers wanting to do stuff on the newest shiniest AWS toy whether that actually makes sense financially or much more importantly in terms of the product roadmap.
If design docs don't at least mention the cost - and your business cares about cost - then you should probably have a chat with the engineering dept.
At a prior FAANG job we included basic cost analysis in our decisions. You don't always need the cheaper option if it doesn't make sense, but you should probably know the traffic that shiny new toy will receive and the cost associated with it. (eg. soln A needs 25% more compute, and the internal price is X vs soln B needs 10% more compute, but will increase storage costs for caching at X per gb for ~Y gb).
I recall a case where a coworker (Senior SDE in Silicon Valley, so easily 25k a month salary) spent a month reducing our $500 SQS bill to $350 because our director wanted to see teams making smart financial optimizations. Meanwhile, our EC2 bill was $50k a month. Not everything is smart financially to focus on fixing. What is the compSci quote on premature optimization?
Of course, if you can't trust your developers to spend money wisely, you need guardrails on cost, no matter where you're spending it.
Sure - not everything at these companies needs to be on the cloud. But when you're dealing with sensitive information, you don't want people rolling their own infrastructure.
[0] https://press.aboutamazon.com/news-releases/news-release-det...
- https://www.youtube.com/watch?v=kzuCnivRoEw
Obviously there are always exceptions, but as a principle you could do a lot worse.
The main alternative is: host the hardware yourself, as it might be enough.
Cool. How many people here are also great sysadmins? Probably a very small number. That's not really an alternative. And furthermore, most of the counter point doesn't really exist.
They just mainly pointed out that "yeah, devops is hard, and lots of things are done by devops that seem simple but arent" but they didn't make an argument that aws is somehow an overnengineering thing that you can avoid if you would only do XYZ and remember that you probably have small scale.
I am. And there probably aren’t that many around here due to the extreme prejudice and derision Developers direct towards Sysadmins. We’re apparently a bunch of low-skill knuckle-dragging hardware monkeys, while at the same time able to do things so difficult that no developer can figure it out so they just go to the cloud instead “to avoid learning all that stuff”.
Very few non-cloud users actually host the hardware themselves. You can rent dedicated servers or even VMs just about anywhere. The hosting company manages and maintains the hardware as part of the monthly price.
I guess you could buy raspberry pi with more memory (but not more cores) and swap the sd card, but beyond that you are stuck. aarch64 rootfs will not boot on commodity x86 hardware. sd card performance and reliability is many times worse than EBS anyway.
Just FYI residential ISPs are absolutely terrible. Even my ISP, a FTTH one, has uptime lower than 99%. This is aside from layers of CGNAT and your own home equipment's SLA. If you're willing to run a product on this kind of RasPi infrastructure feel free, but don't claim there isn't any value in a datacenter.
It's easy to setup a home raspberry pi. It's easy to go one step up and setup a colocated raspberry pi. It's easy to setup a managed dedicated server. Auto scaling virtually provisioned hardware is great for a big company like Netflix with actual daily fluctuating demand. Most people don't need such advanced scaling features.
I previously had Sonic.net, which was one of the best fiber offerings for consumers available. 1 gbps up and down, unmetered, and was pretty much never down during the period I had it.
Realistic AWS non-cloud alternatives are either colo-ing in a DC, using another semi-cloud provider (OVH, Linode, Hetzner, et al.), or buying a DIA circuit for your office and running your own servers from there.
If we're talking about serverless then I think that containerization (either running containers on bare metal, or on kubernetes) changes the value prop of serverless a lot, because if you've got a container environment you can easily just clone an off-the-shelf production-ready container to deploy your app.
As far as your host OS goes get a production ready image to run your production ready container images. It's a one time thing. Keeping the OS updated? This is not brain surgery every time there is an update. Plus you can configure it to automatically install security updates.
You're stuck on this theme that AWS is somehow akin to scaling. That's one benefit of AWS but it's not the only one. At small scale the margins on AWS are peanuts. A t4g micro is $6.15 / mo. The equivalent on Digital Ocean is $5 / mo. Buying your own Raspberry Pi 4 would be ~ $70 with an enclosure/peripherals, so you'd break even at ... 14 months of running your t4g. This isn't counting the power used (which would probably be minimal on a Raspberry Pi.) That overhead is nothing.
> As far as your host OS goes get a production ready image to run your production ready container images. It's a one time thing. Keeping the OS updated? This is not brain surgery every time there is an update. Plus you can configure it to automatically install security updates.
There's more to it than that. You're just thinking about running software not how packets get from a user's machine to your running software. Most residential connections don't come with a stable/static IPv4. You can update a DNS entry with your changing IP, but then you're down for however long it takes you to change your A record and however long your domain's TTLs to expire. If you pay for a static IPv4 then you've already paid for more than what you're getting from a cloud VPS. Then there's the fact that residential ISPs block tons of ports, have no SLAs on uptime, can drop your traffic without warning or recourse, etc etc.
If you're running a tiny, mostly-static site with minimal uptime requirements then you'll pay less and spend much less effort using a shared webhosting platform. They'll do all the ops for you and you get charged peanuts since these providers usually colo their own machines and run hundreds of sites on them. Dreamhost can serve a Wordpress site for $1.99 / mo with no ops work required. That pays for 35 months of running a Raspberry Pi.
I'm not advocating for people hosting sites on a Raspberry pi in their homes, but it's certainly easy to do and if your operation is small enough and you have an extra computer lying around the cost is actually near $0.
Pretty much every ISP I've used in the US has had mostly static IPs. They usually didn't change unless the modem got rebooted. This is good enough for your minecraft server or unimportant personal website.
But of course if your residential internet is no longer serving your hosting needs, you can go a step up and get a virtual host or colocate your old computer! Yes colocation will cost a lot more than a virtual host on a PHP shared host, but you also get more computing bang for your buck.
Sysadmin-ing is not the boogeyman it once was!
They are valid concerns or at least warnings. You're obviously right that there's tradeoffs but the thing I'm sensing in our industry is that it's increasingly seen as just the default "thoughtless" infra model.
Are you sure it isn't relative to other solutions? I mean sure, you can learn it well enough that it's not complex for you anymore but there is still some objective measure of its complexity that relates to how difficult it was to learn.
Not to mention the lock in...
Like any choice in technology, there's always tradeoffs. One person/team's complex is another person/team's simple. Moreover there are circumstances that definitively tip the scale in one direction or the other. If egress bandwidth is important to your product, then you're better off going with an unmetered bandwidth solution. If you want to operate as lean as possible, you're better off in a colo. But discussing tradeoffs is a lot more complicated and less satisfying than saying "AWS bad" with a bit of corporate bashing so clickbait is what we get.