<story><title>Dodging S3 Downtime with Nginx and HAProxy</title><url>https://blog.sentry.io/2017/03/01/dodging-s3-downtime-with-nginx-and-haproxy.html</url></story><parent_chain><item><author>newobj</author><text>Alternate title: &amp;quot;Replacing S3 downtime for vastly greater amounts of your own downtime&amp;quot;&lt;p&gt;What is the name for this phenomenon where folks think they can out-available a thing that has multiple engineers singularly dedicated to nothing more than its availability &amp;#x2F;and&amp;#x2F; operation? It it just hubris? Surely there must be a more clinical name.</text></item></parent_chain><comment><author>Sanddancer</author><text>Caching proxies are old hat. Things like squid have existed pretty much the entire lifespan of the web. Keeping things close to your servers means you don&amp;#x27;t have the inherent delay of pulling things from a remote server, regardless of how fast amazon makes things.&lt;p&gt;Additionally, not keeping all your eggs in Amazon&amp;#x27;s basket means you&amp;#x27;re not SOL when they have a datacenter hosting all your content go down. It also means that if and when a service that better fits your needs comes along, you are more readily able to migrate without problems.&lt;p&gt;Finally, site reliability is not something that takes a team the size of Amazon&amp;#x27;s. A lot of the things that are required for availability on AWS -- redundant systems providing services, standbys, etc -- are things that sysadmins were doing before AWS was extant. AWS&amp;#x27; biggest gift to reliability is that its instances are less stable than most dedicated servers; you&amp;#x27;re taught from day one not to rely on a single server, so you build it right the first time.&lt;p&gt;So no, it&amp;#x27;s not hubris. It&amp;#x27;s calculating price&amp;#x2F;performance, it&amp;#x27;s applying things you&amp;#x27;re probably already doing to a new problem, and figuring out what the best solution really is, which rarely involves just throwing money at Amazon.</text></comment>
<story><title>Dodging S3 Downtime with Nginx and HAProxy</title><url>https://blog.sentry.io/2017/03/01/dodging-s3-downtime-with-nginx-and-haproxy.html</url></story><parent_chain><item><author>newobj</author><text>Alternate title: &amp;quot;Replacing S3 downtime for vastly greater amounts of your own downtime&amp;quot;&lt;p&gt;What is the name for this phenomenon where folks think they can out-available a thing that has multiple engineers singularly dedicated to nothing more than its availability &amp;#x2F;and&amp;#x2F; operation? It it just hubris? Surely there must be a more clinical name.</text></item></parent_chain><comment><author>Klathmon</author><text>I don&amp;#x27;t necessarily agree with it, but the common response to this is all about timing.&lt;p&gt;With AWS you don&amp;#x27;t have any control over &amp;quot;higher risk&amp;quot; times. If you have a massive launch coming up, or you are nearing peak usage for the year, or your clients need you to be stable for the next few months, you can&amp;#x27;t put updates on hold, you don&amp;#x27;t know to get a few more people on standby, you can&amp;#x27;t choose to not make changes to your system, because it&amp;#x27;s not your system.&lt;p&gt;With an in house solution you can choose to lock it down for a month, or do the risky upgrades&amp;#x2F;changes at your lowest traffic time, or even give your customers a heads up if needed. Hell even just being able to mak e sure that your best sysadmin isn&amp;#x27;t out getting hammered when you go to make changes could go a long way.&lt;p&gt;There is some merit to that idea, but I personally feel the track record of many of these services is so near perfect that the chances of unexpected downtime is still smaller than most could realistically manage.</text></comment>