1. 13
  1.  

  2. 2

    Something that’s overlooked about OpenStack is how our industry learned from the Governance model. There was such a high bar to entry that it took (sometimes) weeks to get just your account set up. Nowadays, with SIGs and other systems, you can see how people learned from the initial good intentions of OpenStack Governance(s) and built more stream lined paths to contributions.

    1. 1

      We need a better vocabulary to describe what happens to these projects. “Cathedral” and “bazaar” remade words to describe a fundamental dichotomy in projects. Adding some vocabulary allows better discussions.

      OpenStack, XMPP and CORBA adopted “Open World” specifications where the landscape is so large it is difficult for anyone to explore it all. It is nearly impossible to implement all of it. Often, users will Balkanize to one or another implementation. In contrast, Nginx, CommonMark, and Ledger adopted a “Gated” approach where all extensions were solidly outside of the project.

      This means that you can see adding more “Open World” specifications to mirror cloud APIs from multiple vendors will inherently cause fewer implementations to be compliant. You can talk about the payoffs to users versus the costs of maintaining a larger world.

      I suggest no answers; I only suggest that effort be made into a better vocabulary.

      1. 1

        Yes it might be, but I don’t think the core reason identified in this article is the full story. Bringing it’s own API to the game and hence being too complicated might not be the right cause and effect direction. Consider the glut of recent articles about medium-size companies abandoning cloud services and going back to running their own bare metal — besides pricing and such one of the major benefits is that they ofter reduce total complexity by trading some system admin work for simplified app architecture.

        OpenStack may be fighting a loosing battle partly because people that don’t want to run their services on the cloud don’t want to layer themselves on top of a bunch of abstractions and might actually want to run closer to the metal. The sort of folks that run their own servers (for whatever reason) are just the sort of folks that might also have good reasons not to want to just mimic a cloud hosting setup and architect things a bit differently from the outset.

        1. 1

          Or, is it just an illusion and an echo chamber from the people I work with? Because most of them only talk about one thing… Kubernetes.

          Wikipedia tells me that k8s was released in June 2014. k8s was the new kid on the block and basically no one had any experience or even looked at in detail, but not long after this we (at my company back then) had already formed an opinion about OpenStack. We kept using it because it wasn’t a terrible choice, but it was kinda terrible to use. k8s didn’t even come into the picture when most of us (who were not part of the consortium/consulting ecosystem) had already made half of a decision that this won’t last.

          Years later at one FOSDEM I talked to someone on their booth and while at first telling me enthusiastically that everything was going better now, every time I mentioned one of the releases we had used and our problems there was only “oh, ok. Yeah, that…” and so on.

          TLDR: OpenStack had its uses but for small teams (or small orgs) it was a nightmare, especially the upgrades. Too frequent, too much breakage - and usually not even coming up in smaller test lab setups.

          Also I’ve not even extensively used k8s but from everything I heard, the (complexity) problems are on a completely different layer (not level) - once your k8s cluster runs it will not randomly break every week and not every upgrade will change every second API.