81–90 of 149 posts
Back to the future: this was how computing worked back in the punch card days. Minicomputers and personal computers were supposed to liberate you from this tyranny: computing so cheap that you could have a whole computer to your self for a while!
Earlier quoted context omitted.
Which is why reserved instances exist.
The reserved instance pricing model is really poorly implemented. You have to commit to an instance class and a region, and if you need to change you can, but there is some secondary market. When compared to a sustained use model, it is a disaster. Managing all that in a large org is a real pain in the ass.
Standard vs. Convertible: Convertible allows you to switch between instance families (like c3, m3, m4, i2, r3 etc...) but it requires you to make a 3yr commitment, commit to a specific AZ and doesn't offer the same level of savings you'd get with a 3yr standard, I think it's closer to the savings you'd get with a 1yr Standard RI. Standard RI's come in 1yr or 3yr commitments. You can choose between the default option of the "Regional Benefit" which allows you to apply the RI to any instance that meets the RI criteria in a given region or you can choose the "Capacity Reservation" option which requires you to commit to a specific AZ to guarantee your reservation. That's right, your 'reserved' instance isn't necessarily reserved in the case of an outage unless you commit to a AZ.
One benefit that you get with Standard RI's is that they can be applied to any size instance in the family for which you've purcahsed them. Amazon allows you to convert between nano, micro, small, large, 2xlarge etc. within an Instance Family (t2, c3, m3, r4 etc.) with Standard RI's and they apply these conversions automatically on your bill.
Then you also have to choose how you pay, no-upfront and all monthly (smallest capex), partial upfront/partial monthly or all-upfront (largest capex).
It's frustrating because it's so complex that it makes me hesitate. I never feel like I'm getting the best deal and it just feels like AWS is taking advantage of the market by making pricing impossible to decipher.
Does anyone have any good methods for determining how many RI's to purchase, how often etc?
Back to the future: this was how computing worked back in the punch card days. Minicomputers and personal computers were supposed to liberate you from this tyranny: computing so cheap that you could have a whole computer to your self for a while!
Earlier quoted context omitted.
It's really really difficult to be able to turn on and off instances as needed, like turn a test instance on in the morning when developers come in and turn it off in the evening when they leave.
You can implement this with a simple auto-scaling group or write a small Lambda function which runs at a certain time to start/stop the instance
http://docs.aws.amazon.com/autoscaling/latest/userguide/sche...
Back to the future: this was how computing worked back in the punch card days. Minicomputers and personal computers were supposed to liberate you from this tyranny: computing so cheap that you could have a whole computer to your self for a while!
Somehow we've reached a point where a 2GHz, 2GB computer that fits in your pocket is only worth using as a terminal.
Earlier quoted context omitted.
They would legitimately lose a lot of money if they did this now (and I would argue, wouldn't make up for it in market share). Most companies I work with who switch to AWS think it's a 1:1 conversion in terms of cost from a data center and pretty much just "leave AWS on" not realizing that they are not only paying for computing cost but the hidden cost of being able to scale up more instances quickly.
It's really really difficult to be able to turn on and off instances as needed, like turn a test instance on in the morning when developers come in and turn it off in the evening when they leave.
Earlier quoted context omitted.
It's really really difficult to be able to turn on and off instances as needed, like turn a test instance on in the morning when developers come in and turn it off in the evening when they leave.
Tag it with something like shutdown=non-biz-hours, or can even specify a schedule that a lambda function can pick up each minute or hour and parse to stop/start any instance that falls within that window.
Earlier quoted context omitted.
The reserved instance pricing model is really poorly implemented. You have to commit to an instance class and a region, and if you need to change you can, but there is some secondary market. When compared to a sustained use model, it is a disaster. Managing all that in a large org is a real pain in the ass.
Not just region, I think it's per AZ.
Earlier quoted context omitted.
That is basically the serverless main "point of sell" you are just one step away from automation (if you aren't already doing it) and it will be virtually the same as serverless
You're right, this is effectively a serverless mode. But the serverless instances that are currently available (at least on aws) aren't powerful enough for some applications. For those of us stuck in the middle, needing big machines with serverless behaviour, this is a massive win.
What are you running your big jobs on? Because I'm currently using Batch, but given you've got to wait for the compute environment/VM to start up (if it's not already running), and that's a pain because it takes forever to startup.
I wish I could just run containers on large hardware the same way we can run lambda's: press the button and it just runs, I don't really care about having my own full compute environment, I just need enough memory and CPU to run it.
Earlier quoted context omitted.
Tag it with something like shutdown=non-biz-hours, or can even specify a schedule that a lambda function can pick up each minute or hour and parse to stop/start any instance that falls within that window.
Well that works if you're a startup in one timezone with no teams depending on your service. If you work on a larger company, it's quite possible the sun never sets on your project (west coast, east coast, Europe, India, Australia or SE Asia)