Cloud computing: Why open standards is now the only way to build

Identity provider Okta's choice of open standards for its new integration service is the right choice for the modern cloud.
Written by Simon Bisson, Contributor

Steve Ballmer famously shouted "Developers, developers, developers," as he extolled the value of the Microsoft platform. Without third-party developers building applications on its tools, Microsoft would have just been another operating system company that appeared and disappeared.

Today, with cloud platforms vying to become the connective tissue of the next generation of the internet, Ballmer's call to arms would have been "Open standards, open standards, open standards."

Building on open standards, especially when it comes to key components of a modern cloud infrastructure, is essential. We left the world of proprietary dominance a long time ago, with much of the public hyperscale cloud built on open-source technologies. Even Microsoft has its own Linux distributions, one for cloud networking and one for secure edge devices, and there's significant industry presence in organizations like the Cloud Native Computing Foundation.

SEE: 20 quick tips to make Linux networking easier (free PDF)    

So we shouldn't be surprised at Okta's recent announcement that it's opening up its identity platform and making it a composable, event-driven service. For one thing, it's the appropriate design pattern for a cloud service, allowing users to consume as much of the service as they want. It's also a way of quickly integrating with those existing cloud platforms, using the same standards that they're shepherding through bodies like the CNCF.

One of the more interesting aspects of the Okta platform is its support for the developing CloudEvents standard, which aims to standardize the messaging protocols used by web services. Implemented as part of the Okta Hooks integration tooling, CloudEvents are used to send events into other applications. For example, when a user is added to an Okta directory, they're automatically added to the appropriate team Slack.

Building the code to consume and work with a CloudEvent is easy enough; they're supported by popular serverless programming environments as part of an event-driven programming model, and you'll even find support in publish and subscribe messaging services like Azure's Event Grid. There's support in low-code and no-code workflow-based integration tools, allowing anyone to build an integration end-point for Okta's identity tools.

There's an argument that open platforms lead to the democratization of development, and it's certainly possible to suggest that by using open standards like web hooks and Cloud Events, Okta is expanding the reach of its tooling beyond its traditional IT administrator audience. In fact it's bought a low code development platform, Azuqua, and looks set to repurpose it as the workflow backbone for its Identity Engine.

It's been interesting to watch Okta's transition from an IT-focused, single sign on service to full-fledged identity platform, and it's clear that open standards have played a big part in that transition. Part of that has been the arrival of open authentication standards like OAuth2, and the related development of web authentication frameworks that build on top of OAuth. Another aspect has been the move to passwordless environments, thanks to the FIDO community.

Must read

While Okta's move to open standards-based integration through Okta Hooks is driven by a need to integrate with existing software, it additionally provides a level of future-proofing that protects both Okta and its customers. Where an application needs a shim to convert open event messages to a proprietary format, all that's necessary is to build one that handles open formats; there's no need to build others if every integration uses the same message types. It's an economic win for everyone; Okta, it's partners, it's competitors, and the event consumer. With a common format, there's no need for competition at a message level; what matters now is the performance of the service being used. By removing an unnecessary differentiator, the result is an approach that drives everyone involved to be better, whether that's faster or cheaper or more integrations.

As we increasingly build apps by hooking together features and services from a host of cloud platforms, open standards like these reduce risk and increase interoperability. There's less lock-in, more flexibility, and more options for using off-the-shelf workflow and integration tooling. When you look at Okta's new tooling as a platform integration play that's intended to work across multiple clouds, its choice of open standards makes a lot of sense – and sets an example that more companies should follow.

"Open standards, open standards, open standards," indeed.

Editorial standards