4 ms·

The thing is, he's comparing virtual machines at all of these providers. If you want to use managed services (Fargate, Aurora, DynamoDB, etc) at AWS, it's even

The thing is, he's comparing virtual machines at all of these providers. If you want to use managed services (Fargate, Aurora, DynamoDB, etc) at AWS, it's even more expensive! So if you just use EC2 then alternatives are cheaper, and if you use managed services it becomes so expensive so can actually afford hiring people to take care of your virtual machines.

weberc2 7y ago
If you account for engineering effort, Fargate is cheaper than EC2. No central logging or log exfiltration to configure, no bin packing apps onto AMIs, no SSH to set up or keys to manage, no configuration management, no process management to worry about, etc. Just put your app into an image and write the CF templates for your cluster, services, and task definition and you’re good to go.
scarface74 7y ago
Are you including HA and maintenance? A typical network engineer where we live has a fully allocated cost of around $170K. That can pay for a lot of stuff on AWS. And we can actually move faster without the netops bottle neck.
- emn13 7y ago
  Oh boy, that canard. In my experience, cloud management is nothing like as simple as people make out; and you're not going to be magically making those ifrastructure man-power costs just go away. You need to configure all that stuff non-the-less, and that's where the time goes. Even compared to bare-metal, the difference isn't all it's chalked up to be - the actual rusty box doesn't need a lot of TLC, and you can hire companies for that too, and they just don't break all that often for this to matter much. I mean; who wants the hassle; and it's still sane to outsource stuff you're not good at and don't (want to) care about - but it's not a huge source of savings. And HA is - for most usages - best avoided. It's a complexity source like nothing you've seen before. Better to make sure you can replace anything that's broken really fast (because it's all scripted), and if you have enough scale to have at least few machines - just accept that you'll have some very small downtime when lightning strikes, and that many machines can be temporarily missed without much impact anyhow. By the way - you'll have that in HA cloud datacenters too, but the cause there will be human error due to the excessive complexity. If you dive into uptime claims by cloud providers it's typically for obtuse stuff like "can bare VM ping another VM over http in same datacenter". Actually use any of all of those complex services they provide, and weird stuff like "the outside internet connectivity" and the uptime of the overall system starts shedding those precious 9's. Uptime is almost certainly excellent compared to any trivial alternative, but the real-world difference isn't as large as the misleading uptime claims lead you to believe. I've had outages cloud providers several times while their uptime ticker claimed everything was just peachy. If you really need HA, my condolences - but it's overrated vs. simply being able to spin up a new copy in a few minutes, especially since stuff just doesn't die or crash all that often; typically only once every few years, if that. Almost all actual downtime is not because your physical infrastructure went down in ways that most HA could have prevented.
  - scarface74 7y ago
    * In my experience, cloud management is nothing like as simple as people make out; and you're not going to be magically making those ifrastructure man-power costs just go away. You need to configure all that stuff non-the-less, and that's where the time goes.* I wrote CloudFormation scripts that handle our basic use cases and use parameters. Any developer can click on quick create link for instance and have an isolated build environment just for there service. If they need something above and beyond the standard CodeBuild Docker container for their build environment they can create their own. And we have made the infrastructure manpower diminish to an extent that it might as well be gone. * Even compared to bare-metal, the difference isn't all it's chalked up to be - the actual rusty box doesn't need a lot of TLC, and you can hire companies for that too,* Can I hire a company to put in 20 additional servers every night when our processing queue increases and take them out when it decreases? And HA is - for most usages - best avoided. It's a complexity source like nothing you've seen before It’s “complex” to have an autoscaling group with a min/max of two and clicking on a button (well actually use a CF script) when you want to increase the number of servers? There is nothing “complex” about having HA in a cloud environment. Better to make sure you can replace anything that's broken really fast (because it's all scripted), It’s even faster when you don’t have to do it yourself.. * Almost all actual downtime is not because your physical infrastructure went down in ways that most HA could have prevented.* HA can be as simple as a rogue query killed an app/web server (been there done that). I got an alert that the web server was unhealthy. By the time I woke up well, I got another alert saying that a new instance was brought up. I went back to sleep and investigated in the morning. Not to mention the automatic updates performed on RDS instances or the updates that you don’t have to care about with managed services.
    - emn13 7y ago
      > > In my experience, cloud management is nothing like as simple as people make out; and you're not going to be magically making those ifrastructure man-power costs just go away. You need to configure all that stuff non-the-less, and that's where the time goes.* > I wrote CloudFormation scripts that handle our basic use cases and use parameters. scripts will run on things other than the cloud. The thing that made that difference? It may have been you, not the cloud. > > Even compared to bare-metal, the difference isn't all it's chalked up to be - the actual rusty box doesn't need a lot of TLC, and you can hire companies for that too,* > Can I hire a company to put in 20 additional servers every night when our processing queue increases and take them out when it decreases? Nope; you can't - and that's a real upside to a cloud. I'm not opposed to using the cloud; merely saying that personnel costs savings are nonsense, however. In any case; you cannot easily do this with physical hosts. Then again; most people probably don't need to. If your workload is merely a little spiky (like day vs. night) then the extra costs due to the cloud will be greater even if you spin down instances sometimes; and if you do that, you're spending time to do so, which undercuts the clouds other selling point "I don't want to manager all that junk". On HA: You're listing scaling, not HA. You don't need to do anything special to make interchangable, largely stateless machines "HA" no matter your infrastructure. HA is relevant if you have any single points of failure, and how you avoid the consequences of having those; e.g. having a live database replica or whatever. But sure: this 'll be easier on some clouds! > > Almost all actual downtime is not because your physical infrastructure went down in ways that most HA could have prevented. > HA can be as simple as a rogue query killed an app/web server (been there done that). I got an alert that the web server was unhealthy. By the time I woke up well, I got another alert saying that a new instance was brought up. I went back to sleep and investigated in the morning. Not to mention the automatic updates performed on RDS instances or the updates that you don’t have to care about with managed services. So... why does any of that need the cloud? Sounds like a plain old process or container needed restarting. That's just basic server stuff servers have been doing for... well, longer than the cloud even existed. But the point isn't that the cloud is a bad idea. It's that people ascribe frankly absurd benefits to it, when many of those are either unrelated to being in a cloud, and some are wildly overstated, specifically the management costs. Not that there aren't upsides: but if you're saving 170k on network engineering personnel costs; well, you didn't need the cloud to do that unless you're really, really huge, to the point that other costs are dominating anyhow.
dgemm 7y ago
> If you want to use managed services (Fargate, Aurora, DynamoDB, etc) at AWS, it's even more expensive! More expensive than what? Running similar services yourself?

weberc2 7y ago

If you account for engineering effort, Fargate is cheaper than EC2. No central logging or log exfiltration to configure, no bin packing apps onto AMIs, no SSH to set up or keys to manage, no configuration management, no process management to worry about, etc. Just put your app into an image and write the CF templates for your cluster, services, and task definition and you’re good to go.

scarface74 7y ago

Are you including HA and maintenance? A typical network engineer where we live has a fully allocated cost of around $170K. That can pay for a lot of stuff on AWS. And we can actually move faster without the netops bottle neck.

emn13 7y ago
Oh boy, that canard. In my experience, cloud management is nothing like as simple as people make out; and you're not going to be magically making those ifrastructure man-power costs just go away. You need to configure all that stuff non-the-less, and that's where the time goes. Even compared to bare-metal, the difference isn't all it's chalked up to be - the actual rusty box doesn't need a lot of TLC, and you can hire companies for that too, and they just don't break all that often for this to matter much. I mean; who wants the hassle; and it's still sane to outsource stuff you're not good at and don't (want to) care about - but it's not a huge source of savings. And HA is - for most usages - best avoided. It's a complexity source like nothing you've seen before. Better to make sure you can replace anything that's broken really fast (because it's all scripted), and if you have enough scale to have at least few machines - just accept that you'll have some very small downtime when lightning strikes, and that many machines can be temporarily missed without much impact anyhow. By the way - you'll have that in HA cloud datacenters too, but the cause there will be human error due to the excessive complexity. If you dive into uptime claims by cloud providers it's typically for obtuse stuff like "can bare VM ping another VM over http in same datacenter". Actually use any of all of those complex services they provide, and weird stuff like "the outside internet connectivity" and the uptime of the overall system starts shedding those precious 9's. Uptime is almost certainly excellent compared to any trivial alternative, but the real-world difference isn't as large as the misleading uptime claims lead you to believe. I've had outages cloud providers several times while their uptime ticker claimed everything was just peachy. If you really need HA, my condolences - but it's overrated vs. simply being able to spin up a new copy in a few minutes, especially since stuff just doesn't die or crash all that often; typically only once every few years, if that. Almost all actual downtime is not because your physical infrastructure went down in ways that most HA could have prevented.
- scarface74 7y ago
  * In my experience, cloud management is nothing like as simple as people make out; and you're not going to be magically making those ifrastructure man-power costs just go away. You need to configure all that stuff non-the-less, and that's where the time goes.* I wrote CloudFormation scripts that handle our basic use cases and use parameters. Any developer can click on quick create link for instance and have an isolated build environment just for there service. If they need something above and beyond the standard CodeBuild Docker container for their build environment they can create their own. And we have made the infrastructure manpower diminish to an extent that it might as well be gone. * Even compared to bare-metal, the difference isn't all it's chalked up to be - the actual rusty box doesn't need a lot of TLC, and you can hire companies for that too,* Can I hire a company to put in 20 additional servers every night when our processing queue increases and take them out when it decreases? And HA is - for most usages - best avoided. It's a complexity source like nothing you've seen before It’s “complex” to have an autoscaling group with a min/max of two and clicking on a button (well actually use a CF script) when you want to increase the number of servers? There is nothing “complex” about having HA in a cloud environment. Better to make sure you can replace anything that's broken really fast (because it's all scripted), It’s even faster when you don’t have to do it yourself.. * Almost all actual downtime is not because your physical infrastructure went down in ways that most HA could have prevented.* HA can be as simple as a rogue query killed an app/web server (been there done that). I got an alert that the web server was unhealthy. By the time I woke up well, I got another alert saying that a new instance was brought up. I went back to sleep and investigated in the morning. Not to mention the automatic updates performed on RDS instances or the updates that you don’t have to care about with managed services.
  - emn13 7y ago
    > > In my experience, cloud management is nothing like as simple as people make out; and you're not going to be magically making those ifrastructure man-power costs just go away. You need to configure all that stuff non-the-less, and that's where the time goes.* > I wrote CloudFormation scripts that handle our basic use cases and use parameters. scripts will run on things other than the cloud. The thing that made that difference? It may have been you, not the cloud. > > Even compared to bare-metal, the difference isn't all it's chalked up to be - the actual rusty box doesn't need a lot of TLC, and you can hire companies for that too,* > Can I hire a company to put in 20 additional servers every night when our processing queue increases and take them out when it decreases? Nope; you can't - and that's a real upside to a cloud. I'm not opposed to using the cloud; merely saying that personnel costs savings are nonsense, however. In any case; you cannot easily do this with physical hosts. Then again; most people probably don't need to. If your workload is merely a little spiky (like day vs. night) then the extra costs due to the cloud will be greater even if you spin down instances sometimes; and if you do that, you're spending time to do so, which undercuts the clouds other selling point "I don't want to manager all that junk". On HA: You're listing scaling, not HA. You don't need to do anything special to make interchangable, largely stateless machines "HA" no matter your infrastructure. HA is relevant if you have any single points of failure, and how you avoid the consequences of having those; e.g. having a live database replica or whatever. But sure: this 'll be easier on some clouds! > > Almost all actual downtime is not because your physical infrastructure went down in ways that most HA could have prevented. > HA can be as simple as a rogue query killed an app/web server (been there done that). I got an alert that the web server was unhealthy. By the time I woke up well, I got another alert saying that a new instance was brought up. I went back to sleep and investigated in the morning. Not to mention the automatic updates performed on RDS instances or the updates that you don’t have to care about with managed services. So... why does any of that need the cloud? Sounds like a plain old process or container needed restarting. That's just basic server stuff servers have been doing for... well, longer than the cloud even existed. But the point isn't that the cloud is a bad idea. It's that people ascribe frankly absurd benefits to it, when many of those are either unrelated to being in a cloud, and some are wildly overstated, specifically the management costs. Not that there aren't upsides: but if you're saving 170k on network engineering personnel costs; well, you didn't need the cloud to do that unless you're really, really huge, to the point that other costs are dominating anyhow.

dgemm 7y ago

> If you want to use managed services (Fargate, Aurora, DynamoDB, etc) at AWS, it's even more expensive! More expensive than what? Running similar services yourself?