IBM and RedHat – seeing the forest for the trees.

Regarding the IBM + RedHat deal… here’s my two cents (and please note my disclosure and the fact that this is not a corporate position):

  • First: CONGRATULATIONS to the RedHat team.   While people will (as is their right) make forward looking assumptions about what this means for IBM, for RedHat, whether they will be independent/autonomous.   What happens next week, next month, next year – who knows. It’s certainly something that we’ll all have to see, and time will tell. There’s snark out there by many.   I don’t think that’s right – certainly not at this time.  Heck, the ink isn’t even dry.   The first thing to say is that this is a positive day for RedHat.  It’s an accretive exit. It validates how important software defined has become.  It validates the challenges and the opportunities built around Open Source Software.
  • Second: I think it’s a validation of our Software Defined stack, our multi-cloud horizontal platforms (from the IaaS, CaaS, PaaS, and FaaS abstractions).   I think it’s a validation where we lean in like crazy our Open Source Software (OSS) model, and frankly Dell Technologies overall.
  • Third: See the forest for the trees.   Search for what I think is the deeper story.

What do I mean by that third comment?   This deal is positioned as all about Hybrid Cloud.   I guess that’s a lens. Personally, I think the real lens is the following:

  • Control points are important.  Customers don’t like to hear this, but there is a technological fact (not opinion) that there are certain critical “control points” in the technology stack.   “Control” != “closed”. Rather, it represents layers of the technology stack that are very valuable, because they span/transit/bridge broad parts of the technology ecosystem.   Because they are so horizontal, they are sticky (when done right) – and “sticky” means no more (and no less) than “important to customers”. Data itself is a control point as well as Data control planes and data planes.   Operating systems are a control point – although less important every day. The IaaS, CaaS, PaaS, FaaS abstractions are control points – and more important every day. Software Defined Storage and Networking are control points (note that their non-software defined peers are less so – because they are less “horizontal’).   Developer tools are control points. Fundamentally,  control points are the places where platforms are born.
  • Everyone needs to adapt – or fade to irrelevance.  That statement applies to Dell Technologies as much as anyone.   In this case, I see it as a case where IBM needed control points for continued market relevance, and increasingly, they realized that they needed an inorganic option, because it wasn’t working organically.  The new control points are places where they were simply not leading. That may sound like a critique – it isn’t. It’s a sign of strategic wisdom to recognize a need for change, and to act.   Execution against the opportunity is of course where the rubber hits the road.
  • Open architectures matter – but are not enough.  These control points in general bias towards OPEN. This doesn’t ALWAYS translate to Open Source, but often does. The reason is basic – customers realize that they need to pick these choices wisely.   Many (including me) have written that “lock in” is the wrong idea – because every choice is a form of “lock-in”.  One of my favorite posts on this topic is here, and I highly recommend reading it.  “Lock in” is indeed more accurately represented as the ratio of “benefit” : “cost to move/friction to move”.  Example: SaaS represents near total lock in (very high friction), but provides massive benefit so customers are A-OK with that as “positive lock in”.   Public cloud APIs and data platforms have a can have high cost to move.   Important: open projects like the Open Service Broker, Cloud Foundry, Spring are essential for minimizing bindings for developers.   Likewise, things like K8s is becoming essential for minimizing bindings for the intersection of the developer and infra domain.   Virtualization likewise abstracted hardware – and reduced the cost to move.   In each of these domains, they are open ecosystems, often with a clear leader.    The piece of work that has kept the team I work with at Pivotal and VMware very busy of late is our work around Kubernetes as that new critical open control point – manifest in VMware/Pivotal PKS.  It’s VERY important to Pivotal as K8s is the base under the future of developer abstractions. It’s VERY important to VMware as K8s is the API standard for container scheduling/abstraction… and while containers almost always run on kernel mode VMs (for hardware abstraction and operational reasons) – K8s moves the control point up from the kernel mode VM layer as well as some of the functions.   The VMware/Pivotal PKS effort is anchored in the fact that we MUST contribute like crazy, but more importantly we must keep a couple of “north stars”. These “north stars” are: enterprise readiness; simple lifecycle of K8s itself and fleets of K8s clusters, K8s completeness (“batteries included” of everything you need – critically a great SDN in NSX-T); and constant compatibility with native, clean, K8s – with all contributions going upstream.  Pivotal and VMware recognize many K8s use cases and markets (multi-cloud enterprises, K8s-aaS, and how over time we can bring K8s dial-tone to the masses).  PKS is the singular focus around K8s dialtone for Dell Tech.  But a CRITICAL “north star” that is worth elaborating on is “constant compatiblity” with Kubernetes and GKE.  Pivotal and VMware must commit to being pure, always contributing northbound to the K8s core, to never fork, to build on clean API abstractions that people can integrate with (see CNI/CSI ecosystems) and build developer value on top of K8s (see Knative and Istio work).   This is open at its core.  It’s working. PKS is cooking and has a ton of momentum.  There are PKS customers of every size and shape, in every geography around the world.  It’s also worth stating that from where I sit, the industry is ABSOLUTELY are in the Kubernetes early stage enterprise hype-cycle.   The vast majority of workloads currently fit the kernel mode VM abstration as the sweet spot.   Beyond that,  there are K8s major releases every 3 months, and one of the things we focus on is making upgrades easy – because frankly every release has a ton o f change. If customers find themselves unable have a platform that follows the continuous delivery principles of iterating fast, delivering incremental value, K8s in the enterprise won’t fly. We aren’t perfect, but are iterating FAST.
  • Open Source models are important – but not enough.  Businesses anchored in Open Source Software are essential, important, but also challenging.  RedHat’s approach to building an Open Source based business was one. Pivotal’s is another. No one can question the Pivotal OSS bona fides – check out the GitHub study from Oct 2017 here and deeper analysis here.   More interesting, when the data is sliced by employee, we are #2 – see that here.    That last one is fascinating, and it highlights, OSS is in our blood.  VMware is also increasingly a large force themselves in the OSS communities, in the K8s SIGs (more on this very soon).    So, this comment is coming from a pro-OSS PoV: businesses built on OSS is hard. You can see all the news in this space around Cloudera/HortonWorks.  You can see Redis Enterprise, MongoDB, and others trying different Open Source licensing models. My point of view – it’s about delivering platform outcomes, not Open Source per se.   I’m passionate that Open Source is a force for good. Yet, I encounter customers constantly that spend countless years, countless millions of dollars in OSS based science projects – with nothing to show for it.   The most extreme (and most epic fails) are when enterprises try full OSS (no partner, just going for git pull/clone solo) themselves – and discover it is ridiculously HARD to maintain platforms built on OSS without massive software development teams and making material contributions themselves.   Even when they are successful, it’s often transient.  The number of customers with crufty OpenStack platforms that are back-revved years and have become fragile is legion.  I see some of the same happening with K8s: most of our PKS customer are customers that have tried this approach and have learnt how hard this is.   They just want a platform.  Building and sustaining platforms is almost never a strength of enterprises – and frankly, why would it be?  It’s not their business.   Yes, this “pure OSS” is the model of the hyper-scale folks. Let me share a friendly hint: you are NOT Google, you are NOT AWS. The Dell Technologies focus (and here I mean Pivotal certainly, but also VMware and Dell EMC) is to contribute to OSS, to build on OSS – but with a lens of “platforms are something you build ON, not something you build”.  Another friendly hint: measure the economic value of platforms that you use through what they enable YOU to do, not their sub-component cost elements.  If you find yourself struggling to maintain an OSS platform, you’re not alone.   Ask for help.   But recognized that falling into the trap of “OSS should be free” is a strategic error and will lead to businesses built on OSS, and platforms built on OSS failing.  If you believe in OSS – support businesses build on OSS (and that yes, that means paying them).
  • It’s a “full stack” game – and that means consolidation of ecosystems.   Keeping the balance of “integrated stack” and “optionality” right is a hard balance.  I know this well – it’s the world I work in every day.  This move helps IBM have a more complete stack. That said, I say “welcome to the party” 🙂  We have a full technology stack as Dell Technologies between Pivotal, VMware, Dell EMC, RSA, Secureworks, etc. At each point, we have optionality – but more and more, the customer pressure is to more deeply integrate the stack, and ultimately deliver the platform outcomes.   I think that’s our primary challenge and the Dell Technologies opportunity. It’s not about VMware, or Pivotal, or Dell EMC – but rather being better together more and more every day. Look at the Pivotal Ready Architecture (PRA) – which isn’t a new thing, or a promise of something the future.   It delivers the industries best kernel mode VM, K8s dialtone, and Cloud Foundry app platform, built on the leading software defined storage, and software defined networking stack all on the best, most economical x86 server platform with a global supply chain that is industry leading. Beyond that – it has the best hybrid cloud model in the industry.   The kernel mode VMs can span into AWS with the VMware Managed Cloud. VMware/Pivotal PKS runs on premises, on AWS, on GCP, and on Azure (shortly). Pivotal Cloud Foundry runs everywhere – today. All the abstractions are in the PRA package. We’re delivering PRA today, and how we deliver PCF ends with the CI/CD pipeline delivering PCF releases that land with a great team that validates, documents on the VMware and Dell EMC stack (VxRail).   We can deliver PRA today in weeks. This represents the full Dell Technologies stack – delivering all the abstractions enterprises need. Read about it here, and check out more here. 

I think that it’s important for Dell, Dell EMC, VMware, Pivotal, RSA, Secureworks and Boomi employees realize that yes, we have different cultures.   Yes, we have open ecosystems.   Yes, that’s important.   The bigger game is how we are better together.

Someone with a more important (certainly higher impact!) perspective than mine talks about it here (Michael Dell on Pivotal Ready Architecture):

 

And perhaps this is the most important “meta” observation – the ultimate “see the forest” comment…

  1. This deal is a proof point that the real battle in the market today – it has changed.   
  2. Customers want choice, and open – but that’s not enough.   They want opinions. They want answers. They want outcomes.   They want platforms.
  3. This means that there will be a few “full stack” platform players left standing.   It means that it’s an untenable position to be a “part of a stack”. That translates to consolidation “IN the stack business”, and “innovation and explosion of diversity ON the platform stack business”
  4. There will be AWS, there will be Microsoft.  There will be Google. There will be Dell Technologies.   There will be a couple mega-platform players from China (you can see this coming).    There may be IBM/RedHat.
  5. Each of us HAS to keep our control points open (god forbid IBM does bind RedHat too closely) – but customers want outcomes.
  6. We’re laser focus on delivering exactly that – and have been doing it (and will keep iterating) for a long time, and a long time to come.

 

1 thought on “IBM and RedHat – seeing the forest for the trees.”

Leave a Reply

Your email address will not be published. Required fields are marked *