Diversify Your Cloud Portfolio or Bank on Failure

May 15, 2017 Joshua McKenty

Why would a business choose a strategy of investing in a single cloud? It doesn’t make sense in today’s marketplace.

What if I asked you to invest your entire savings into one stock: would you do it? Of course not. You don’t have to be a Wall Street professional to understand the reasons to invest in more than one company. So, why would a business choose a strategy of investing in a single cloud? It doesn’t make sense in today’s marketplace.

Initially, cloud providers like Microsoft Azure, AWS or Google Cloud were commodities using pricing as a competitive advantage. But today, these providers are differentiating themselves with unique value-add services and features that make sense for different businesses. Google, for example, offers arguably the best Vision AI services, which for retail business will enable them using facial recognition to connect online and offline identifies for loyalty programs. But if you’re focused on replatforming some of your legacy applications and bringing them to the cloud, you’ll probably want to use Microsoft Azure SQL and Azure Active Directory.

In addition to features, you’ll want to consider your needs for locality, regulatory or service-level agreement challenges that each provider might address differently. When going multicloud, take advantage of “Best of Cloud” as well, leveraging the optimal feature sets from each provider that makes sense for your business.

Ultimately, if you’re not moving toward building a cloud ecosystem of microservices and applications, then you’re likely to fall behind your competitors. Before you get started, consider these four principles for building a best-in-class multi-cloud strategy.

Understand The Accordion Thesis

I use a metaphor affectionately known as the “Accordion Thesis” that Donnie Berkholz created (but never seems to talk about). IT is like an accordion and at any moment, there are parts of it that are expanding and parts of it that are contracting. The contraction is standardization, where all diverse choices are gradually squeezed down to a single standard (like the 19-inch server rack); whereas, the expanding parts are the innovations, such as machine learning, chatbots and AI. On the innovation side, your organization needs to be able to select and experiment with an infinite number of choices. The trick in managing IT is understanding where you’re standardizing and where you’re innovating, and to try not to standardize on the innovation side or innovate on the standardization side.

IT is like an accordion and at any moment, there are parts of it that are expanding and parts of it that are contracting.

The hardest part for most IT organizations is the “Fat Middle,” where it’s unreasonable to try and force a single standard choice, but where a plethora of choices is just unnecessary overhead. Most healthy businesses can tolerate two to six choices within each category, for example having both SQL Server and PostgreSQL available.

You can use the Accordion Thesis to inform “Build versus Buy” decisions as well. It can also be helpful for avoiding one of the greatest business risks: analysis paralysis. Do pilots, learn things, but have a bias towards building cloud native applications or microservices that will facilitate innovation, and leaning on standardized services provided by the major cloud leaders.

Take Control of What’s Already in the Cloud

Oftentimes when I connect with a company’s application developers, they say, “We need to go fast, and we need a platform to do microservices and we don’t care where it runs — that’s IT’s problem.” Whereas IT says, “We’re trying to get the lines of business back into our house. If we give them a platform, they’ll use it, instead of whatever this mix and match of things we won’t be able to manage.”

All of the Fortune 500 companies are using the public cloud, but most likely are not using it strategically or even on purpose. Much of this use is rogue lines of business, such as applications that the marketing team utilized because they wanted to move fast without informing the rest of the organization. Part of your cloud strategy is taking control of the ways you’re already using the cloud, and you may not know it. As the number of applications continues to expand geometrically, you’ll find it harder and harder to “get your arms around” the operational footprint of this sort of tactical ‘mix and match’ approach.

Part of your cloud strategy is taking control of the ways you’re already using the cloud, and you may not know it.

Build Your Own Ecosystem, Don’t Depend on Others

Building a “multi-cloud strategy” around a single cloud provider is like writing a standard with only one implementation. History is littered with examples like Quicktime: A monstrosity of video encoding, Quicktime had all these secret assumptions within its implementations that weren’t part of the standard, so the MP4 file was a trainwreck.

The more you’ve built against one cloud provider, the more likely you’ve inadvertently embraced a lot of -isms of that provider around things like storage, authentication layer, and access or network topologies that are not portable when you shift to a multi-cloud approach. The sooner you adopt a multi-cloud strategy, the less you’ll have to rework to make it possible.

Don’t forget: service brokers are your friend. Once you’ve identified the differentiated features and services you want to take advantage of (your “Best in Cloud” choices), you can bind them to your applications using a system broker. Imagine a service broker like a fund manager: it has access to all the different options and connects them together for you. This ecosystem is what will differentiate your business’ innovation, enabling you to create additional applications that take advantage of best-in-class features from leading cloud providers.

Don’t Conflate The Present With The Future

Another reason to diversify your portfolio: you don’t know what the future holds. I remember when Google was completely unfundable. In 2000, people thought the space was so crowded that “it was finished” when up against leaders like Altavista, Lycos, Yahoo! and Excite. Today, there is a similar — albeit misguided — implicit assumption: “Cloud is done because the major players are here.” That’s like saying we’re going to bet our company’s future on Friendster.

Just because AWS was there first, and has tapped into a decade of pent-up demand, it’s foolhardy to believe AWS will always be the market leader simply because they are today. When you adopt a standard that has at least two vendors, then you protect yourself to some degree against the unknown.

Of course, your engineering team may have some resistance to a multi-cloud approach because they assume there is upfront work to learn a new cloud’s commands. This may seem obvious to some, but the languages of Microsoft Azure, AWS, or Google Cloud are like romance languages: they’re all very similarly rooted. There are minor changes for each provider, so this shouldn’t be a major hurdle, or, you can use Pivotal Cloud Foundry which automatically translates between these cloud infrastructure providers.

When you adopt a standard that has at least two vendors, then you protect yourself to some degree against the unknown.

There’s a reason that the top banks, auto-manufactures, telecoms and other Fortune 100 companies are all adopting multi-cloud strategies: innovation is key to their success. The speed of innovation is now more paramount than ever, especially given that competitors have a lower barrier for entry with the reduced cost of outsourcing infrastructure.

If you want to retire comfortably, make sure you’re laying the foundation. Invest your resources across the right cloud providers and build on a platform that will sustain your future.

Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced and incorporated continuously through development and innovation, because good software is never finished.


Diversify Your Cloud Portfolio or Bank on Failure was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.

About the Author

Joshua McKenty

Entrepreneur and technologist Joshua McKenty works with Fortune 100 customers who seek to transition to a cloud native architecture, and with Pivotal’s Cloud Foundry team to bring new features and functionality to Cloud Foundry-based products, the industry-standard enterprise platform for the cloud era.

More Content by Joshua McKenty
Previous
How Crunchy Data Closed the Enterprise PostgreSQL Gap - All the Way to Cloud-Native
How Crunchy Data Closed the Enterprise PostgreSQL Gap - All the Way to Cloud-Native

Next
Announcing Spring Cloud Data Flow 1.2: Unified Service for Event-driven, Streaming, and Batch Data Pipelines
Announcing Spring Cloud Data Flow 1.2: Unified Service for Event-driven, Streaming, and Batch Data Pipelines

Spring Cloud Data Flow 1.2.0.RELEASE is now generally available. Composed Tasks, Real-time Metrics and Moni...

×

Subscribe to our Weekly Newsletter

!
Thank you!
Error - something went wrong!