Last week I attended the Open Infrastructure Summit in Denver, Colorado. The Open Infrastructure Summit is the new name for what was previously called the OpenStack Summit. The OpenStack Foundation (OSF) changed the name of the event to reflect their overall transition from providing support to one project (i.e. OpenStack) to providing support and governance to multiple open source projects, of which OpenStack is only one. Aside from that name change, all of the supporting infrastructure for projects have moved from the openstack.org domain to opendev.org.
For example, the OSF currently provides support for several unique and useful open source projects:
- OpenStack
- Zuul – Advanced CI/CD
- Kata Containers – Virtual machines as containers
- Airship – Declarative Kubernetes and OpenStack
- StarlingX – A Kubernetes and OpenStack based Edge platform
StarlingX
StarlingX (STX) is one of the five major projects under the OSF (I should mention here that I am one of the members of the STX Technical Steering Committee, and work with the project to help set direction. I spent a lot of time at the summit working with the STX community).
Plain and simple: StarlingX is an edge platform. You can run STX on a single server, two servers, or more. In my opinion, the most interesting deployment model is one (simplex) or two (duplex) servers. When you deploy STX you get a vertically integrated platform made up of both Kubernetes and OpenStack (in fact OpenStack is optional).
During the summit it became clear that it is time for some newer edge deployment models to move from paper to at least proof of concept if not higher. STX is in a unique position to help with that transition; to get edge models into production.
Interdynamix also participated in running a hands-on workshop for StarlingX. We had approximately 50 people deploying STX and exploring the platform, learning about how to install and configure STX in an All-in-one Simplex deployment. The workshop was a great time and we met people from around the world, all of whom were interested in what STX has to offer.
OpenStack – Going Strong in Telecom
From what I saw at the summit, OpenStack and related projects are still dedicatedly moving forward, continually making OpenStack a better platform for Network Function Virtualization (NFV). A good example is a presentation I watched on using Vitrage, Heat, and Mistral to auto heal NFV workloads. This required some additional functionality in Vitrage, but was not a massive change. That’s just an example of the continual, incremental improvement in OpenStack projects to support advanced NFV workloads.
Further, discussions with colleagues indicated that every level of telecom, from AT&T to the Tier 3/4 telecoms, either already have OpenStack or will be using it for their NFV infrastructure. This presents a huge opportunity for vendors and integrators to help telecoms going forward.
Telecoms Need Multiple OpenStack Distributions
The scale of Chinese telecom is unbelievable to many outside of China. During one presentation it was noted that a particular Chinese Communication Service Provider (CSP) uses five OpenStack distributions. To be fair, they are still in PoC mode in this particular example, but they will not be going into production without multiple distributions. One of the more interesting reasons as to why this is the case is that the vendors behind the OpenStack distributions do not have enough people–enough human resources–to support running the entirety of the CSP’s workload on their singular platform.
A dual vendor or multiple strategy is common in telecom. However, in my experience in the NFVi world, CSPs have not yet been able to deploy a dual vendor strategy for NFVi. This is something the OpenStack ecosystem will need to encourage and support.
Kubernetes and OpenStack
OpenStack and Kubernetes are at different positions in the hype cycle. OpenStack is moving nicely along the plateau of productivity, while Kubernetes is either rocketing towards the peak of inflated expectations or gently tipping down to the trough of disillusionment.
Kubernetes’ spot on the hype cycle has spun some people in the OpenStack community into somewhat of an existential crisis. To me, what this crisis has led to is an understanding that OpenStack may be best suited as a platform on which to run Kubernetes, especially in a bare metal context. In fact OpenStack may need to simplify in some capacity to ensure that it is the easiest and best place to run bare metal Kubernetes. Strangely, with this in mind, it may actually be Kubernetes that uses OpenStack (see the Metal3 or Ember projects as examples).
Conclusion
OpenStack and the OSF are doing what they need to do to keep things moving forward. Some of the existential fog around Kubernetes is dissipating and leaving behind new ideas and plans for being a good bare metal platform. On the surface, the OSF’s movement to support multiple open source projects seems redundant in the face of the Linux Foundation or the Cloud Native Computing Foundation (or the Apache Foundation, etc.) but the OSF’s unique and inclusive culture is a positive force in open source.
As far as StarlingX, in the upcoming months expect to see more from the project as it begins to move workloads onto its unique edge platform.