If abstraction is the key concept in virtualization, then you might wonder why it’s not been played in the market explicitly. It has, in multiple forms, but not in a way that linked explicitly to the abstraction concept. Now, though, Microsoft has launched Radius, a “cloud-native” application platform that abstracts the stuff it runs on, even to the point of supporting rival cloud providers. What’s happening here may well be linked to both Microsoft’s specific cloud strategies and the pressure on cloud growth. And other stuff as well, as we’ll see.
From the first, public cloud services have been offered at various levels, reflected in names that all ended in “-as-a-Service”. Infrastructure as a service, or IaaS, is the form of cloud service that abstracts hardware and so delivers a virtual machine. Platform- and software-as-a-service abstract at a higher level, and the level of abstraction an aaS offers determines how much work it is to support it and how difficult it is to translate it from one cloud or data center environment to another. In theory, you could run either PaaS or SaaS services on anything as long as the underlying implementation was mapped to the API set that exposes the “service” involved. The great majority of these beyond-IaaS services weren’t aimed at being portable, only at facilitating development and use.
Radius is different, because it really aims first at portability and only then at facilitation. It uses a set of services called Recipes that control the mapping of Radius platform APIs exposed in the application direction to the facilities on which the applications would run. The Recipes can be changed without changing the code of the applications that depend on them, and the new ones can map that code to new environments. This is what creates portability. The presumption of Radius is that the applications are containerized (which many equate to “cloud-native”, and that’s why I used the term in quotes earlier), so an application in Radius is a set of container images and the associated Recipes that match where you can put the combination.
It’s not just a question of the differences in basic deployment features between data centers and all the various public clouds. Radius can accommodate different application resources like databases, and map those to explicitly deployed (container image) elements or to cloud resources/services. Thus, Radius is really powerful in its ability to automatically match what applications see as resources to the resources of various deployment environments. To many, it realizes the principles of DevOps by codifying the separation between the “Dev” and the “Ops” parts, then uniting them with Recipes.
There’s a lot we could say about the technology of Radius, but it doesn’t really belong in a blog like mine. What we’ll do instead is return to the “why” of Radius, the specific set of conditions that would induce a company like Microsoft who’s arguably the leader in enterprise cloud computing to encourage portability.
The classic view of cloud computing, at least up to 2023, was that “everything moves to the cloud”. If you presumed that to be true, then data centers go away and so does any need for portability except for companies who insist on multi-cloud deployments. Even for those companies, multi-cloud is often a decision driven by the need to use specialized facilities for some applications, facilities all cloud providers don’t offer. Sometimes it’s also driven by geographic distribution of users or resources. In either case, portability wouldn’t be a big factor.
What changed things in 2023 is largely the realization that everything wasn’t going to move to the cloud, and in fact that some things already moved were returning via “repatriation”. This is a validation of what was originally called “hybrid cloud” to express that applications were a hybrid of a front-end, user-facing, cloud component and a transaction-processing-and-database portion running in the data center. This meant that applications would perpetually have to balance between cloud and data center, and that some components might, for reasons of failover or scaling, migrate back and forth across the two. The same could be said for public clouds, because user experience with the cloud showed them that the front-end-user-focused nature of the cloud piece means that having a cloud outage could disconnect every user of a hybrid application. Multiple clouds could well be a better answer than retaining enough data center resource capacity to pull everything back in when the cloud part fails.
From the first, Microsoft was always more accommodating of the realistic front/back-end view of the hybrid cloud, but when IBM did a major hybrid cloud positioning and was rewarded with better sales and more cloud influence, I think Microsoft got the message. The smart thing to do was to reposition cloud and other assets to account for the direction the market was taking, before a player like IBM leveraged their own early lead and used it to gain cloud market share.
Radius makes Microsoft a formidable player, or perhaps a more formidable one given their lead in enterprise cloud. It might also be an essential part of their strategy to use Azure cloud services to integrate AI into a broader range of custom applications. While Microsoft isn’t likely interested in making their AI portable to other clouds, there is considerable concern over AI data security among enterprises, given that the most interesting AI applications would have to be trained on and operate on companies’ own data. The possibilities of linking data-center-hosted AI elements and cloud-AI services could be of great interest to enterprises.
It’s also possible that the Radius model could be the basis for richer platform services. For example, you could use it to create a model for real-time IoT/edge/metaverse services by building a set of intermediary application-linked APIs on top of Radius. Similarly, you could use this as the basis for feature hosting in the service provider space. Could it be the way that NFV should be moving? The current NFV “containerized network function” concept could be mapped to something like Radius, and that could perhaps obviate the need for some or all of the MANO functions.
This is a useful abstraction concept, the sort of thing I think is the way that “virtualization” and “the cloud” should naturally evolve. It will be interesting to see if other cloud providers follow along.
