The lesson I see from this: AWS hurts bad if you are using it heavily, but salaries... salaries kill. Automate, outsource and self-build as much and as long as you can possibly stand it, and then push on a lot longer than that.
Going off on a tangent here, but if (a) "software is eating everything" and (b) "salaries kill", wouldn't that mean a society of mass (30%+) unemployment in the future?
I wonder who would have the money to pay for stuff like Everpix or any other offering at that point...
The crazy thing is that when people are suffering, there is work to be done. If the 30%+ unemployed in that scenario could reorganize themselves into servicing each others needs, they would surely want to do that.
basic income?
I also worry about centralization (of both government and corporate power) which get at the primary political problem to be dealt with in my opinion: how to mitigate the sociopathic element.
My best answer, at this point, is to break large states up into lots of small states, spreading the sociopathic ruling classes broadly and making it difficult for corporate interests to completely dominate a given political unit.
Within a given smaller and sovereign political unit, I hope that decisions will be made that encourage full, useful employment (since there is less room for both social services shenanigans as well as corporate indifference in a compressed society.)
Even better is if you can plan your infrastructure on AWS around using spot instances. They can be really cheap (we're talking a 5x times cheaper then on-demand and 3-4x than reserved). If your instances are used in a stateless fashion with all persistent state saved externally (DB, S3, etc) then you can do some pretty cheap scaling with spot instances.
One setup I've played with is a core set of non-spot instances phalanxed by a number of spot instances (at a couple different price points) for stateless web traffic. As long as the spot price stays below your bid you have significantly more instances available (which should give your users better response times). When the spot price rises your spot instances die and things slow down, but your app would still be alive thanks to the non spot instances. Again it takes quite a bit more engineering to get a setup like this but this is the kind of thing you need to do to take advantage of elastic computing.
In our experience with CPU or IO intensive workloads, Spots are still 2-5x slower than what you can get at decent dedicated provider..
Actually I ran the numbers for some of our (higher end ec2 instances). And some of them you break even in 6 weeks
- AWS reserved instances (doesn't help with storage costs though)
- dedicated servers at e.g. SoftLayer
- colocation
Over the years, I've had good experience with WebNX which has good connectivity to Asia. They've been supposed to open a NY location for a while now...Speaking of NY, there's reliablesite.net which is ok. You have Hivelocity in Florida (which I didn't use specifically for South America, but I imagine they'd be good for that).
There's a handful of companies which I've never used but that I've been hearing good things about for years. NetDepot, SingleHop and LimeLight Networks for example.
I have used 100TB in both Singapore and Washington. They are a Softlayer reseller. The extra level of indirection sucks when something goes bad, but they are much cheaper (what you can get from 100TB for $400 might cost $1200 at Softlayer). A few of the locations they actually have staff at, so I imagine that's much better.
I recommend you spend some time on webhostingtalk.com. It's great. There's a forum specifically for deals which can be useful to pick something up.
For anyone who's only familiar with AWS/clouds: most of these take 1-2 days to set up machines, their control panels are horrible, they don't have an API and you might not even get a dedicated KVM switch.
Wow, I feel like a huge advertising billboard this morning!
Many of these are older than OpenStack by a wide margin. OVH in particular is huge, they own many data centers, thousands of employees...you just don't make that sort of switch overnight. The cost and risk might not be justifiable.
However, on the database side of things, there was a lot of room for optimization (and we only got to some of it).