3 ms·
> But how, for example, is SoftLayer better than AWS? Where do I begin... The latency to our dedicated DB servers is always 1-2 milliseconds. Never 5. Never 50
by old-gregg 14y ago
> But how, for example, is SoftLayer better than AWS?
Where do I begin... The latency to our dedicated DB servers is always 1-2 milliseconds. Never 5. Never 50. I do not understand how people tolerate 50ms response time from memcached servers on AWS.
We pay much less "per request". Way less. We never have to worry about servers disappearing. We don't need proprietary APIs for server images because the Chef script makes me a DB or a DNS box out of any Linux box.
We do not waste any time "architecting for failure": our databases run on RAID arrays with hot standbys, no need for chaos monkeys. Everything is very, very simple. We never used SoftLayer documentation because nothing of what we use needs to be documented.
And most importantly, we had less than an hour of downtime in 3 years. And none of that was Softlayer's fault.
It becomes much harder to reason about performance, uptime and responsiveness of your system when the underlying infrastructure does not provide guarantees on basic building blocks like I/O latency. Everything on AWS is always in flux and you have to over-allocate resources and/or over-engineer around those faulty building blocks. It may make you feel like a hero to survive in this jungle, but doesn't it look like a "forced premature optimization"?
99% of every graduating YC class could be running on a single pair of dedicated low-end servers and saving themselves a TON of time.
- mbell 14y ago> We do not waste any time "architecting for failure": our databases run on RAID arrays with hot standbys, no need for chaos monkeys. Ha - your in for some fun the first time your hardware fails.
- old-gregg 14y agoWe're not. Hardware failures were "invented" before Amazon marketing thought of them. There are reasonable engineering overhead to deal with them, and we do. You are welcome to go and unplug any of our severs with no measurable downtime or data loss. My point is that we didn't have to spend nearly as much money and time as AWS forces you to do. Another point I want to make: not all hardware is the same. If you're running in Amazon/Google style data center optimized around energy efficiency and real estate density and you're spending serious R&D money on tolerating server failures. But guess what: you are not Google and you are not Amazon. You need to be in a datacenter which is optimized for individual server longevity. Cooler temperatures. Better hardware. Have a hot stand-by. That's cheap. Such way to "compute" may be expensive for Google scale to run, but it's much cheaper and easier for nearly everyone else.
- mbell 14y agoGiven your response - I don't understand why you would then make the statement about Chaos Monkey. It also appears that your earlier statement appears to be false: "We do not waste any time "architecting for failure"". If you can pull the plug on a server and not lose service, you certainly have architected for failure. Chaos Monkey does effectively exactly what you claim to be able to survive - it unplugs servers. The fact that it runs on AWS is inmaterial, it exists to make sure you really can survive a server disappearing. The underlying point is that many teams build their software to survive server failures and never test the fail-over till it occurs for real, that often goes very badly. Chaos Monkey tests fail-over on a regular basis so you find out about it before it costs you hours of downtime.