5 ms·

These kinds of articles seem to come up on tech aggregators every so often. Someone comes up with a bunch of theoretical benefits of not using AWS along with so

These kinds of articles seem to come up on tech aggregators every so often. Someone comes up with a bunch of theoretical benefits of not using AWS along with some hand-wringing about complexity (which is relative to the person but is invoked as objective fact). They then offer alternatives. But they never interview anyone who actually subscribes to these theoretical benefits and operates at any scale. There's never a discussion on the needs of the products in mind, it's always blanket dogma that can be applied in any situation. 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.

lopatin 5y ago
Reminds me of these YouTube videos filled with bad advice for newbies. For example, "Why I never code with ELSE statements, and YOU shouldn't either". It sounds profound to a newbie, but it's all just disingenuous dogmatic click bait.
- ehutch79 5y ago
  I know you're kidding, but there are legit videos saying you should never use If statements
  - lopatin 5y ago
    I wish I was kidding, but that sounds even worse! - https://www.youtube.com/watch?v=kzuCnivRoEw https://www.youtube.com/watch?v=kzuCnivRoEw - https://www.youtube.com/watch?v=_ougvb8mT7k https://www.youtube.com/watch?v=_ougvb8mT7k - https://www.youtube.com/watch?v=EumXak7TyQ0 https://www.youtube.com/watch?v=EumXak7TyQ0
    - deanCommie 5y ago
      Except...these are right. Minimizing nesting, and setting up validation failures as exit-early conditions from functions to have the main function body focused on the happy path are absolutely valid principles of clean code. Obviously there are always exceptions, but as a principle you could do a lot worse.
- LAC-Tech 5y ago
  FWIW I rarely use else statements and prefer early returns. Might be trauma from dealing with legacy code where you'd need an ultra wide monitor to get the end of the indentation.
bcrosby95 5y ago
It's simply a predictable swing of the pendulum. 5-10 years ago the same formula would play out except then, it was AWS solving all your problems, and how hardware is so hard because apparently you need to hire 3 full time employees because machines run on sysadmin tears rather than electricity so of course you need someone constantly lording over your 10 servers.
Justsignedup 5y ago
Just to add here, even aside from these trade-offs... 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.
- chrischen 5y ago
  A lot of small sites can probably do great without a sysadmin, nor AWS. If you think about it AWS can be a pre-mature optimization when just running your site off a Rapsberry Pi in your basement will do.
  - Karrot_Kream 5y ago
    Tradeoffs. If you can run your service on a residential internet SLA (or lack thereof) with residential CGNAT, and you have the ops chops to maintain Linux installs yourself, then do it. If you can run your business with a business-consumer SLA do it. AWS is much more reliable than that. 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.
    - chrischen 5y ago
      Well, you still have to patch and secure your OS on EC2. As far as EC2, AWS is really just taking over the hardware portion and making it somewhat easier to scale. But rapidly scaling is not something most apps do, even big ones. 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.
onlyrealcuzzo 5y ago
I worked at several startups before working at FAANG - none of them operated at any scale that they needed to be on AWS. None of them ever grew enough to need to be on AWS either. 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.
- Karrot_Kream 5y ago
  I worked at a startup that didn't use the cloud and was hemorrhaging money by only using a handful of compute in a DC despite renting a whole bunch of space/power. They could have moved to AWS and saved a ton on cost, but their CTO was comfortable with renting colo space and knew how to run a colo-based tech company. There's not much you can do when people make bad decisions. At most you can understand the tradeoffs of the decision space and do your best. There's rarely a silver bullet.
  - onlyrealcuzzo 5y ago
    There are options beside AWS and colo. 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.
    - Karrot_Kream 5y ago
      Yeah there's tons of options. There's the big clouds/cloud-native stuff. There's the cloud-VMs/VPSes. There's colos. There's making a DC at an office through DIA. Understanding these options is key to making a good, informed decision IMO.
    - vineyardmike 5y ago
      > 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?
bryanrasmussen 5y ago
>with some hand-wringing about complexity (which is relative to the person 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.
- Karrot_Kream 5y ago
  IMO a good example here is ops. I grew up in the era where net businesses started by renting colo space or getting a T1 line. When I learned about starting net projects, I learned how to set up all the things needed to get a project going in one of these settings. To me, running ops on a Linux or BSD box is simple; I've literally been doing it since I was a kid. These days it's a lot harder to find people with this expertise. To _me_, buying a DIA circuit and setting up a mini-DC for a business is simple. To most others who experienced Linux through Ubuntu or mostly grew up using MacOS, using cloud-VMs is probably a lot simpler.
nottorp 5y ago
To come from the other direction, not every app is or will ever need to be running at Google scale. Most of what AWS offers just triggers large enterprise warm fuzzy feelings. Even when they're totally not needed. Not to mention the lock in...
deleted 5y ago
[deleted]
fleddr 5y ago
Complex uncapped pricing is not a theoretical problem. Cloud lock-in is not a theoretical problem. Loss of control in case of downtime or a "ban" is not a theoretical problem. Cloud reducing complexity is questionable and may swing the other way. 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.

lopatin 5y ago

Reminds me of these YouTube videos filled with bad advice for newbies. For example, "Why I never code with ELSE statements, and YOU shouldn't either". It sounds profound to a newbie, but it's all just disingenuous dogmatic click bait.

ehutch79 5y ago
I know you're kidding, but there are legit videos saying you should never use If statements
- lopatin 5y ago
  I wish I was kidding, but that sounds even worse! - https://www.youtube.com/watch?v=kzuCnivRoEw https://www.youtube.com/watch?v=kzuCnivRoEw - https://www.youtube.com/watch?v=_ougvb8mT7k https://www.youtube.com/watch?v=_ougvb8mT7k - https://www.youtube.com/watch?v=EumXak7TyQ0 https://www.youtube.com/watch?v=EumXak7TyQ0
  - deanCommie 5y ago
    Except...these are right. Minimizing nesting, and setting up validation failures as exit-early conditions from functions to have the main function body focused on the happy path are absolutely valid principles of clean code. Obviously there are always exceptions, but as a principle you could do a lot worse.
LAC-Tech 5y ago
FWIW I rarely use else statements and prefer early returns. Might be trauma from dealing with legacy code where you'd need an ultra wide monitor to get the end of the indentation.

bcrosby95 5y ago

It's simply a predictable swing of the pendulum. 5-10 years ago the same formula would play out except then, it was AWS solving all your problems, and how hardware is so hard because apparently you need to hire 3 full time employees because machines run on sysadmin tears rather than electricity so of course you need someone constantly lording over your 10 servers.

Justsignedup 5y ago

Just to add here, even aside from these trade-offs... 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.

chrischen 5y ago
A lot of small sites can probably do great without a sysadmin, nor AWS. If you think about it AWS can be a pre-mature optimization when just running your site off a Rapsberry Pi in your basement will do.
- Karrot_Kream 5y ago
  Tradeoffs. If you can run your service on a residential internet SLA (or lack thereof) with residential CGNAT, and you have the ops chops to maintain Linux installs yourself, then do it. If you can run your business with a business-consumer SLA do it. AWS is much more reliable than that. 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.
  - chrischen 5y ago
    Well, you still have to patch and secure your OS on EC2. As far as EC2, AWS is really just taking over the hardware portion and making it somewhat easier to scale. But rapidly scaling is not something most apps do, even big ones. 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.

onlyrealcuzzo 5y ago

I worked at several startups before working at FAANG - none of them operated at any scale that they needed to be on AWS. None of them ever grew enough to need to be on AWS either. 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.

Karrot_Kream 5y ago
I worked at a startup that didn't use the cloud and was hemorrhaging money by only using a handful of compute in a DC despite renting a whole bunch of space/power. They could have moved to AWS and saved a ton on cost, but their CTO was comfortable with renting colo space and knew how to run a colo-based tech company. There's not much you can do when people make bad decisions. At most you can understand the tradeoffs of the decision space and do your best. There's rarely a silver bullet.
- onlyrealcuzzo 5y ago
  There are options beside AWS and colo. 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.
  - Karrot_Kream 5y ago
    Yeah there's tons of options. There's the big clouds/cloud-native stuff. There's the cloud-VMs/VPSes. There's colos. There's making a DC at an office through DIA. Understanding these options is key to making a good, informed decision IMO.
  - vineyardmike 5y ago
    > 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?

bryanrasmussen 5y ago

>with some hand-wringing about complexity (which is relative to the person 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.

Karrot_Kream 5y ago
IMO a good example here is ops. I grew up in the era where net businesses started by renting colo space or getting a T1 line. When I learned about starting net projects, I learned how to set up all the things needed to get a project going in one of these settings. To me, running ops on a Linux or BSD box is simple; I've literally been doing it since I was a kid. These days it's a lot harder to find people with this expertise. To _me_, buying a DIA circuit and setting up a mini-DC for a business is simple. To most others who experienced Linux through Ubuntu or mostly grew up using MacOS, using cloud-VMs is probably a lot simpler.

nottorp 5y ago

To come from the other direction, not every app is or will ever need to be running at Google scale. Most of what AWS offers just triggers large enterprise warm fuzzy feelings. Even when they're totally not needed. Not to mention the lock in...

deleted 5y ago

[deleted]

fleddr 5y ago

Complex uncapped pricing is not a theoretical problem. Cloud lock-in is not a theoretical problem. Loss of control in case of downtime or a "ban" is not a theoretical problem. Cloud reducing complexity is questionable and may swing the other way. 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.