ATT has been a leader in what we could call transformation, and we recently had a number of stories about its adoption of Airship, via a deal with Mirantis. This follows on an AT&T blog on the topic last May. There are a lot of things about this deal to like, but there’s not been a whole lot of ink spent on describing what Airship does, or could do. I want to try to address that here, because Airship is related to the broader issues of transformation and carrier cloud.
In a blog last week and one earlier this week, I talked about some technologies to virtualize networks by converting fixed devices into software instances, or by framing networking within a Kubernetes model (SnapRoute). We can see virtual networking, in a sense, as a sliding scale from virtualizing network elements (DANOS, 6WIND virtual router) through virtualizing network elements and topology (DriveNets) to virtualizing network services (SnapRoute). We can visualize Airship as most similar to the last of these.
Airship is a project of the OpenStack Foundation, aimed ironically at providing a strong framework for lifecycle automation in container environments. The container focus may seem ironic, given that one of the goals AT&T has for Airship is a replacement of the classic virtual-machine (VM) framework that OpenStack has been promoting from the first. The project includes Kubernetes and Helm, and its goal is to provide what AT&T called an “under-cloud platform” (UCP) using Kubernetes on top of bare metal, and OpenStack Helm (OSH) on top of Kubernetes. You can also make this configuration work on top of VMs instead of bare metal, but AT&T’s goal seems to be to go right to Kubernetes.
AT&T’s blog touts this as “delivering a unified, declarative and cloud-native way for operators to manage containerized software delivery of cloud infrastructure services”. The “unified” part seems to reference the fact that Airship creates a single operations environment. “Declarative” means that like Kubernetes overall, Airship defines a goal-state or end-state using parameters (YAML) and the software then works to achieve and maintain it. “Cloud-native” is a bit harder to interpret, but I take it to refer to the fact that containers are the logical way to deploy microservices or other small logic pieces that cloud computing in native form would favor.
In my view, though it’s not stated explicitly by AT&T, the goal here is to create a carrier cloud framework. If all AT&T wanted to do was deploy traditional VNFs in service chaining applications, there’s no reason why VMs wouldn’t have worked. As I pointed out last week and in an earlier blog this week, if you virtualize devices (physical network functions or PNFs in the NFV lexicon) you tend to create traditional networks by non-traditional means, and the application of carrier cloud to things beyond NFV isn’t about creating networks at all, but rather about creating experiences. In that light, carrier cloud would treat traditional network services as a class of experience to be created on an experience-centric platform, not a translation of appliances (PNFs) into software (VNFs).
What AT&T is doing seems to center on getting Mirantis to join the ONF and Airship project, and then doing some code exchanges to flesh out Airship to be more in line with Mirantis’ Cloud Platform (MCP). I’m showing the architecture in the figure below, from AT&T’s white paper on the topic.
The challenge for me here is interpreting exactly what mission Airship is supposed to be supporting. You’ll note that ONAP (derived from another AT&T project, ECOMP) is noted as a “consumer” of the Airship platform, meaning it sits on top like applications. That suggests to me that Airship is an abstraction of the cloud (OpenStack calls it part of the “Network Cloud” initiative). Besides OSH (Helm) and Kubernetes, Airship includes nine other open-source components (some of which relate to document management), and so you could rightfully call it a form of “Kubernetes ecosystem” for the carrier cloud.
The figure above also shows “VNF” as a consumer of Airship, which to me suggests that AT&T is looking at containers as the mechanism for hosting VNFs, further leading to a focus on “carrier cloud” versus “NFV” in a specific sense. As I noted in the two earlier blogs on white-box and virtual routing, there are some data-plane activities that probably require a customized platform rather than a general resource pool. VNFs consume the same Nova/Neutron framework as before, meaning that they still use OpenStack, but the hosting maps to containers and Kubernetes.
Anything that moves operators toward carrier cloud instead of NFV Infrastructure is a good thing, but Airship has its issues. My own concerns about Airship arise from its very conception as a way to map OpenStack to containers. In the figure above, Kubernetes is a kind of parallel/orthogonal element to OpenStack’s Nova/Neutron. This does in theory allow you to continue to use OpenStack to deploy VMs, but that’s not the stated goal AT&T has for Airship. Why, then, use a VM-centric strategy to deploy containers when you’re using Kubernetes too? Why even have ONAP in there for lifecycle management?
One clear problem here is the figure itself. We saw with the NFV ISG’s E2E architecture block diagram, which they asserted was just to illustrate a functional relationship, how easy it is to let explanatory drawings become architectural models. You don’t build cloud applications, services, or infrastructure from monolithic blocks, but it’s hard to depict functional relationships the way the cloud would implement them. We thus fall into an illustrative diagram becoming a guideline for implementation, and implementation of that diagram breaks our original goal of cloud-native.
The easiest interpretation of the figure, in NFV terms, would be that Airship’s effect is to build a kind of NFV Virtual Infrastructure Manager (VIM). This would abstract infrastructure for NFV using containers, but would also present an abstract hosting option for the broader mission of carrier cloud. The problem with that is that Kubernetes is shown under ONAP, which means that ONAP is presumed to be “orchestrating” and providing “lifecycle automation”. That would seem to diminish the role of Kubernetes in doing that, and that would be bad because the cloud community is making Kubernetes (more properly, the Kubernetes ecosystem) into the best overall framework for lifecycle automation.
I think the Airship concept, the “Network Cloud”, is a really good one, and it might well even be essential (in thought if not necessarily as a unique implementation) for carrier cloud to succeed. However, I’m not sure that AT&T is realizing its potential fully. What the AT&T vision surely does is to create a fairly concrete barrier between what could be called “hosting” and what could be called “service”. In the sense that an intent model naturally cedes the SLA management of a given model-element to processes within that element, AT&T has made a logical choice. In the sense that NFV from the first tried to sustain current device-centric management practices, AT&T seems to have made hosting into a virtual device. But more could be done.
If AT&T or any operator really believes in transformation, they have to believe in selling experiences and not just connectivity. There is still too much connectivity in their thinking, and that’s true even with Airship. Where is the link between the Airship framework and true cloud experiences? It should be easy to find, if Airship is really a complete solution. So yes, AT&T has literally led the world in technologies to support operator transformation, but that doesn’t mean that they’ve provided the complete solution. I’d like to see them go further.