Archive

The Dulin Report

Browsable archive from the WordPress export.

Results (45)

The future is bright Mar 30, 2025 On Amazon Prime Video’s move to a monolith May 14, 2023 One size does not fit all: neither cloud nor on-prem Apr 10, 2023 Some thoughts on the latest LastPass fiasco Mar 5, 2023 Comparing AWS SQS, SNS, and Kinesis: A Technical Breakdown for Enterprise Developers Feb 11, 2023 There is no such thing as one grand unified full-stack programming language May 27, 2022 Which AWS messaging and queuing service to use? Jan 25, 2019 Using Markov Chain Generator to create Donald Trump's state of union speech Jan 20, 2019 Adobe Creative Cloud is an example of iPad replacing a laptop Jan 3, 2019 Facebook is the new Microsoft Apr 14, 2018 Leaving Facebook and Twitter: here are the alternatives Mar 25, 2018 Rather than innovating Walmart bullies their tech vendors to leave AWS Jun 27, 2017 Architecting API ecosystems: my interview with Anthony Brovchenko of R. Culturi Jun 5, 2017 TDWI 2017, Chicago, IL: Architecting Modern Big Data API Ecosystems May 30, 2017 Online grocers have an additional burden to be reliable Jan 5, 2017 Windows 10: a confession from an iOS traitor Jan 4, 2017 What I learned from using Amazon Alexa for a month Sep 7, 2016 Why I switched to Android and Google Project Fi and why should you Aug 28, 2016 Amazon Alexa is eating the retailers alive Jun 22, 2016 In search for the mythical neutrality among top-tier public cloud providers Jun 18, 2016 What can we learn from the last week's salesforce.com outage ? May 15, 2016 Why it makes perfect sense for Dropbox to leave AWS May 7, 2016 Our civilization has a single point of failure Dec 16, 2015 IT departments must transform in the face of the cloud revolution Nov 9, 2015 Setting Up Cross-Region Replication of AWS RDS for PostgreSQL Sep 12, 2015 Top Ten Differences Between ActiveMQ and Amazon SQS Sep 5, 2015 What Every College Computer Science Freshman Should Know Aug 14, 2015 Ten Questions to Consider Before Choosing Cassandra Aug 8, 2015 Big Data Should Be Used To Make Ads More Relevant Jul 29, 2015 Book Review: "Shop Class As Soulcraft" By Matthew B. Crawford Jul 5, 2015 Attracting STEM Graduates to Traditional Enterprise IT Jul 4, 2015 Smart IT Departments Own Their Business API and Take Ownership of Data Governance May 13, 2015 Guaranteeing Delivery of Messages with AWS SQS May 9, 2015 We Need a Cloud Version of Cassandra May 7, 2015 The Clarkson School Class of 2015 Commencement speech May 5, 2015 Building a Supercomputer in AWS: Is it even worth it ? Apr 13, 2015 Ordered Sets and Logs in Cassandra vs SQL Apr 8, 2015 Microsoft and Apple Have Everything to Lose if Chromebooks Succeed Mar 31, 2015 Where AWS Elastic BeanStalk Could be Better Mar 3, 2015 Trying to Replace Cassandra with DynamoDB ? Not so fast Feb 2, 2015 Why I am Tempted to Replace Cassandra With DynamoDB Nov 13, 2014 Infrastructure in the cloud vs on-premise Aug 25, 2014 Cassandra: a key puzzle piece in a design for failure Aug 18, 2014 Cassandra: Lessons Learned Jun 6, 2014 Things I wish Apache Cassandra was better at Feb 12, 2014

Infrastructure in the cloud vs on-premise

August 25, 2014

[caption id="attachment_250" align="aligncenter" width="300"]Cloud Cloud[/caption]

I made a comment on twitter saying that if you are still operating an on-premise data center in the second decade of the 21st century you are wasting a ton of money. I was talking specifically about AWS vs on-premise. I got some pushback on that assertion in the form of private messages. Here is the summary of the feedback I received:

  1. AWS only makes sense if you need to spin up hundreds of servers fast. Otherwise it is a costly low quality proposition.

  2. In AWS you have zero control of your infrastructure and therefore you have no control over the outcome of failures.

  3. On premise data centers are built to stay operational whereas on AWS you must build your infrastructure with the expectation of failure.


As an application developer my experience is quite the opposite. In the AWS environment I am able to provision resources as needed based on the requirements of my application. I cannot do so in an on-premise data center where any sort of an upgrade or installation can take weeks or months of red tape. At this point in my career, having seen what is possible in AWS and in the cloud in general I have zero interest in building anything out in an on-premise data center.

As for control of the infrastructure, where is the delineation ? At what point do you say with certainty that you have full control over your infrastructure ? Even if you have control over your LAN and other on-premise resources you still have to rely on your power company for electricity. Power companies solved the problem of offering energy as a utility, why not IT infrastructure companies offering their resources as a utility ?

The only way an on-premise datacenter can be better than anything AWS can offer is if you build the exact same infrastructure as they have, with the same resources and tools to help design for failure. Yes, that includes multiple data centers in geographically distinct regions (as in Virginia and California). Sure, there are flaws in AWS, and they do on occasion have outages. But so do on-premise data centers and in my experience with much greater frequency and with greater impact.

Consider the April 2011 EBS outage at Amazon in one of their availability zones:
What about Netflix, an AWS customer that kept on going because they had proper "design for failure"? Try doing that in your private IT infrastructure with the complete loss of a data center. What about another AWS/enStratus startup customer who did not design for failure, but took advantage of the cloud DR capabilities to rapidly move their systems to California? What startup would ever have been able to relocate their entire application across country within a few hours of the loss of their entire data center without already paying through the nose for it?

Sure, when you move to the cloud you give up control over your infrastructure, but the whole point of designing your applications for failure is to make your lack of control less relevant.