1. We thought that private clouds were generally valuable. In 2010 it seemed like everyone was going to have a private cloud. It turns out if you are a midsize business, having a rack of "cloud" doesn't really offer you much benefit over having a rack of managed vms. You still need to pay someone to manage that rack. The vast majority of the benefit of cloud comes from having a ton of workloads, which means a public cloud or a huge service-provider sized business.

2. We focused on community building by supporting all use cases. The best way to build an open-source community is to bring everyone in. The community grows fastest that way. Unfortunately, it also means that the product quickly becomes an unfocused frankenstein that is decent at everything and good at nothing. Projects like docker and mesos are suffering from the same problem.

The end result of these mistakes OpenStack is good for certain use-cases. It does really well in large companies that need a public-cloud like environment to manage their infrastructure and can hire a team of people to manage it (e.g. comcast, verizon, e-bay, wal-mart).

I don't know that the exodus is due to endemic problems so much as the market finally waking up and realizing that public cloud is the future.

You folks popularized a misconception and hoped to monetize it in perpetuity and were eventually corrected by reality. So goes all big $$ software.

Get ready for the next big thing and first step that...ad nauseam.

The problem with Openstack is it had too many moving parts, and no standard/reference implementation. It was destroyed by it's own grandiose goals. The project wanted to say 'yes' to every permutation of software. Making it a disaster from an operational standpoint. Everything promised, but nothing verified.

Visible also in things like the installation process (which for ages didn't have an "official" answer, so you had pay one of the big vendors to do it if you didn't want to try automate it yourself)

It's a PaaS for IaaS foundation. Unless you have the resources to line up and support Openstack, I recommend just build on AWS/Google/Azure/Rackspace/Heroku/DigitalOcean, you name one.

I wonder if big customers such as Bloomberg ever regret / think of moving to public/private IaaS.

Instead it was a vehicle for hardware vendors to sell compatible product and consultants to build something they'd have to service forever afterwards. (Yes this is a cynical and half joking take, but it's also serious)

So what went wrong? Welll, If you're not going to build a product that teams can actually figure out how to use, then you need to have Cisco or Oracle level sales talent behind it. OpenStack didn't have that, and maybe couldn't have it because there wasn't one boss company behind the product.

Like I mentioned, there is a trade-off between the usability and required Sales Power. As far as usability goes, even consultancies that were directed to use and sell OpenStack solutions couldn't get their people to figure it out. A consultancy based technology has to be coherent enough that a junior associate can reasonably start billing hours for it. OpenStack will stymie a close-knit team of veteran "devops" people— And I'm talking about people who actually know systems administration and development, not a buzz word ninja.

Everybody got that completely wrong. Open source works, but you still have to understand how to engineer it. So far, companies that succeeded are mostly following an "open core" model where they control the core too (Atlassian, Automatic). Red Hat is the exception, and with Red Hat putting a lot of effort on upstream OpenStack development no one could pull off open core for OpenStack. Mirantis has plenty of non-upstream code and last I heard wants to sell SaaS to work around that.

Plus, no one devoted the right amount of engineering to the lower levels of the stack (at least QEMU and libvirt). You cannot seriously expect to partner with vendors for guest operating systems without knowing all of the stack---this was something else that Mirantis and others missed.

So the problem was not that OpenStack was bad, it was that everybody thought open source is magic. But it isn't magic, and if it looks like magic, it means you don't understand it.

IMO, OpenStack was sort of a consortium effort to compete with VMWare, AWS and Salesforce, but it's operational model is closest to AWS. Nearly all the big enterprise IT companies tied their rafts together hoping to stave the flow of customers. It doesn't appear to have worked.

RackSpace is advertising AWS migration and consulting services on podcasts I listen to. Not exactly a stellar testament for their own cloud product, but I think they still participate.

HP's strategy is a bit haphazard given the recent corporate splitup. On the plus side, the HP/HPE split seems to have allowed HPE to ditch all the weird www# URLs. They retired their public cloud, but still sell hardware that can run OpenStack at least.

Dell bought EMC, and proceeded to shut down their OpenStack offerings in favor of VMWare, which they own a substantial fraction of.

IBM is in a continual process of downsizing its hardware divisions in pursuit of higher earnings per share. It seems their big push is cloudfoundry, which seems to be more about containers and k8s.

So why are they bailing? I'm guessing:

- it's way harder to hire support staff for OpenStack, than VMWare - AWS reduces capital costs and upfront investments - Customers on existing solutions aren't prepared to take advantage of new opportunities - Many of these companies have existing product lines they don't wish to disrupt

Most of IBM, Intel, HPE etc have thrown in the towel and now offer their own services on top of Red Hat OpenStack.

OpenStack has now found itself beyond enterprise, and now being the de-facto platform for NFV running mobile networks, and I guess Red Hat are becoming the winner here as they are so used to supporting an OpenStack 'type of' infrastructure for large bodies such as banking, telco, health etc. When you consider Red Hat are already large well established contributors to all of the layers of the OpenStack 'stack' such as KVM/QEMU , libvirt, the kernel itself, + overlay networking tech such as OVS, and now DPDK, you can see why they are well positioned to support and run OpenStack clouds.

[1] https://www.theregister.co.uk/2017/03/28/red_hat_cloud_quart...

Given all of the inter-dependencies between OpenStack services and lower level Linux constructs and software (OVS, Ceph, QEMU, etc.) those who were already used to distributing and managing these already turned out to be the ones who were best able to make the combination work.

That said at least some folks who were working on OpenStack and related technologies at Canonical are among those now looking for new gigs:

https://twitter.com/zulcss/status/852542117566189568

Thus while cloud remains on their priority list it is not immediately clear how big a part OpenStack will play in that going forward for Canonical versus solutions that run on the reigning public clouds.

Canonical seriously lacks expertise in KVM (+QEMU+libvirt), and you cannot take that for granted when you have a customer with VMs crashing that is asking for a fix.

FWIW, I recently had to explicitly inform the Canonical Virt maintainers (of which there seem to be very few) about which patches that ought to be backported to fix a bug in one of their libvirt packages that was seriously affecting (i.e. preventing from patches being merged) OpenStack upstream CI environment.

The said bug had fixes already available upstream, and are straight backports with no conflicts. No one bothered to do the "unsexy" work of backporting & cutting a quick stable build.

Only after pointing out the commits (with help from one of the lead upstream libvirt maintainers), and posting them on a LaunchPad bug, did the Ubuntu maintainers stepped in to backport the said fixes.

Cloud Foundry is built on technologies that predate k8s, but yes, containerisation is the unit of operational currency.

Insofar as Dell EMC has a multi-play, it also includes Pivotal, which is the leading contributor to Cloud Foundry. Unsurprisingly it runs smoothly on VMWare, as well as AWS, GCP, Azure, OpenStack and I forget what else.

Disclosure: I work on Cloud Foundry on behalf of Pivotal.

Just conjecture on my part, but I would have serious reservations about that part of their service catalog right now if I was vendor shopping.

Their own cloud isn't mentioned on it. They've obviously been putting their eggs in the consultancy basket for 6 months now,

Hell, even if you go to cloud in the menu, they're only advertising other clouds: https://www.rackspace.com/cloud You have to go through the 'Infrastructure' menu to find their own cloud offerings.

I'm wondering how long before we get notice we need to migrate away from them due to impending shutdowns.

Devstack works. Sort of. Poorly. Everything else is pay-a-consultant territory.

OpenStack refers to a number of different projects (Nova, Neutron, Horizon, etc). I would advise getting a high level understanding of how Nova, Neutron, and Cinder/Swift interoperate. Then drill in to Neutron. As with every other cloud platform I've worked with, most of the IaaS complexity lies in Networking, in my opinion. Neutron, and SDN in general, is a fairly complex topic depending on your experience with network architecture and administration.

So for example a development environment I use is a docker-compose environment building Monasca. That environment is a work in progress, so half the time I'm fighting that environment just to make a proper change.

Then from there, I don't have Horizon, so I have to use command line apis directly to set everything that I wish to use.

The whole thing has just been a challenge, every part I've had to learn in some respect. The actual code I've changed in Monasca, has been the simplest part so far. Validating it's correct, and testing it has been the far harder challenge.

Monasca also being a bit of a challenge since it's several different repos of services working together, instead of a large one akin to Nova.

I'll get it, but it's been a struggle so far.

Take a look at the sponsors for KubeCon and Dockercon and consider that many of these same companies were those originally trying to catch the OpenStack wave, and then ponder how many of them will be extracting themselves from those projects in 5 years (or at least lowering their investment, which as we see here is generally perceived as extraction).

Prominent folks in the Kubernetes community will tell you that it's different but the recent conferences sure have a similar vibe to OpenStack summits circa ~2013 when the marketing really started to overtake what the technology could deliver.

I believe the decline of OpenStack is inherent in the type of technology. I don't believe that type of "infrastructure plumbing" software lends itself to high-speed high-quality innovation in the "open source" model. Some reasons:

1) it's boring infrastructure software: Because it is software for "data center" infrastructure, it's not glamorous and interesting enough to attract programmers who don't interact with that world. Other successful open source projects like LAME MP3, ffmpeg, Linux kernel, etc have programmers that can experiment on laptops and ordinary users that can download and play with it.

2) no abundant source of high-quality code contributions: The enhancements you want contributed into OpenStack should be provided companies running complex private cloud operations. They would battle-test the code and that knowledge would trickle down into the open source contributions.

However, a company that's facing the prospects of a complex private cloud would more likely choose Amazon AWS or Google Compute platforms instead of tackling OpenStack.[1] This removes a subset of potential OpenStack contributers. OpenStack is so complex to run/customize/maintain that it requires building up an internal staff with skills similar to AWS/Google/Facebook's datacenter engineers.

If the company does decide to run OpenStack, it's likely they won't contribute back any source code. (Same as Linux situation where most users of it don't contribute source code.) This removes another subset of potential contributors.

Probably the best "private cloud operating systems" are developed by Google/Facebook/Amazon/MS for their own datacenters and those 4 companies are not contributing to OpenStack. Wal-mart has sophisticated datacenter operations and they may be the largest Openstack user but their contributions to OpenStack do not match the new innovations of AWS mentioned at re:Invent[2] or Google CloudNext[3]. Yes, Red Hat is a sponsor of OpenStack but their internal cloud operations are not stressed like AWS/Azure/GCP with customer-facing challenges nor do they manage IT complexity like Wal-Mart.

Sometimes, commercial versions of plumbing software do lose to open source projects. One example would be Microsoft's Dryad "distributed computing" losing to open source Hadoop even though MS had a 7 year headstart. However, Hadoop+HDFS is still not as fast or reliable as Google's internal distributed mapreduce. (Maybe the idea of buying a hundred expensive Windows Server licenses to satisfy a 100-node Dryad cluster contributed to the market ignoring it.)

Based on history of how certain open source projects fall behind proprietary counterparts (such as OpenCL not as cutting edge performance as NVIDIA CUDA or OpenGL not matching MS DirectX features[4]), OpenStack seems on to on a similar trajectory of "not as good as the proprietary alternative".

At this point in time, the "private cloud OS" space is moving very fast (possibly faster than flavor-of-the-month Javascript frameworks!) and the open source development model is not able to keep up.

[1] http://www.computerworlduk.com/cloud-computing/guardian-goes...

[2] https://aws.amazon.com/new/reinvent/

[3] https://blog.google/topics/google-cloud/100-announcements-go...

[4] https://softwareengineering.stackexchange.com/questions/6054...

From my perspective, companies that decide to run Openstack do contribute code back, but the process is so long and arduous to get code accepted that it's not hard to see how groups would just give up and just merge upstream to their own.

Core reviewers have to accept your code, and they are on no timeline to do so. Months will go by without a review.

I think that's a slightly different reason because OpenCL is just a spec with no real teeth. NVIDIA/MS have a pretty tight grip over the market both in h/w and s/w, and creating a CUDA like spec does nothing meaningful if there is no alternative source for hardware and software. Everything including drivers, libraries, compilers etc. is closed, whether it's CUDA or OpenCL. So aside from some vague promise of portability, OpenCL doesn't really open anything.