By Peter McCallum

We have all heard the idiom: “Don’t put all your eggs in one basket!” Ostensibly this wisdom has been passed down from the farming generations to us modern folk who check our eggs in their Styrofoam nests prior to leaving the supermarket. Mark Twain countermanded this idiom by saying “Behold, the fool saith, ‘Put not all your eggs in the one basket’ … but the wise man saith, ‘Put all your eggs in the one basket and - WATCH THAT BASKET.’" Breaking through the funny prose, I believe he is telling us that the one basket theory is fine as long as it is a great basket, and you are very careful. So are we to follow the hard-won wisdom of the ages and avoid single-basket strategy? Or rely on superior technology and monitoring to prevent mishaps?

In a recent article posted in The Register ( http://www.theregister.co.uk/2017/02/28/aws_is_awol_as_s3_goes_haywire/ ), we discovered that one of the best engineered and embraced egg baskets in the known universe went crazy and many eggs were “broken” for a period of time. According to legend, Amazon’s AWS and S3 storage pools are better engineered and managed and monitored than nearly any infrastructure in the world. This is why it is so impactful when someone trips and the eggs spill. There are other idioms at work here like: “hardware eventually breaks, software eventually works” and the great Scottish idiom “The best-laid plans of mice and men oft go awry.” I’ll let other disaster-chasing tech writers tell you what happened, and to who, but I would like to talk about strategy right now.

Every single tech company in the world wants a piece of AWS. If you build a product that cannot connect to and speak with AWS, you have made a product management error. If you are an IT director or CIO and you do not have some mention of AWS in your IT plan, you should consider your resume as a priority. Why? It’s the gold standard for “the cloud” today. There are other fantastic cloud providers in the public and private cloud spaces that have better technology, better customer service, better pricing model - what have you - but nobody has the scale and market share as AWS. That is why it’s so scary when something goes wrong – especially to the extent that it’s wrong enough that AWS can’t even post an update about what is happening because that service runs on itself.

So this is where eggs and baskets come into play. One of the most significant trends I have seen in IT today is moving DR off-premise to the cloud. For many companies, DR comprises 50-70% of their IT budget (software, time, and infrastructure included). When accosted about this figure, a CIO/IT Director will be challenged to “reduce the cost of insurance” by consolidating, re-architecting, cost-cutting, head-count-cutting, and other terrors in order to bring that figure down to “reasonable levels.” One common strategy today is to simply shift some or all DR to the cloud. In most cases, to AWS with an S3 backend. However, there are some glaring issues that may or may not be a problem for you, most notably: “If you back up to the cloud, who backs up the cloud?”

There. A new modern idiom. I’d like full credit for that. So as it turns out, there are some good reasons to use the cloud and some good reasons to maintain your own infrastructure. Instead of just villainizing AWS and pointing out their recent trouble, I’ll share a few architectural nuggets I’ve learned over the years:

  1. Backing up is one thing… but recovery is really the point, right? It’s now as easy to back up to the cloud as it was to your own tapes and libraries. However, it may not be as easy to recover. Consider that recovery involves temporarily running in the cloud for business continuity, and replicating good data back to your datacenter. Performance and bandwidth could be issues, and synchronizing changes back from the cloud can be onerous at best without the right technology.
  2. Long-term retention for peace of mind, and or compliance is really well-suited for the cloud. As long as the economics work out. (Remember that if you pay for something and own it, it eventually should become cheaper than paying for something endlessly over time. Do the math!) Again: the cloud is great for archival and backups, but recovery – especially in a hybrid model – has many challenges.
  3. Running production in the cloud is GREAT! It’s a lot like living in a full-service hotel instead of owning your own home. Right? They just take care of it. It never fails, never goes down, and for one flat-fee you have absolutely no worries. Until it does (or doesn’t) and you have absolutely no recourse. Imagine if you have a business that processes millions of transactions a minute and for your 2 Cents/GB/Month it works perfectly 98% of the time. However, every 15 minutes of downtime costs you $1 million. How many minutes of downtime can you sustain before you lose any and all ROI due to lack of diversification and redundancy?
  4. What if you want to change cloud providers, or embrace a new hybrid model? Can you bridge bi-directionally between your cloud provider and any infrastructure you choose to run on? Can you be a DR site for AWS and if your S3 buckets go offline for 5 hours without notice, can you run production from your own facility until AWS gets things fixed? Who would do that?!?

So here is my summary, in case you are bored of idioms and tidbits: No matter how good a provider or technology is, there is no such thing as foolproof nor failsafe. However, there is a great concept that the storage and IT industry have tried to get away from and that is diversification . In fact, the trend of the entiretech industry is to frantically pull you into a single, all-eggs-in-one-basket approach that promises “one-throat-to-choke” support, procurement, and simplicity of operations. So to make our lives easier, we may have just opened ourselves to a whole new universe of risk that has everything to do with our attempts to reduce it.

I will not villainize AWS or the astonishingly good technology and services they provide. As part of a strategy to provide data resiliency and business continuity, they are a key player and a market standard. But the take-home lesson is that if AWS can have an outage that impacts so many businesses at once (and leaves millennials unable to socialize for 5 hours) perhaps you should look at diversification, hybrid cloud strategies, and vendor-neutral platforms that provide a pathway to jump YOUR data across any infrastructure you need it to be running on in any location you need it in.

Want to hear more from Pete McCallum? Tune into his live Webinar on March 7th at 10 am ET. Watch live or on demand. https://falconstor.com/page/633/brighttalk-upcoming-on-demand-webinars

Corporate Headquarters
701 Brazos Street, Suite 400
Suite 1300
Austin, Texas 78701
Tel: +1.631.777.5188
Europe Headquarters
Landsberger Str. 312
80687 Munich, Germany
Tel: +49 (0) 89.41615321.10
Asia Headquarters
Room 1901, PICC Office Tower,
No. 2, Jian Guo Men Wai Street
Chaoyang District
Beijing, 100022
Tel: +86.10.6530.9505
Information in this document is provided “AS IS” without warranty of any kind, and is subject to change without notice by FalconStor, which assumes no responsibility for any errors or claims herein. Copyright © 2019 FalconStor Software. All rights reserved. FalconStor Software and FalconStor are registered trademarks of FalconStor Software, Inc. in the United States and other countries. All other company and product names contained herein are or may be trademarks of the respective holder.
FalconStor Software
Why Falconstor
FalconStor Software
Privacy Policy & Legal
© 2019 FalconStor Software. All rights reserved.