Companies naïve enough to think about moving to the cloud with just one partner may regret it, warns database expert Martin Gaffney, Area Vice President - EMEA at Yugabyte.

The Bank of England is planning tough new rules on IT resilience that stress that CIOs avoid cloud “concentration risk.” This should be ringing alarm bells across all enterprises, no matter what sector they operate in.

 The news might have thrown those of us outside financial services a phrase we’re unfamiliar with; “concentration risk.” But, this term is one that every internal IT leader needs to know and follow the Bank’s guidance on. 

Why? Because concentration risk is ultimately what you get when you combine all the disadvantages of vendor lock-in with the serious risk of operational failure. I think we can all agree, that’s not to your advantage.

The Bank’s warning came as part of three new draft supervisory statements released in mid-April. These raise fears about cloud outsourcing and detail why cloud suppliers need to be on a tight leash. For example, the guidance notes that the technical complexity of some technologies provided by third parties, coupled with the fact that they are constantly evolving, “can make it difficult for the boards and senior management of financial market infrastructures to understand and manage relevant risks.”

It also warns that the cloud can be “heavily dominated by a small group of third parties, may limit FMIs’ or participants’ ability to exit outsourcing arrangements without incurring significant costs, and/or disruption, and require significant resources and time (‘vendor lock-in’)”. 

Finally, the Old Lady of Threadneedle Street fears that if banks become dependent on a small number of dominant outsourced or third-party arrangements which are very difficult or impossible to substitute, this could, over time, give rise to systemic concentration risks. This means that any “major disruption, outage or failure at one of these third parties could create a single-point-of-failure with potential adverse consequences for financial stability”.

Let’s be clear: the Bank is not saying that moving to the cloud per se is risky and should be avoided. Moving to the cloud is what many companies want (and need) to do to stay competitive. But, it is saying—and what many enterprises have quietly been figuring out for themselves over the past few years—is that putting all your eggs in one cloud provider’s basket is not very sensible operationally.

At the end of the day, this is just good old-fashioned vendor lock-in. If you are locked-in, you are in a worse negotiation position. If you're in a regulated industry like financial services or pharma, you’re also running the concentration risk BoE’s is warning about, giving you less control of what data is where, and what's accessible to whom.  

In other words: you’re actually worse off than you were on-prem—if not functionally, then as a business. But, say that to a big cloud provider, and they will stare at you blankly. 

Running core services on Aurora means you must stick with Aurora

It’s not that they don’t hear the words you’re saying, they just disregard them. They don’t see concentration risk; their whole model is about wanting ALL of your business—all your apps, all your databases, all your data. In their view this can and should all live on their cloud. 

These firms are investing big bucks to make their services as irresistible as possible. For example, Google's new Transatlantic Dunant submarine cable system pumps your data at 250 terabits a second across the Atlantic. This is the final link in a web of fibre optic links and subsea cables for all 24 Google Cloud Platform regions and 100-plus Google Cloud CDN locations.

The main cloud trio will encourage you to sign on the dotted line to take advantage of all their stellar investment. They will make it as easy and tempting as possible, and will offer all manner of excellent management capability, tools, application software of their own to “help” you, as well as very tempting pricing. Until very recently, this was an argument that landed very well with many CFOs; we want to go cloud because of the capex to opex argument, we can get this outsourcer to do everything we need, and there’s the convenience of that ‘one throat to choke/single supplier for everything’ angle. 

That made sense for a while. But, this is the same vendor logic that IBM used to live and grow rich by: by providing you everything, you have no need to look at anyone else. 

This means that the advantages of cloud soon start to ebb away—especially in terms of choice. As soon as you start running core services on something like Amazon Aurora you are stuck with them, as you can't get an Aurora database from someone else. You can't move providers without rebuilding and reengineering applications. Even if you haven't 100% locked yourself in and could migrate, it's still going to be an expensive and risky business, with a lot of possible business disruption. 

The cloud leaders know that on paper, you could go, but you're very unlikely to really put yourself through the hassle. When it comes to renewal, the original compelling discounts are a thing of the past. Over time they are in a stronger and stronger negotiation position when it comes to SLAs, contracts, or customisations that benefit them.

Enter multi-cloud

Many businesses still seem happy to go down the single cloud provider route. However, if you look around, this concentration risk has become a red flag for larger organisations. 

Today, any CIO worth her salt will be looking for more than one cloud provider. Even if they rely on one or two great Software-as-a-Service products only available on Azure, they will want to have in-house apps that they have built, maintain, and continue building on Google Cloud.  

Another term I need to throw at you is multi-cloud—the practice of keeping your options open and avoiding vendor lock-in by embracing more than one cloud provider, even at a global level. 

If the enterprise at large is going multi-cloud, mid-range organisations also need to balance convenience and economies of scale with this same risk of operational rigidity. With multi-cloud, you will be putting different parts of your workload on different vendors,  like all your CRM on Salesforce in Amazon, but your ERP on Azure. 

With multi-cloud you can: 

a) migrate if you need 

b) have horses for courses for apps (perhaps based on what makes most sense on a geographic data regulation or local vendor support capability basis) 

c) operate and interoperate between multiple vendors to give you real guarantees of high availability on a global basis. 

Sounds great (and it is). But, a key factor in that decision from a technical point of view is whether it’s practical. The cloud operator wants to give you a key component of commercial data processing - a performant and reliable database. If you choose Google Spanner or the SQL stack on Azure, you may worry that you can’t really go multi-cloud as it’s notoriously difficult to get proper business databases running in the cloud.

Just like the one cloud fits all uses narrative, that’s no longer as true as it once was. You can now work to achieve multi-cloud independence and avoid committing to the proprietary database of any one cloud provider. That’s because a multi-cloud business database built on SQL as an open standard is out there if you want to use it. A PostgreSQL compliant database, such as YugabyteDB, is an excellent candidate for doing just that.

That might be worth informing your enterprise IT architecture team of when they begin to think about building your new data layer. You might want Snowflake here doing this good job for you, some graph over here doing another, maybe a data lake running Spark and other great open source stuff for that. 

The sine qua non of such a proposition has got to be vendor independence. You can decide what you want to put into whatever data engine makes most sense for your apps, wherever you want. That could be on-prem, or in a special private cloud a smaller vendor spins up for you, and so on. 

Even better—multi-database

Sounds like a lot of work? Maybe it is. Maybe it does seem easier to get one cloud to do everything. 

How strong a position do you think you’ll be in to renegotiate an equally great deal next year if your cheerful one-cloud-for-everything partner knows you are reluctant to entertain other options? When you've got more and more systems, processes, and databases on their cloud, it will become increasingly difficult to migrate.

Ironically, the big drivers your CFO loved about the original cloud migration business plan, reduced cost, is now exacerbated  by this new lock-in. Exactly what you were trying to avoid. 

Another reason to support multi-cloud is future-proofing. Say you acquired a competitor stronger in a new geography to expand your business, but they're on Google and your main platform is Amazon. You cannot force those customers to move to Amazon, so you want to try and unify the offering to them. But, you may baulk at the risk of running two clouds in parallel if you can’t see a way to do multi-cloud. 

I know of an M&A situation, where the perceived risk forced the acquirer to change database and change cloud provider. This pushed the eventual cost of their acquisition up way higher. The buying company had a database solution irretrievably locked into its architecture, but they had to operate in parallel. They couldn't merge the services because they were architected so differently and incompatibly.

This company had made life difficult for themselves by not being flexible. If they had been able to run on Google, they would have been able to expand more easily. If they’d been on open SQL, they wouldn't have cared what the cloud provider was and could have just picked the best vendor for the geography they were moving into. 

One database won’t meet all your needs in the data layer 

Putting all this together, maybe we shouldn’t be surprised that the Bank of England has started to sound the alarm about over-committing to one cloud partner. 

After all, we know that one database can’t meet all your needs in the data layer. You want to support different workloads, which will have different requirements. 

You have to accept that you can’t make one cloud vendor decision and then live with it forever, for everything. You also need to accept that once you start on the journey of digital transformation and moving your IT into the cloud, then you should design for that complexity in order to make your new cloud business operate in a proper digital, multi-database, multi-cloud fashion.

Or, to put it a way the CFOs will like:

We can get what we want from the cloud, but in a safe way that ensures our data stays in our control.

That ought to help them concentrate on strategies that avoid long term cloud risk.