There are some interesting things going on with Airship, an AT&T-promoted open-source project to deploy a virtualized hosting layer on top of bare metal. For one thing, it’s getting support from a major server vendor, Dell. For another, it’s closing a loophole in the overall vision of cloud hosting, and it’s addressing some issues that are particularly critical for carrier cloud. Finally, it just might be showing that AT&T is getting serious about a cloud-centric vision of its own infrastructure evolution.
Virtualization in hosting, in simple terms, is the creation of an abstraction between real data centers and applications or hosted features, so that deployment and operations for software can be standardized across a mix of hardware options and locations. This is how “the cloud” is built, but most of the focus of the cloud has been on how to build the applications and features. The abstraction piece has been taken a bit for granted, other than some catchily named initiatives like “infrastructure as code”. Airship was launched to fix that.
Airship is an open-source toolkit assembled from fairly popular pieces, including YAML, OpenStack Helm, Redfish, and Kubernetes. With Airship, it’s possible to declare a kind of portable virtualization layer, and map it to infrastructure when data center resources are augmented. For classic cloud data centers, where the hosting resources tend to be homogeneous and augmented incrementally by adding server racks, this isn’t a life-changing capability. Where it makes a lot of sense is in its application to edge computing or an expanding carrier cloud.
If my models are right and carrier cloud represents a potential for more than a hundred thousand incremental data centers by 2030, it would be madness to expect the operators to pony up all the money for a single massive deployment. What would happen is that data centers would be incrementally commissioned in areas where opportunities converged, at a pace that made business sense. However, all this discrete commissioning has to add up to collectivized resources, which is where Airship can help. Arbitrary edge data center plus Airship equals an added piece to carrier cloud.
There are two critical elements to the current Airship story. One is Redfish, a universal RESTful API and data model set that’s designed to deliver open management and abstraction to all the hardware elements of a server farm. Redfish lets a single set of management tools manage a variety of specialized hardware elements based on “class-based” management of things like disk drives or even specialty chips. The other is the notion of Helm charts as descriptors for software tool deployment and integration.
An Airship deployment links all the current cloud-native and container work, proceeding at what I’ve called a “dazzling pace”, to the necessarily earthbound data centers. Integration of the application-and-feature abstractions of things like cloud-native components or even NFV’s virtual network functions (VNFs) is facilitated if there’s a uniform set of properties defined for the abstract resources on which things run. Functionality is delivered from the top, but to realize it the resources at the bottom have to be organized into a common framework. NFV failed to do that in its specifications, and the result has been major integration (“on-boarding”) problems.
It’s the Helm charts stuff that sets Airship apart from what might be called “pod” or “abstract pod” strategies that create a pure hardware-layer abstraction. One thing the cloud work of the open-source community has shown us, particularly in the container, Kubernetes, and cloud-native space, is that the whole cloud-native software ecosystem is evolving almost faster than it can be documented. The cloud-native applications and VNFs don’t deploy onto hardware, but onto virtual hardware and through a set of changing middleware tools. Getting those tools deployed on the hardware is as necessary as getting the hardware abstracted. Helm is used not only to deploy services, applications, or features, it also deploys Airship and any necessary middleware. With Helm charts, Airship can deploy a complete platform for applications and features.
I think the most useful thing about Airship’s evolution, from a carrier cloud perspective, is its solidification of the concept of a platform on which services/features are run. In the age of the cloud, you don’t talk about “hosting” to mean “running on servers”, because there are a lot of pieces that have to be in place above the server, in order for things to run. The thing that carrier cloud needs is not the standardization of servers, or hardware, or even just “operations tools” but that whole platform. Otherwise, deployment of services will involve special integration, and deployment of new data centers will too.
The most problematic thing here is coming up with the makeup of that platform. Remember that Airship permits unified platform deployment, but it’s not a platform in itself. There are still a lot of moving parts that will have to be addressed, and as the concepts of cloud-native mature the number of these parts is going to explode. Operators may want to “collectivize” their vision of platform contents, but with early service priorities highly variable among operators, that will be difficult to do.
A close second, problem-wise, is describing the software environment that the platform creates, as a set of APIs that applications, services, and features can then rely on and be written for. Remember some of my early blogs, when I said that NFV really needed a form of platform-as-a-service API set? That’s true of anything that’s expected to run on a portable platform environment. You need to present a single, standard, model for application or virtual function integration, and until that happens you don’t resolve any of the on-boarding problems.
The abstraction centerpiece of virtualization has to adapt in two directions. It first has to adapt the hosting environment to present itself as a single, common, set of capabilities, lifecycle-managed in a uniform way. Then it has to present that common set of capabilities through a set of well-known and stable APIs so virtual functions and components can use them. Only then can those functions and components be altered to conform, and only then does a standard hosting platform map to standardized feature and service deployment.
AT&T could do some things to drive this process along. Obviously, they could work to define that standard service-facing API set. They could also work to make ONAP conform to the Airship platform framework, but in my view, ONAP has scalability issues that should be addressed first. In any event, ONAP is already looking at Airship. AT&T could even promote a rational view in the Common NFVI Telco Taskforce (CNTT), where they’re a member. So far, I’m not hearing much about a CNTT/Airship connection, except perhaps via ONAP.
Another interesting question is whether the Airship concept could spread. All cloud computing, but in particular hybrid cloud computing, has to deal with the issue of deploying a consistent platform on various data center resources, and it would be helpful if the service-facing aspect of that platform could deploy on the public cloud to create better application portability. This could be a rightful mission for Airship given that deploying public cloud services on carrier cloud infrastructure is a mission most operators are at least considering.
All this interest comes with some concerns, obviously. One is whether AT&T, having been the driver behind the ONAP design that lacks fundamental cloud-readiness, can take a positive cloud step. The difference here is that Airship is assembled from cloud-community technology, where ONAP was an AT&T development project from the first. I think that difference is more than enough to ensure Airship isn’t falling into the ONAP monolithic trap.
The second question is whether those necessary steps I outlined above will actually be taken. Having a way to do something doesn’t guarantee it gets done. There’s a lot of careful cloud-centric planning associated with the kind of future Airship enables. AT&T and other operators obviously have a mixture of cloud-thinking and cloud-opaque people, and we don’t know which group will contribute the most to the actual deployment of carrier cloud infrastructure. Remember that Airship is a loosely coupled toolkit, and “loosely coupled” means “human-integrated”. If the cloud-opaque thinkers get the nod, those humans may find they’re not able to play their role.
