TL;DR: Sometimes paradigm changes demand a rapid response and I believe unifying OpenStack services under Kubernetes has become an such an urgent priority that we must freeze all other work until this effort has been completed.

See Also Rob’s VMblog.com post How is OpenStack so dead AND yet so very alive

By design, OpenStack chose to be unopinionated about operations.

pexels-photo-422290That made sense for a multi-vendor project that was deeply integrated with the physical infrastructure and virtualization technologies.  The cost of that decision has been high for everyone because we did not converge to shared practices that would drive ease of operations, upgrade or tuning.  We ended up with waves of vendors vying to have the the fastest, simplest and openest version.  

Tragically, install became an area of competition instead an area of collaboration.

Containers and microservice architecture (as required for Kubernetes and other container schedulers) is providing an opportunity to correct this course.  The community is already moving towards containerized services with significant interest in using Kubernetes as the underlay manager for those services.  I’ve laid out the arguments for and challenges ahead of this approach in other places.  

These technical challenges involve tuning the services for cloud native configuration and immutable designs.  They include making sure the project configurations can be injected into containers securely and the infra-service communication can handle container life-cycles.  Adjacent concerns like networking and storage also have to be considered.  These are all solvable problems that can be more quickly resolved if the community acts together to target just one open underlay.

The critical fact is that the changes are manageable and unifying the solution makes the project stronger.

Using Kubernetes for OpenStack service management does not eliminate or even solve the challenges of deep integration.  OpenStack already has abstractions that manage vendor heterogeneity and those abstractions are a key value for the project.  Kubernetes solves a different problem: it manages the application services that run OpenStack with a proven, understood pattern.  By adopting this pattern fully, we finally give operators consistent, shared and open upgrade, availability and management tooling.

Having a shared, open operational model would help drive OpenStack faster.

There is a risk to this approach: driving Kubernetes as the underlay for OpenStack will force OpenStack services into a more narrow scope as an infrastructure service (aka IaaS).  This is a good thing in my opinion.   We need multiple abstractions when we build effective IT systems.  

The idea that we can build a universal single abstraction for all uses is a dangerous distraction; instead; we need to build platform layers collaborativity.  

While initially resisting, I have become enthusiatic about this approach.  RackN has been working hard on the upgradable & highly available Kubernetes on Metal prerequisite.  We’ve also created prototypes of the fully integrated stack.  We believe strongly that this work should be done as a community effort and not within a distro.

My call for a Kubernetes underlay pivot embraces that collaborative approach.  If we can keep these platforms focused on their core value then we can build bridges between what we have and our next innovation.  What do you think?  Is this a good approach?  Contact us if you’d like to work together on making this happen.

See Also Rob’s VMblog.com post How is OpenStack so dead AND yet so very alive to SREs? 

Category:
Kubernetes, OpenStack, Uncategorized
Tags:
, , , , , ,

Join the conversation! 6 Comments

  1. […] Read Rob's follow up article, OpenStack's Big Pivot: our suggestion to drop everything and focus on being a Kubernetes VM manageme… […]

    Reply
  2. Too late. Openstack’s big draw was a lingua franca, a common API for cloud. It cant really deal with multi-site, regions, AZ and federation for itself, let alone help abstract or handle multicloud. It also, as you point out, doesn’t deal with containers as first class. So not the multicloud, not an abstraction tool, not a container manager. And with container management services available from the cloud vendors themselves this really would be serving a dying on premise market. PAAS itself is really funneling all into k8s, and that will be served by the cloud-infra providers, the rest of the world (non-IT focused shops) want to buy SAAS, and for SAAS offerings you need the Holy Grail of technology, actual user facing, B2B and B2C applications. Openstack has no SAAS offerings and no SAAS vendor uses Openstack that i know of. Seriously, containers as a point of interest will probably pass by quickly – k8s will become dominant and the standard quickly and k8s services will be facilitated by cloud-infrastructure vendors. Tangled messes like cloud foundry will fall by the wayside, either buy a SAAS, or build-your-own-PAAS – forget buying a PAAS to build on that.

    Reply
    • Thanks for your comments! I’m not sure that on-premises is dying forever – I do think that it needs to be radically changed to improve ROI before it’s a realistic alternative again. I think that competitive pressures drive IT change in powerful ways.

      Reply
  3. […] tried to define that recipe for everybody, and that approach didn’t work as well as some had hoped for something as complex as modern cloud computing. The CNCF is trying to do the opposite, […]

    Reply
  4. […] tried to define that recipe for everybody, and that approach didn’t work as well as some had hoped for something as complex as modern cloud computing. The CNCF is trying to do the opposite, […]

    Reply
  5. […] OpenStack’s Big Pivot: our suggestion to drop everything and focus on being a Kubernetes VM manage… […]

    Reply

Leave a Reply

%d bloggers like this: