6 ms·

This. If you can predict your workload with some accuracy, and have someone who knows how to design systems- you can save a lot of money. AWS' value is that "we

by lykr0n 8y ago

This. If you can predict your workload with some accuracy, and have someone who knows how to design systems- you can save a lot of money. AWS' value is that "we can do everything except write your code for you" which you end up paying a lot for.

chomp 8y ago
Even if you can't predict the workload too well, you can go hybrid cloud - colo for the baseline and then AWS for the unpredictable stuff. ManageIQ is great for this.
ekovarski 8y ago
... isn't that the hardest part, predicting workload, for many companies. Scaling up within a colo can be troublesome due to procuring hw, having remote hands rack it, setup, etc. If you can predict workload then you could also reduce your cloud bills, in theory, by moving spinning up/down instances. Many are going the cloud route because the cost of entry is much easier to start developing but eventually, yes, the cost skyrockets and you do end up paying for putting little forethought into the real workload requirements.
- toomuchtodo 8y ago
  > Scaling up within a colo can be troublesome due to procuring hw, having remote hands rack it, setup, etc. One senior sysadmin/infrastructure engineer with on-prem experience is enough to scale up your colo presence. You can either assemble your own servers or custom order and have them shipped directly to the colo. Remote console and power management (PDUs) is a solved problem. Out of band management, also solved. Virtualization, solved. Push your VM snapshots, content, artifacts, and database backups into your object store of choice for offsite backups. Ideally, your colo facility is within driving distance of your office if you absolutely need physical access. Otherwise, you pay someone at the colo a few hundred bucks a month for remote hands services. EDIT: k8s arguably makes this easier than in the past. You want to run on your own cluster? You can. You need to burst your containers to spot instances in someone else's cloud? You can.
  - user5994461 8y ago
    All the problems you consider solved are only solved if you have the tooling from AWS/Google or half solved if you have VMWare. With physical hardware, the sysadmin will spend a lot of his time fighting the hardware supplier and the colo to get hardware in place and running, then reinvent the tooling. Any trip to the facility is half a day lost.
    - toomuchtodo 8y ago
      Many organizations run their own hardware successfully without the tooling I mention. There are problems, just different problems from cloud with significant cost savings realized. Why would you be fighting your hardware supplier or your colo? I have never had a hardware vendor "fight me", and only once had challenging negotiations with a colo provider. Have you never lost half a day of getting work done because Amazon's EC2 API was failing to launch new instances? I have! [1] To simply hand wave away hosting your own hardware as infeasible and more costly (especially when it's been proven to be more costly) is unproductive at best. [1] https://hn.algolia.com/?query=AWS%20outage&sort=byPopularity&prefix=false&page=0&dateRange=all&type=story https://hn.algolia.com/?query=AWS%20outage&sort=byPopularity... (HN search of "AWS Outage")
      - user5994461 8y ago
        The cost savings have never been proven. If anything, they're proven to be miscalculated every time someones gives his numbers. Self hosting is doable up to 2 or 3 servers with a very few services. Beyond that it's really suffering from the lack of tooling, the lack of isolation and the lead time of weeks to get anything more in place. DELL wants to re verify by phone 3 times before they bill or ship anything. Don't ask me why, I don't know, I keep begging them to stop doing that. I've had the API down about 4 times in a year, always for specific types of instance, if I remember the count well. Never more than a few hours. It's nothing in comparison to the weeks it takes to ship and setup physical hardware.
        deleted 8y ago
        [deleted]
- deleted 8y ago
  [deleted]
- drieddust 8y ago
  Servers are cheap enough so buying a few and keeping on standby is no brainer and they are good for 5 years generally.
weinzierl 8y ago
If you have someone who knows how to design systems and your workload is constant most of the time with occasioal spikes you could run your base load on your own machines and offload the spikes to AWS.
- lykr0n 8y ago
  Yep. There is a 99.99% chance one of the following will happen: - Your Colo has direct connect to AWS, so you can deploy EC2 under times of load - Your Colo offers some sort of virtualized infrastructure that you could wire into your network and offload under times of load - Your Colo has a virtual server provider running that you can offload to in times of load. - Is close enough to one of the big 3 that a Site to Site will work fine

by lykr0n 8y ago

chomp 8y ago

Even if you can't predict the workload too well, you can go hybrid cloud - colo for the baseline and then AWS for the unpredictable stuff. ManageIQ is great for this.

ekovarski 8y ago

... isn't that the hardest part, predicting workload, for many companies. Scaling up within a colo can be troublesome due to procuring hw, having remote hands rack it, setup, etc. If you can predict workload then you could also reduce your cloud bills, in theory, by moving spinning up/down instances. Many are going the cloud route because the cost of entry is much easier to start developing but eventually, yes, the cost skyrockets and you do end up paying for putting little forethought into the real workload requirements.

toomuchtodo 8y ago
> Scaling up within a colo can be troublesome due to procuring hw, having remote hands rack it, setup, etc. One senior sysadmin/infrastructure engineer with on-prem experience is enough to scale up your colo presence. You can either assemble your own servers or custom order and have them shipped directly to the colo. Remote console and power management (PDUs) is a solved problem. Out of band management, also solved. Virtualization, solved. Push your VM snapshots, content, artifacts, and database backups into your object store of choice for offsite backups. Ideally, your colo facility is within driving distance of your office if you absolutely need physical access. Otherwise, you pay someone at the colo a few hundred bucks a month for remote hands services. EDIT: k8s arguably makes this easier than in the past. You want to run on your own cluster? You can. You need to burst your containers to spot instances in someone else's cloud? You can.
- user5994461 8y ago
  All the problems you consider solved are only solved if you have the tooling from AWS/Google or half solved if you have VMWare. With physical hardware, the sysadmin will spend a lot of his time fighting the hardware supplier and the colo to get hardware in place and running, then reinvent the tooling. Any trip to the facility is half a day lost.
  - toomuchtodo 8y ago
    Many organizations run their own hardware successfully without the tooling I mention. There are problems, just different problems from cloud with significant cost savings realized. Why would you be fighting your hardware supplier or your colo? I have never had a hardware vendor "fight me", and only once had challenging negotiations with a colo provider. Have you never lost half a day of getting work done because Amazon's EC2 API was failing to launch new instances? I have! [1] To simply hand wave away hosting your own hardware as infeasible and more costly (especially when it's been proven to be more costly) is unproductive at best. [1] https://hn.algolia.com/?query=AWS%20outage&sort=byPopularity&prefix=false&page=0&dateRange=all&type=story https://hn.algolia.com/?query=AWS%20outage&sort=byPopularity... (HN search of "AWS Outage")
    - user5994461 8y ago
      The cost savings have never been proven. If anything, they're proven to be miscalculated every time someones gives his numbers. Self hosting is doable up to 2 or 3 servers with a very few services. Beyond that it's really suffering from the lack of tooling, the lack of isolation and the lead time of weeks to get anything more in place. DELL wants to re verify by phone 3 times before they bill or ship anything. Don't ask me why, I don't know, I keep begging them to stop doing that. I've had the API down about 4 times in a year, always for specific types of instance, if I remember the count well. Never more than a few hours. It's nothing in comparison to the weeks it takes to ship and setup physical hardware.
      - deleted 8y ago
        [deleted]
deleted 8y ago
[deleted]
drieddust 8y ago
Servers are cheap enough so buying a few and keeping on standby is no brainer and they are good for 5 years generally.

weinzierl 8y ago

If you have someone who knows how to design systems and your workload is constant most of the time with occasioal spikes you could run your base load on your own machines and offload the spikes to AWS.

lykr0n 8y ago
Yep. There is a 99.99% chance one of the following will happen: - Your Colo has direct connect to AWS, so you can deploy EC2 under times of load - Your Colo offers some sort of virtualized infrastructure that you could wire into your network and offload under times of load - Your Colo has a virtual server provider running that you can offload to in times of load. - Is close enough to one of the big 3 that a Site to Site will work fine