Companies naïve enough to think about moving to the cloud with just one partner may regret it, warns database expert Martin Gaffney, Area VP EMEA of Yugabyte.
The Bank of England is planning tough new rules on IT resilience that stress that CIOs take steps to avoid cloud “concentration risk.” This should be ringing alarm bells across all enterprises, no matter what sector they operate in.
This 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 IT leader needs to know and follow the Bank’s guidance on.
Why should you care? Because concentration risk is what you get when you combine all the disadvantages of vendor lock-in with the serious risk of operational failure. This is clearly not to your advantage.
The Bank’s warning came as part of three new draft supervisory statements released in mid-April. These statements raise fears about cloud outsourcing and detail why cloud suppliers need to be kept on a tight leash. 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. Essentially, this becomes detrimental ‘vendor lock-in’.
The Bank of England fears that if banks become dependent on a small number of dominant outsourced or third-party arrangements which are difficult or impossible to substitute, this could give rise to systemic concentration risks over time. 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 that putting all your eggs in one cloud provider’s basket is not sensible operationally. Something many senior enterprise executives are all too aware of.
This is essentially good old-fashioned vendor lock-in. Being locked-in puts you in a worse negotiation position. If you’re in a regulated industry like financial services or pharma, being tied to a single cloud vendor could put you at risk of operational failures that can push you out of compliance.
In other words: you’re actually worse off than you were on-premise—if not functionally, then as a business. But, if you say that to a large cloud provider, they won’t necessarily agree.
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 significant sums to make their services as attractive as possible. 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. No wonder they want to see a return on this investment!
The main cloud trio will encourage you to adopt all that they can. 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 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 ‘one throat to choke/single supplier for everything’.
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 anywhere else.
It also means that the advantages of cloud eventually ebb away—especially your choices. 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 is likely to be an expensive and risky business, with a chunk of business disruption.
The cloud leaders know that you could go elsewhere, but that you’re unlikely to put yourself through that pain. When it comes to renewal, those original compelling discounts become a thing of the past. Over time this puts them in a far stronger negotiation position when it comes to SLAs, contracts, or customisations that benefit them.
Another reason to support multi-cloud is future-proofing. If 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.
Martin Gaffney
Area Vice President – EMEA, Yugabyte
Enter Multi-Cloud
Many businesses still seem content to progress down the single cloud provider route. However, if you look around, this concentration risk has become a red flag for larger organisations.
Today, any forward-thinking c-suite executive will be looking for more than one cloud provider. Even if they rely on one or two popular 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 important term to consider 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 is going multi-cloud, mid-range organisations need to balance convenience and economies of scale with the risk of operational rigidity. With multi-cloud, you put different parts of your workload on different vendors, for example, like all your CRM on Salesforce in Amazon, your ERP on Azure, and your mission-critical transactions on YugabyteDB.
Going multi-cloud gives you choice, and enables you to:
a) Migrate if you need to
b) Select the right platform for different applications (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 solid guarantees of high availability on a global basis
This is all positive. However, a key factor in the decision to choose a multi-cloud strategy 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 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.
This option should be a key consideration for your enterprise IT architecture team when they consider building your new data layer. You might want Snowflake here doing this job for you, a graph database over here doing another, maybe a data lake running Spark, and another great open source software for something else.
Adopting a multi-cloud proposition ultimately comes down to maintaining your independence and flexibility. 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-premise, or in a private cloud a smaller vendor creates 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.
But, how strong a renegotiation position do you think you’ll be in next year if your jolly 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 impacted by this new lock-in. Exactly what you were trying to avoid.
Another reason to support multi-cloud is future-proofing. If 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. So, you want to try and unify the offering. You may end up severely out of pocket 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 their database and change cloud provider. This pushed the eventual cost of their acquisition up. 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 the architectures were so incompatible.
This company made life difficult for themselves by not being flexible. If they could just 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 in.
One Database Won’t Meet All Your Needs in the Data Layer
Putting all this together, it’s no surprise 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 as you need to support different workloads, with different requirements and demands.
Organisations have to accept that you can’t make a single cloud vendor decision and then live with it forever, for everything. Executives also need to accept that once you start on the digital transformation journey, moving your IT into the cloud, you should design for that complexity to ensure your new cloud business operates 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 concentration risk.
ABOUT OUR GUEST WRITER
Martin Gaffney
Area Vice President – EMEA at Yugabyte
Martin is a specialist sales executive for US enterprise software companies wishing to enter the EMEA market place. Long and incredibly successful track record of being either first-person-on-the-groud or member of the very early EMEA team in stand-out companies such as Netezza, ThoughtSpot, Sequent, Tivoli and now, Yugabyte. Martin also possesses a 7+year hands-on experience of co-founding a UK-based enterprise software firm, Volantis Systems, from 2000-2007.
