5 ms·

AWS at the lowest level is just a virtual server in the cloud (EC2) and files in an unlimited storage (S3). Maybe if AWS is too difficult one is making it too

AWS at the lowest level is just a virtual server in the cloud (EC2) and files in an unlimited storage (S3). Maybe if AWS is too difficult one is making it too difficult by using services that are overkill at the time. You can slowly add services as you need them. A couple web machines, load balancer and database is as easy to setup on AWS as it is locally and it has many more availability and security guards than any local server. AWS success is largely from startups and the ability of Amazon to make it easy/fast to setup, yes it can get complex like anything but by default it is pretty simple. They do have many, many services but you only really need a handful or a couple depending on the project. Maybe they need to separate out those huge lists of features/systems into buckets of simple, personal, small to medium, enterprise etc.

imaginenore 10y ago
For someone who has never used AWS (because there are much cheaper options), every time I look at even setting up a simple server, AWS seems insane. With a VPS server it's trivial. You go to the website of your choice, you pick whatever specs you need, you rent the server, you get exactly that: RAM + cores + disk space. With AWS it looks like you have to rent storage separately and somehow connect it to your instance. Look at the pricing page, it's ridiculous for someone new: https://aws.amazon.com/ec2/pricing/ https://aws.amazon.com/ec2/pricing/ I have to google what "ECU" is, I have to figure out what "Variable" ECU means, I have to figure out what "EBS Only" means. There's not even a tooltip to explain any of that is. Even after googling "ECU", and going to Amazon's FAQ page, it's still not clear exactly what I'm paying for. And that's just the purchasing part.
- lisa_henderson 10y ago
  And you have to figure out what a "reserved instance" is. Because that saves you 70%. And so, if you miss that small point, then you are wildly over paying. But who can learn all these details in a short amount of time?
  - tptacek 10y ago
    A reserved instance is just an instance you don't pay hourly for. Lots of people use AWS specifically so they can pay hourly, turning up servers dynamically in response to load, and then turning them off when spikes subside, without penalty.
    - paulmd 10y ago
      However, most people's load doesn't regularly go to zero - and in fact it still might be advantageous to use reserved instances even if it did, because they're so much cheaper. The situation is analogous to "base-load vs peak-load" on the power grid. Base-load power (reserved instances) are very cheap but cannot respond to transient spikes in the load. Peaking plants (on-demand instances) can respond to transient spikes quickly, but are expensive to run. A naieve model is that you find your minimum usage and buy enough baseload to cover that, with peaking beyond that. However, since peaking is so much more expensive than baseload this is not necessarily optimal - instead, you may want to buy some extra baseload that isn't fully utilized during your off-hours, because that offsets expensive peaking capacity during your high-demand hours. You almost certainly would not want to have zero reserved instances.
    - cothomps 10y ago
      .... kind of. A reservation is all about planning capacity. If you know (e.g.) that you need two web servers "hot" all the time to serve a base level of traffic, you can pay for that up front either partially or in total (a reservation) at some pretty significant savings. You can add hourly (or spot) capacity as needed - but paying for what you'll be using up front can make AWS very economical. If you're paying for X1 servers for an extended period of time on an hourly basis, you should be entitled to a thank you note from Jeff Bezos.
  - visarga 10y ago
    I used a GPU instance today and it cost me 1$. I think you can discover the best setup in a week or so, with just a few dollars to waste. It's just a small "learning tax".
- yaourt 10y ago
  You've overthinking things. Give the Free Tier a shot and you'll see how easy it is to get an instance up and running. Sure, there is a lot of customization available if you want it though you can make do with the defaults most of the time.
- visarga 10y ago
  That means using AWS is just as complicated as using an API in Python or JavaScript. You have to read it carefully, understand their model of thinking, and master the subset of functionality that you need. Nothing new for IT people. But I love DigitalOcean much more. If only they had GPU instances.
- derefr 10y ago
  I had the same problems years back when I first tried AWS; I mostly just learned everything by rote. Recently, though, I tried setting up a simple home "VM lab"—basically a two-node cluster of regular workstations, running bare-metal hypervisors (e.g. Xen, VMWare ESXi, etc.) When you do this, suddenly everything IaaS providers do comes into stark clarity. For example, you realize that with even two nodes of scale, that sticking a lot of storage into each VM node is expensive, especially if you're not going to use it all on each node; it's a lot cheaper to have diskless VM hosts (save for an SSD for swapfiles), and stick the disk volumes on a SAN, connected to the VM hosts by something like iSCSI. (This then gives you other benefits, like disks that are copy-on-write clones of other "template" disks on the SAN; the ability of VMs to "fail over" to another VM host (and thus the ability of the host to gracefully restart without killing its VMs—at least, from a user perspective); "free" snapshots with rollback; etc.) EBS is exactly such a setup—the perfectly-sensible setup for any VM cluster operating at scale. It's the other setup—local disks in the VM hosts—that's insane and doesn't scale; everyone is just familiar with it because most people's experience of providers is with the ones just getting off the ground who are before the ROI intercept. Or, for another example, when running a heterogenous VM cluster, you immediately realize that the unit that the VM CPU resource commitment is measured by on a VM host is a "vCPU"—which is not exactly one reserved physical core (since it can just represent a hyperthread, and can be overcommitted when other VMs aren't using their resources) and is not the same on each host, since each core operates at a different speed. The closest you can really get to getting a useful unit of CPU allocation, then, is by rounding off the host differences to integer multiples—such that you could say that one vCPU on host A is (roughly) equal to two vCPUs on host B. That unit, whatever you call it, will then scale up over time, as you phase out previous generations of VM host hardware. That's an ECU. Smaller hosting companies can get away with telling you what CPU you'll be running on, because smaller hosting companies are new enough to have homogenous hardware, and small enough to not attempt anything like live VM migration. A company that has both heterogenous hardware and must migrate VMs across that heterogenous hardware can't make any such claims.

imaginenore 10y ago

For someone who has never used AWS (because there are much cheaper options), every time I look at even setting up a simple server, AWS seems insane. With a VPS server it's trivial. You go to the website of your choice, you pick whatever specs you need, you rent the server, you get exactly that: RAM + cores + disk space. With AWS it looks like you have to rent storage separately and somehow connect it to your instance. Look at the pricing page, it's ridiculous for someone new: https://aws.amazon.com/ec2/pricing/ https://aws.amazon.com/ec2/pricing/ I have to google what "ECU" is, I have to figure out what "Variable" ECU means, I have to figure out what "EBS Only" means. There's not even a tooltip to explain any of that is. Even after googling "ECU", and going to Amazon's FAQ page, it's still not clear exactly what I'm paying for. And that's just the purchasing part.

lisa_henderson 10y ago
And you have to figure out what a "reserved instance" is. Because that saves you 70%. And so, if you miss that small point, then you are wildly over paying. But who can learn all these details in a short amount of time?
- tptacek 10y ago
  A reserved instance is just an instance you don't pay hourly for. Lots of people use AWS specifically so they can pay hourly, turning up servers dynamically in response to load, and then turning them off when spikes subside, without penalty.
  - paulmd 10y ago
    However, most people's load doesn't regularly go to zero - and in fact it still might be advantageous to use reserved instances even if it did, because they're so much cheaper. The situation is analogous to "base-load vs peak-load" on the power grid. Base-load power (reserved instances) are very cheap but cannot respond to transient spikes in the load. Peaking plants (on-demand instances) can respond to transient spikes quickly, but are expensive to run. A naieve model is that you find your minimum usage and buy enough baseload to cover that, with peaking beyond that. However, since peaking is so much more expensive than baseload this is not necessarily optimal - instead, you may want to buy some extra baseload that isn't fully utilized during your off-hours, because that offsets expensive peaking capacity during your high-demand hours. You almost certainly would not want to have zero reserved instances.
  - cothomps 10y ago
    .... kind of. A reservation is all about planning capacity. If you know (e.g.) that you need two web servers "hot" all the time to serve a base level of traffic, you can pay for that up front either partially or in total (a reservation) at some pretty significant savings. You can add hourly (or spot) capacity as needed - but paying for what you'll be using up front can make AWS very economical. If you're paying for X1 servers for an extended period of time on an hourly basis, you should be entitled to a thank you note from Jeff Bezos.
- visarga 10y ago
  I used a GPU instance today and it cost me 1$. I think you can discover the best setup in a week or so, with just a few dollars to waste. It's just a small "learning tax".
yaourt 10y ago
You've overthinking things. Give the Free Tier a shot and you'll see how easy it is to get an instance up and running. Sure, there is a lot of customization available if you want it though you can make do with the defaults most of the time.
visarga 10y ago
That means using AWS is just as complicated as using an API in Python or JavaScript. You have to read it carefully, understand their model of thinking, and master the subset of functionality that you need. Nothing new for IT people. But I love DigitalOcean much more. If only they had GPU instances.
derefr 10y ago
I had the same problems years back when I first tried AWS; I mostly just learned everything by rote. Recently, though, I tried setting up a simple home "VM lab"—basically a two-node cluster of regular workstations, running bare-metal hypervisors (e.g. Xen, VMWare ESXi, etc.) When you do this, suddenly everything IaaS providers do comes into stark clarity. For example, you realize that with even two nodes of scale, that sticking a lot of storage into each VM node is expensive, especially if you're not going to use it all on each node; it's a lot cheaper to have diskless VM hosts (save for an SSD for swapfiles), and stick the disk volumes on a SAN, connected to the VM hosts by something like iSCSI. (This then gives you other benefits, like disks that are copy-on-write clones of other "template" disks on the SAN; the ability of VMs to "fail over" to another VM host (and thus the ability of the host to gracefully restart without killing its VMs—at least, from a user perspective); "free" snapshots with rollback; etc.) EBS is exactly such a setup—the perfectly-sensible setup for any VM cluster operating at scale. It's the other setup—local disks in the VM hosts—that's insane and doesn't scale; everyone is just familiar with it because most people's experience of providers is with the ones just getting off the ground who are before the ROI intercept. Or, for another example, when running a heterogenous VM cluster, you immediately realize that the unit that the VM CPU resource commitment is measured by on a VM host is a "vCPU"—which is not exactly one reserved physical core (since it can just represent a hyperthread, and can be overcommitted when other VMs aren't using their resources) and is not the same on each host, since each core operates at a different speed. The closest you can really get to getting a useful unit of CPU allocation, then, is by rounding off the host differences to integer multiples—such that you could say that one vCPU on host A is (roughly) equal to two vCPUs on host B. That unit, whatever you call it, will then scale up over time, as you phase out previous generations of VM host hardware. That's an ECU. Smaller hosting companies can get away with telling you what CPU you'll be running on, because smaller hosting companies are new enough to have homogenous hardware, and small enough to not attempt anything like live VM migration. A company that has both heterogenous hardware and must migrate VMs across that heterogenous hardware can't make any such claims.