Are cloud standards a bright new horizon, or just pie in the sky?

For many financial services cloud users, the ability to port data and workloads seamlessly from one public cloud to another and make applications interoperable, insulated from the work of dealing with individual infrastructure, is a kind of utopian dream. This flexibility gives subscribers the power to negotiate terms with providers, negating vendor lock-in. And regulators, particularly in the UK and EU, are pushing for a multi-cloud world to ensure that critical data is not lost and critical functions are not disrupted by some sort of catastrophic disruption of services.

The only way to achieve such a vendor-agnostic world is through the widespread adoption of standards for interoperability, migration, and data security. But Software-as-a-Service vendors say that wider standardization of cloud is a pipe dream—or at least still in its very early stages—and that even if it were possible, 100% standardization across all cloud services may not even be a desirable state to achieve.

Standard outcomes

That’s not to say that cloud standards don’t exist at all. In cloud computing, there are “de jure” standards, created by a formal body through a recognized process. The US National Institute of Standards and Technology, for example, has developed definitions for cloud-related terminology, and models for implementing cloud tech.

But the standards that form the foundation for how DevOps professionals go about their jobs are known as “ de facto” standards—they haven’t been through any formal process, but they have achieved widespread adoption. In the cloud world, de facto standards include software like Docker and Kubernetes for packaging and running containers, or Postgres for relational database management. These technologies are often nurtured in the open-source community.

Mark Schlesinger, senior technical fellow at Broadridge, says cloud standardization is in its very early stages. “So if a customer wanted to standardize their tech stack and have it work as seamlessly as possible across multiple cloud providers, they would in today’s world for the most part have to architect everything around the open-source community,” he says.

Open-source development of cloud standards works through organizations like the Cloud Native Computing Foundation, a sub-foundation of the Linux Foundation that was formed in 2015. The CNCF bills itself as a vendor-neutral home for many of the world’s fastest-growing open-source projects, including Kubernetes, the hosting and operational control of which it took over from Google. 

The CNCF’s 450-strong, blue-chip membership is indicative of how widely this software is used and how important its development is to major enterprises. Members include the major cloud platforms Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform, tech giants like SAP and VMWare, Fortune 500 companies„ financial firms such as Fidelity Investments, and data giant Bloomberg.

Sticky services

But these widely-used standards don’t amount to a fully vendor-neutral environment.

“The utopian vision is being able to insulate yourself from the details of what that individual cloud provider offers and to get to the point where you can say, ‘OK next week we’re just going to move to Google Cloud Platform. And we don’t have to make any kind of changes at all to any of our software, we can just literally point it at a different environment and off we go’,” says Chris Brook, co-founder and head of platform engineering at Finbourne, which offers investment management software solutions.

Technology like Kubernetes and Docker do offer this “utopian” experience to a degree, Brook says.

“If providers all have the facility for me to run Kubernetes on their cloud platforms, then theoretically, I can just pick up my workloads and move it elsewhere if I get a better commercial offer. And that doesn’t cost me anything. So we can get some diversity and negotiate better commercial deals with the providers, and there’s a bit more price competitiveness between them,” he says.

Andreas Burner, chief innovation officer at SmartStream, says that such a utopia could encourage compatibility between different solutions and collaboration between previously competing providers to learn from one another and built better, unified offerings.

“It’s easier for our journey to walk together towards a full cloud environment,” he says.

But the fact is that cloud service providers are “sticky.” As highly competitive companies, they want to differentiate their offerings and build tech that is fuller-featured than its open-source analog and those offered by their peers.

“Why is Amazon different to Microsoft and Microsoft different to Google? They differentiate to get clients, and that is all around innovation. That’s the commodity. They all have good hardware, they all have good networks, they probably have similar pricing models when it all comes down to it—that’s not the differentiator. But their platform services and their app development services—these are incredibly different across the cloud providers…. these are what make a difference to a client,” Schlesinger says.

Therefore cloud standardization is a pipe dream, he adds. “I don’t see any one of these cloud providers giving that up to say, Let’s just paint it all blue and we are all the same cloud provider. At that point, there is no differentiation between them.”

Brook agrees. “Philosophically, standardization is brilliant. The challenge with standardization is a technical one: if you want to standardize something, you end up standardizing to the lowest common denominator between all the things that you want to interoperate,” he says.

Finbourne was built to be cloud-native, and has run on AWS since Brook helped to found the company in 2016. Thus, the vendor has invested a great deal of time and effort in building its technology on AWS, Brook says. “We’ve tried all the way through that journey to avoid being too tightly coupled to anything proprietary that they have, but inevitably there is some specific software that we’ve had to write to be able to plug into that layer underneath,” he says.

Brook says Finbourne used to use Postgres. Most cloud providers support the system, but some have their own versions. AWS’s is called Aurora, which is a cloud-native database management system that has compatibility with PostgresSQL and MySQL databases.

“Aurora has some benefits and extra features that are better than the out-of-the-box Postgres. And we liked those capabilities. For us to switch over to Aurora was very easy: it’s literally like you just toggle a switch in one of the AWS interfaces,” Brook says.

And that’s “sticky”, he adds: “If we wanted to pick ourselves up and move to Azure, we would have to unwind that, and any dependencies would be taken upon those extra features.”

Limitations

Schlesinger says that standardization might break vendor lock-in, but it would be limiting also. “You’re not leveraging the cloud-native tech stacks that these large public clouds offer, which are differentiators and provide much more innovative solutions and a much more manageable process from a technology standpoint.”

In addition to being limiting, it’s also costly: Multi-cloud often ends up being more expensive than using one provider, Schlesinger adds.

“How infrastructure is provisioned at Google is a little different to Amazon, and a little different to Microsoft. So you have to deal with all these little differences before you deploy your tech stack. It creates additional tech overhead, and it’s harder to manage in terms of operability across the multiple cloud providers,” he says.

Also, using multiple cloud providers means that you’re not taking advantage of the incentives that these scale-based businesses offer to customers who avail themselves of multiple services.

“Financially, if you’re using, say, two or three different cloud providers, you’re not getting the purchasing scale as if you were with a single provider. If you use more resources from a cloud provider, your unit costs go down over time.” Schlesinger says.

And the cloud standards have their limitations, even as standards: there’s no such thing as complete uniformity between them and between the organizations that use them, meaning that at some point, proprietary intervention is required. Kubernetes, for example, Brook says, while abstracting away a lot of detail for users, and hiding the bespoke integrations under the hood of the cloud providers, still can’t hide everything.

Security models and policies differ substantially across cloud providers, for instance, requiring users to write code that “speaks” AWS or Azure or GCP to provide user authentication.

“We see the open-source community and non-profits like the CNCF trying to drive these bits of technology that run on all these platforms and interoperate between them,” Brook says.

“If you write your software to run on these bits of tech, it’s much easier to pick it up and move it somewhere else. But inevitably, there’s always a point where it’s not 100% standardized, and you have to write some kind of bespoke code to make it work”.

Crisis of confidence

It may be that while some anxiety pervades about vendor lock-in among both regulators and customers of cloud providers, financial services users are gradually turning away from the concept of a multi-cloud world and by extension, the belief in common standards.

Anthony Caiafa, chief technology officer at SS&C, says there is some talk of cloud standardization in the industry, but it’s a buzzword. “What’s the difference from AI or blockchain four or five years ago? Everyone had to have an AI story. Everyone had to have a blockchain story. Everyone had to have a devops and cloud story. But do you hear that about that so much anymore? It’s just something new that is trending,” he says.

Anything new that wants to be put to work in a conservative, critical industry like financial services needs to be demonstrably useful and reliable, Caiafa says.

“Financial services don’t have a ton of time to have pie-in-the-sky things going on. It must be proven, it must work very well. we have trades that we have to make sure are executing, we have customers that rely on us. Where people were going with Kubernetes, packaging up that kind of tech to make things cloud-agnostic, and what Hashicorp was doing with [Kubernetes competitor] Nomad—I think those efforts are great. But you talk to some low-level engineers, and they say, ‘We’re just trying to solve the same problem we’ve always had with a different buzzword’,” Caiafa says.

Schlesinger says it’s really the auditors and regulators that are driving the standardization conversation. If enterprise cloud users architect their solutions properly, considering availability zones in different geographies, their cloud should be as resilient as if they had a multi-cloud strategy.

“There’s a concern if you put all your eggs in one basket of one cloud provider. But the reality is, if you architect your application properly, and you select a prominent cloud provider, you can have the same level of resiliency and scale as if you’re in multiple cloud providers. It’s all about your architecture at the end of the day,” he says.