Thoughts on Red Hat’s Purchase of Inktank

Hi folks,

The truth is, I sorta saw this coming, but even if I’m not psychic, I’m really not surprised…Let’s look at the last few years:

2008 – It is clear that the complete Xen kernel bits will never ever ever be accepted into the upstream kernel, which means that Red Hat has to either support 2 kernel streams (regular RHEL kernel plus Xen kernel) or switch to KVM.. They bought Qumranet and with it KVM and the KVM engineers.

2010 – Red Hat’s CloudForms product is (depending on who you talk to) behind or not broad enough or (insert other opinion).. Truth is, I don’t know what the catalyst was, but the end result was that Red Hat purchased ManageIQ, and rebranded it CloudForms 2.0.

2012 – Red Hat is working hard on Aeolus, a promising PaaS product that was supposed to “out OpenStack OpenStack”. But again, they saw the writing on the wall, and moved to support OpenStack as the de facto PaaS project.

2014 – Red Hat’s purchase of Gluster 18 months earlier and rebranding as Red Hat Storage has not had the uptake that they had hoped for. In the mean time, Ceph becomes the de facto storage standard for OpenStack.

History repeats itself, and no more so than at Red Hat, and I mean this in the best possible way. Allow me to explain… Red Hat sets a course and goes whole hog into it. If it pays off, they continue. If it doesn’t, they re-evaluate and course correct. I love this about Red Hat, because it means that even as they surpassed $1b in revenue and 5k in employees, they remain nimble in their business decisions.

So how do I see things unfolding? Well, under the heading of “pure speculation”, I will say that Red Hat will not want to support 2 separate commodity storage platforms for too long. I think that Red Hat will either fix the issues that plague Ceph’s file service, or find a way to merge Gluster’s file service with Ceph. Additionally, Ceph’s management platform is further along. In other words, I don’t see an enterprise Gluster-based solution for too much longer.

Regardless, I think it was a great move as it solidifies Red Hat’s leadership in the Enterprise and Telco spaces for OpenStack.

Again, this is only my speculation and I could be (probably?) completely off base. It is also not a reflection of the men and women who work very hard to develop and support Gluster.. I have friendships with these people that will hopefully outlast my professional career.

But as long as I’m speculating, I have one more… As OpenStack (and RHEL-OSP) matures and picks up more and more enterprise features, I see Red Hat pulling the great parts out of RHEV and merging them with RHEL-OSP…. I just don’t see Red Hat supporting what will become 2 virtualization platforms.

Captain KVM

11 thoughts on “Thoughts on Red Hat’s Purchase of Inktank”

  1. Nice post. I think too, and hope, that they combine Ceph and Gluster’s strengths to finally make a robust, comprehensive file/object/block storage solution (specially to strengthen Ceph’s file storage capabilities).

    1. Jose,

      Thanks for dropping by. And yes, that is my hope as well. I think a comprehensive software solution would be great. Competition breeds innovation.

      Captain KVM

  2. Curious as to how you see Openstack and KVM “supporting two virtualization platforms”? They accomplish different things… it’s the same reason VMware has massive market penetration with the vsphere suite, and nearly nothing with vcloud director. Almost every business can benefit from the basic virtualization provided by esxi/kvm. Very few have the scale necessary to see a cost benefit from a product like openstack/vcloud director.

    1. Hi Tim,

      Thanks for stopping by and leaving comments/questions. It’s not so much a matter of “OpenStack and KVM” supporting 2 different virtualization platforms as it is specifically Red Hat supporting 2 virtualization platforms. You are absolutely correct that OpenStack and traditional virtualization, be it KVM or ESX or Hyper-V or Xen, serve different use cases right now. I whole-heartedly agree with that – however, in the next few years, I see Red Hat collapsing their virt and cloud products together. That’s my speculation. Customers have a funny way of telling vendors like NetApp, Red Hat, EMC, Vmware, and others how they will use their particular products… For example:

      I’m already seeing customers porting all of their internal applications to OpenStack, especially ones that don’t need HA, or have lower SLA’s. In other words, they’re already using OpenStack as a replacement for (in this case) VMware. As more customers do this, it forces OpenStack to mature even faster. For a company like Red Hat, as OpenStack (and therefore RHEL-OSP) matures and gets parity with existing virtualization platforms, it becomes less and less cost effective to support 2 different virt platforms.

      As for cost benefit from OpenStack, I respectfully disagree with you there. Whether you pay extra for vCloud Director or not, you still have to purchase VMware. If you want any kind of scale, VMware is going to cost you. In both VMware and OpenStack you have to purchase more hardware, but you don’t necessarily have to purchase OpenStack. Even if you do, getting support for OpenStack is much cheaper.. Even paid support for KVM is cheaper.. These same customers that I just talked about absolutely see a cost benefit from moving from Vmware to OpenStack.

      thanks,

      Captain KVM

  3. The point is, even at a price point of “free”, nobody wanted vCloud director other than service providers. It added a TON of complexity for nearly no benefit to the average company. I’ll admit I haven’t spent much time with openstack, but I don’t see how it’s any different. Perusing their documentation, it looks eerily similar. A bunch of complexity to add features the average business is never going to touch.

    Just look at their case studies, it’s a list of service providers and Universities/Education. That’s not to say it doesn’t have it’s place, but if Redhat dumps their KVM roadmap to roll it into Openstack, I think they’ll find themselves exactly where VMware did when they decided they were going to include vCloud with every licensing bundle they sold. I think that lasted about 2 quarters before the outrage from their users caused them to about-face. It was swifter and more brutal than vRam taxation.

    1. Hi Tim,

      I think I understand where you are coming from, and you do make very good points. Let start at the bottom of your last comment and then work my way back up.. I completely agree that vCloud director was botched. It was VMware’s attempt to get ahead of everyone else in “cloud” and help define it, but the execution was awful. I’m not suggesting that Red Hat dump their KVM road map.. Whether you virtualize on RHEL, RHEV, or RHEL-OSP, it’s all KVM. What I’m talking about is that RHEL-OSP 5 (when it lands in a few weeks) will start including support for HA in the configuration for critical services.. RHEV requires 3rd party help from NetApp and/or Symantec for that. That’s just one example of how OpenStack (and RHEL-OSP) is on a course to out-pace RHEV in terms of maturity and functionality.

      The case studies are in fact mostly universities as you say. But that doesn’t cover the folks that aren’t public case studies. NetApp alone has over 100 customers using OpenStack with NetApp, with twice that in POC.. and we’re talking Enterprise customers. And I agree with you that OpenStack is not a complete solution right now, and therefore has limited use cases, but that won’t last for long. Not at the current pace.

      Don’t get me started on OpenStack documentation. It’s not helpful at all when you’re trying to actually get work done. It’s essentially the best formatted man pages ever.

      As for complexity, all virtualization solutions are complex.. it’s just that OpenStack hasn’t done a good enough job of hiding that complexity yet. But then again, it wasn’t meant for the Vmware point and click crowd.. it was built by developers for developers with a true devops mentality. It’s the enterprise customers that are working on better GUI’s. Again, I’m saying watch what happens in the next 2-3 years.

      So in 2-3 years if you were Red Hat and RHEL-OSP has full HA, full deployment tools via API and GUI, ability to move workloads between datacenters and providers, full support for VMs and containers, full support for PaaS on top (OpenShift for example), a policy engine, and secure multi-tenancy, a secure useful web-based GUI, and other things that aren’t even on the RHEV roadmap, why would you keep RHEV? OpenStack has 100x more community support than RHEV does. That hurts as an oVirt board member, but “it is what it is”. Maybe take parts of RHEV-M, the thin hypervisor, and some other worthwhile tools, and donate them to OpenStack?

      In 2-3 years, OpenStack becomes a much different and better product than what it is today, and likely becomes more advanced than RHEV, Vmware vSphere, Hyper-V, etc. Ultimately, I think customers will move away from RHEV and to RHEL-OSP. That’s why I think Red Hat will collapse the products. They wouldn’t even lose any jobs, because the virt guys and the cloud guys are the same guys.. it would free them to concentrate on one roadmap, one set of bugs, etc.

      Finally, if we agree to disagree, that’s cool too. I honestly enjoy the healthy debate. I’d rather keep you as a reader, reliable debater, and devil’s advocate than be “right”.

      thanks again for taking the time to comment and debate!!!

      Captain KVM

      1. Hey Cap’n,

        Just felt the need to chime in on the convergence of OSP and RHEV.

        I think this is a bad direction and hope it doesn’t happen, for the same reason that we all pick on vCloud.

        At some level, “enterprise visualization” and “cloud” are nothing more than orchestrated virtual machines. However, the focus and needs for instantiation, management, networking, storage, third-party integration points (backups, app management, etc) are very very different between the two. There are certain subsystems that can be shared (Glance does effectively the same thing so why replicate) and some may bring new capabilities (Neutron is a giant leap for RHEV networking), but others (Heat templates for RHEV? Maybe not) don’t quite fit the paradigm.

        Why force traditional HA into OSP if the cloud paradigms don’t want HA? OpenShift is already fully supported on each platform, why force an integration that is already naturally supported while split? VSC is a great addition to RHEV for Filers, why lose that b/c we need to support Glance/Swift/Cinder in a different manner for “permanent” virtual machines?

        Or, better served in other tools like CloudForms, an orchestrator of orchestration engines?

        So tl;dr I think these tools are like hammers, there’s a broader category but we’re discussing framing hammers versus peening hammers and pushing towards a frame-peen hammer.

        1. Hi Matt,

          Again, all good points. I just think that in a few years that OpenStack will support everything that you would want, whether that is simple virt, private cloud, hybrid cloud, or public cloud, not that you would have to use it all. No one will force you to use HA, but it’s getting put in because enough folks are asking for it.

          Ultimately, I think vCloud Director failed because they were essentially forcing folks to use vsphere under the covers, when it really wasn’t geared for cloud. OpenStack is the flipside of that… You want your tools upstream? No problem, write them for everyone. To use your hammer analogy, I think of vCloud Director as the frame-peen, or at least an awkward attachment to a framing hammer to look like a peen.. I still see OpenStack as a tool box, much like Linux or Unix. You don’t have to install every tool or package in Linux or OpenStack. Install the pieces you need. Make it look like what you need, not how a particular vendor defines it. I see RHEV as a toolbox as well with lots of room for new tools.. I just think that the tools will be created in the OpenStack community first and as such, added to the OpenStack toolbox first..

          Again, this is only my speculation. And I love the debate. And I have no problem being wrong…

          ck/jb

          1. 10000000% agree on the “OpenStack as toolbox” message. Umbrella over a group of projects that you can use to do “cloud stuff” by picking and choosing from the set. Lots of folks I talk to don’t get that part. They think it’s a “cloud in a box” that just goes…enough soapbox.

            So while I agree, I do wonder if someone is going to start building the sorts of tools to provide “traditional” enterprise virtualization orchestration for OpenStack if they wouldn’t be better off being told to go contribute to oVirt. Reuse and improve neh?

            Or… does oVirt wind up as a project under OpenStack as the enterprise virtualization pattern of component installs? I think I just walked into the “Here There Be Monsters” part of the map…

Agree? Disagree? Something to add to the conversation?