Q&A: IBM’s Landmark Acquisition of Red Hat

Editor’s note: Today, we announced the close of Red Hat's acquisition by IBM.

Q&A with Arvind Krishna, senior vice president, IBM Cloud & Cognitive Software, and Paul Cormier, Red Hat executive vice president and president, Products and Technologies

How will IBM and Red Hat benefit from joining forces?

Paul: Red Hat is an enterprise software company with an open source development model. A fundamental tenet of that model is that everything we do, from new practices that we learn to new technologies that we develop, goes back to the upstream community. By joining forces with IBM, our reach into customers will dramatically increase so we’ll be in a position to drive open enterprise technology a lot further. As for IBM, we’ve been partners for quite some time, but now existing IBM customers will have even more direct access to next-generation open source-based technologies that are at the cornerstone of hybrid cloud innovation.

Arvind: There will be an increase in terms of the investment that goes into open source. Red Hat will be able to directly leverage the work that IBMers do in these communities. As a result, a lot more will go back to the upstream community. Another benefit is the optimization of IBM products to run on Red Hat products. We’ll spend even more energy enabling other open source projects to run on this infrastructure.

What about the benefit to clients? What has been their feedback?

Paul: Let me put it this way: we’ll bring innovation to our clients at a greater scale and on much broader scope. The combined might and expertise of Red Hat and IBM will allow us to do a lot more for our clients. I recently spoke to a large wireless carrier, and the feedback was: “we love you both.” They see the opportunity that’s in front of them; of taking open source technology a lot further. This is not just a consequence of IBM’s physical reach. It’s about having the capacity to take on much larger projects. In many cases, they’re already running IBM products or relying on IBM consulting to deploy these technologies. We’ve done some of this as partners, but it’s never been done in an integrated fashion.

Arvind: It’s a change in the order of magnitude—for us and our clients. It’s about bringing the skills and capabilities needed to carry out massive transformational projects. A lot of our mutual clients are interested in doing a lot more. Many see this as an opportunity for us to create large industry ecosystems with other providers who are optimized on this common infrastructure. The benefit for them is clear: they’ll be able to consume the technology in a much easier way. If Red Hat were to do this on their own, there would be a limit to how much they can scale. Together, we can put a lot more resources into optimizing other partners. The best part? It’s a win-win-win. It’s a win for us. It’s a win for clients, and it’s a win for other providers.

What are the most pressing challenges that clients and industry currently face?

Paul: When cloud first came on the scene, companies were told that every application would move there as early as tomorrow. That was more than 10 years ago. However, industry analysts point to the enterprise world as being about 20% there. One of the reasons for this is because the cloud has become an increasingly complex environment to manage. This is, in part, because of a confusion as to what constitutes a cloud-centric development project versus a cloud-ready product. Kubernetes, for instance, is a development project, not a product. Many customers have been under the belief that all Kubernetes distributions—all 125+—were compatible. But it’s not the case. When it comes to deployment, they quickly realize that these are not on the same timelines, lifecycles, etc. Just like products, all the clouds, even though they have the same underlying technology, they’re all different. And so, as customers want to span clouds, they’re realizing now that they have to have four or five different islands of technology stacks that developers have to develop for, and that operations people have to operate. That’s really unsustainable from a management perspective.

Arvind: Let me add another major challenge. Every business today is effectively becoming a technology business. A huge pain point for clients is to leverage technology in a way that optimizes their workflows. When people talk about deploying a platform, the things on top hardly come optimized. Capabilities such as recovery, monitoring, security, and auditing are rarely built in. And they often cannot be deployed in a single click. Typically, all of these configurations have to be done manually. So, a massive problem our clients need us to solve is to make the whole process a lot easier.

How will the two companies help solve these problems?

Arvind: What clients need—beyond the platform itself—is the expertise and the added work that’s going to help make the whole environment less brittle. That’s what we’ll accomplish together. Red Hat is already providing the platforms on containers and Linux. They can also offer the workloads that come on top. For IBM, the name of the game is to ensure that the middleware, data, and AI—not just IBM’s but also the open source ones—come optimized.

Paul: Businesses need to simplify their IT environments. This is even changing the way applications are going to be built. Instead of monolithic applications, we’re going to see applications built into microservices architecture, which is excellent from a software engineering standpoint. And to really take advantage of microservices, clients can spread these across multiple footprints. And there’s one way to keep those in sync, and that’s automation. It’s just too complex for humans to do it without tools.

Arvind: Let me add this. The world has already embraced Linux, and now it’s moving toward containers. The problem is, if you let that happen in a chaotic way, we’ll end up getting 1000 disparate islands. Using automation—so that one person doesn’t have to manage 1000 instances—is vital. Without it, it’ll be much harder to create that simpler and more cohesive environment that clients so desperately need.

IBM and Red Hat both have far-reaching relationships with the developer community. In what ways will developers benefit as the two companies join forces?

Arvind: The world of IT is currently going through a big shift. In an environment where there’s 1000 disparate islands, a developer’s reach is somewhat more limited than it could potentially be. As we go about and create this common infrastructure that will help companies on their journey to use different public clouds, we’ll help developers unlock all of that reach.

Paul: What we learned from deploying public clouds is this: Clouds can become part of the IT infrastructure, but rarely part of the entire IT infrastructure. Customers have on-premise applications that run on bare metal, virtual machines, or private clouds. And they have multiple public clouds that they now want to be able to span across. Each platform will have a different version of Linux running on it, based on specific developer needs, which means that each development environment is different as well. This is the problem that we’re aiming to solve—providing a single, common operating environment across the hybrid and multicloud world. As we help lay down that one common operating environment, we’ll not only help operators but also help developers have one operations policy, one deployment policy and one security policy. They’ll have one environment where they can build once and deploy in any one of the footprints that’s appropriate.

IBM and Red Hat’s relationship goes back almost 20-years. What are Red Hat and IBM able to achieve in a formal union that they couldn’t before as partners?

Arvind: A business partnership only gets you so far. Moving forward, the primary platform on which we’ll develop and deploy software products will be Linux and OpenShift. Both for cloud and on-premise. Also, Red Hat has the largest enterprise ship with Linux, so now we’re in a position to do a lot more. We can provide the end-to-end solution that only the two of us can build. Doing this is hard unless you are committed to each other.

Paul: From an upstream perspective, there’s an efficiency aspect in terms of getting more engineers on the right projects early on. Let me give you an example. Five years ago, there were no less than ten different container orchestration projects out there. Red Hat decided to put all the wood behind Kubernetes. We brought influential people that were working in that community into Red Hat, put extensive resources behind making Kubernetes enterprise ready and became influential community members as a company. We decided to put all of our developers down that path, but IBM could have had a different opinion. Now we’re in a position to discuss the merits of an upstream project for the benefit of the community and we can do that in the open.

Arvind: If you take the example of Kubernetes, Red Hat is among the top contributors. However, if you take Istio, IBM is. So together we can also cover more ground and do things that build on each other. That’s critical because the nature of open source is not for one company to do it all. A key success factor is having contributions coming from very different places.

Paul: Absolutely. The weakest projects are the ones where it’s just one company. The most successful projects have the broadest scope. There’s tremendous value in having different ideas from different places. That said, many companies claim to be open source companies, but they’re just packagers. In fact, they have little influence upstream. If upstream is your development model and you can’t help drive where it’s going, then you won’t be able to solve your customers’ problems down the road. Both IBM and Red Hat have worked upstream for a long time. So, I think that’s just going to be great for open source. It’s in our collective DNA.

What are the one or two most important principles that you see as necessary for open source to continue to flourish?

Paul: First, there’s the principle that the best technology wins. However, the most significant commitment Red Hat has and will continue to have is “upstream first.” What do we mean by that? We won’t put anything in the product that isn’t already upstream or very close to being accepted upstream. That’s crucial from an open source perspective, but, more importantly, from an engineering perspective. An upstream first policy is what allows us to develop an enterprise-class product line space that’s 100% based on open source technologies.

Arvind: I will add the importance of giving back as much as you take. Some companies simply take open source and then fork it. Giving back allows you to be a good citizen of the innovation that is happening and that others can also benefit from. Also, open technology communities that strive for inclusiveness and open governance tend to attract the largest ecosystems. Projects that have many contributors are more robust, have a longer life, and are less risky than projects that are controlled by a single vendor or are more restrictive in their governance.

Red Hat is often described as the Switzerland of IT. That aspect has been the key to its enduring success. What will IBM do to preserve the neutrality of Red Hat?

Arvind: Red Hat is going to stay neutral. Let’s be extremely clear about that. For this to be successful it is key that products can run anywhere that clients want them to see. Guaranteeing access to the broadest possible ecosystem is what enables true choice for customers. It’s in everyone’s interest to let Red Hat be Red Hat.