4 ms·

First of all, should be (2023). Second, he starts with sudo. Where's that command line coming from? Who installed the OS? Who maintains it? What about availabi

First of all, should be (2023). Second, he starts with sudo. Where's that command line coming from? Who installed the OS? Who maintains it? What about availability zones and fast failover? You can do self hosting if you want, but it's not as easy or as cheap as he's making it out to be. Cloud is still better for early stage startups, that's why everyone's using it.

codegeek 2y ago
You are missing the point. You may not need multiple availability zones when you are starting out and majority of cases never reach that point anyway. We are over optimizing too much because of "cloud" and dumbing us down further.
deleted 2y ago
[deleted]
giantrobot 2y ago
> Second, he starts with sudo. Where's that command line coming from? Who installed the OS? Who maintains it? What about availability zones and fast failover? I've noticed most of these anti-cloud articles omit this exact point consistently. So we'll replace "the cloud" with docker compose! Because apparently docker compose just spins up resources ex nihilo. There's also often the contrived assumption that "the cloud" means a bunch of huge bills because you automatically launch every service available and run them constantly. Also you run the largest instances because reasons.
- snoman 2y ago
  When people provision resources in the cloud in the same way they provision resources on-premises, they tend to massively over-provision.
goostavos 2y ago
>What about availability zones and fast failover You're making OP's main point. He's arguing that (to use his numbers) 90-95% of startups don't actually need to worry about that. Hell, I would argue that a lot of services at established companies don't actually need to worry about it (and the ones that do, need to worry about it a lot). Tons of stuff inside of $megacorps is running on crummy "non-scalable" architectures because somebody sat down and did the "engineering" part of "software engineering" and went "y'know, I think all we're really ever need is..." >Cloud is still better for early stage startups My preference is cloud these days (especially if I'm just quick and dirty clicking buttons in console rather than CDK-ing things together). However, there are still lots of cases where sinning up a $10 droplet and running `docker compose` completely satisfies "the architecture" part of the business.
- mjr00 2y ago
  > Hell, I would argue that a lot of services at established companies don't actually need to worry about it (and the ones that do, need to worry about it a lot). Tons of stuff inside of $megacorps is running on crummy "non-scalable" architectures because somebody sat down and did the "engineering" part of "software engineering" and went "y'know, I think all we're really ever need is..." Yeah, those system architectures are the ones that end up in all the other rants, the ones about how companies never prioritize fixing technical debt and legacy code :)
  - deleted 2y ago
    [deleted]
- erik_seaberg 2y ago
  Downtime for your own staff is a quantifiable cost you can expect them to put up with. It's outside customers whose trust will be hard to restore.
- underdeserver 2y ago
  I'm not sure how bad it is if you're the one product that's down for 12 hours out of your competitive field. Maybe you're right and it's small. But even if you neglect these issues you still need to manage your own machines, which is more time consuming than spinning up a new VM with preinstalled OS in EC2.

codegeek 2y ago

You are missing the point. You may not need multiple availability zones when you are starting out and majority of cases never reach that point anyway. We are over optimizing too much because of "cloud" and dumbing us down further.

deleted 2y ago

[deleted]

giantrobot 2y ago

> Second, he starts with sudo. Where's that command line coming from? Who installed the OS? Who maintains it? What about availability zones and fast failover? I've noticed most of these anti-cloud articles omit this exact point consistently. So we'll replace "the cloud" with docker compose! Because apparently docker compose just spins up resources ex nihilo. There's also often the contrived assumption that "the cloud" means a bunch of huge bills because you automatically launch every service available and run them constantly. Also you run the largest instances because reasons.

snoman 2y ago
When people provision resources in the cloud in the same way they provision resources on-premises, they tend to massively over-provision.

goostavos 2y ago

>What about availability zones and fast failover You're making OP's main point. He's arguing that (to use his numbers) 90-95% of startups don't actually need to worry about that. Hell, I would argue that a lot of services at established companies don't actually need to worry about it (and the ones that do, need to worry about it a lot). Tons of stuff inside of $megacorps is running on crummy "non-scalable" architectures because somebody sat down and did the "engineering" part of "software engineering" and went "y'know, I think all we're really ever need is..." >Cloud is still better for early stage startups My preference is cloud these days (especially if I'm just quick and dirty clicking buttons in console rather than CDK-ing things together). However, there are still lots of cases where sinning up a $10 droplet and running `docker compose` completely satisfies "the architecture" part of the business.

mjr00 2y ago
> Hell, I would argue that a lot of services at established companies don't actually need to worry about it (and the ones that do, need to worry about it a lot). Tons of stuff inside of $megacorps is running on crummy "non-scalable" architectures because somebody sat down and did the "engineering" part of "software engineering" and went "y'know, I think all we're really ever need is..." Yeah, those system architectures are the ones that end up in all the other rants, the ones about how companies never prioritize fixing technical debt and legacy code :)
- deleted 2y ago
  [deleted]
erik_seaberg 2y ago
Downtime for your own staff is a quantifiable cost you can expect them to put up with. It's outside customers whose trust will be hard to restore.
underdeserver 2y ago
I'm not sure how bad it is if you're the one product that's down for 12 hours out of your competitive field. Maybe you're right and it's small. But even if you neglect these issues you still need to manage your own machines, which is more time consuming than spinning up a new VM with preinstalled OS in EC2.