“I have no idea, but I’ll go on,” or IBM buying Red Hat
Software Defined Talk LLC·2018-11-01·via Software Defined Talk
Episode 153
·
November 1st, 2018
·
1 hr 25 mins
IBM is buying Red Hat. Topic acquired.
Sponsored by DataDog
This episode is sponsored by Datadog and this week Datadog wants you to know about Watchdog.
Watchdog automatically detects performance problems in your applications without any manual setup or configuration. By continuously examining application performance data, it identifies anomalies, like a sudden spike in hit rate, that could otherwise have remained invisible. Once an anomaly is detected, Watchdog provides you with all the relevant information you need to get to the root cause faster, such as stack traces, error messages, and related issues from the same timeframe.
Look, Red Hat and IBM are Pivotal competitors, good ones: we wish them success in this complex integration, it’s good they’re finally trying to fix their cloud portfolio, we’re hiring, etc., etc.. Let’s take it for mature-granted that we’d prefer enterprises be Pivotal customers than IBM/Red Hat customers. Now, let’s put that aside.
First, this is a bold, good move. Acquiring Red Hat has always been a hill too high and it’s kind of mind-blowing that someone actually did it. The valuation here is sort of besides the point of anything impressive. In contrast, the GitHub valuation was impressive because GitHub is a one product company (please don’t email me about “community” as a separate product - sure thing, I agree). Red Hat is kind of everything IBM has missing…except public cloud.
To be, I guess, contrarian and annoyingly not Pivotal-biased, I think it’ll be hard for IBM to fuck this up.
On that last point, Ben Thompson: “The company has spent the years since then claiming it is committed to catching up in the public cloud, but the truth is that Palmisano sealed the company’s cloud fate when he failed to invest a decade ago; indeed, one of the most important takeaways from the Red Hat acquisition is the admission that IBM’s public cloud efforts are effectively dead.”
In other word, IBM is too late to catch-up to public cloud co.’s, it’d need to spend lots of capex to get close.
Related, sick nerd burn: “Meanwhile, [IBM’s] aforementioned commitment to the cloud has mostly been an accounting fiction derived from re-classifying existing businesses”
Fixing IBM’s cloud business. What was wrong in the first place?
Things Red Hat has: RHEL revenue, JBoss developer presence, product/developer know-how, support know-how, OSS good-will, OpenShift as a k8s distribution:
RHEL & IBM has a foot-print in most all enterprise stacks, but not public cloud(?)
IBM knows how to eek out OS revenue, so does Red Hat.
JBoss + WebSphere. At some point, IBM had a huge developer community. They likely do among enterprise developers (but even there, it’s been fading). Red Hat has developers - I assume. People do like kubernetes.
The know-how and good will are interesting - added to IBM’s OSS equivalent (they still have that?) you have, potentially, the biggest OSS people around…? I’m not sure which standards bodies this allows them more control over, no which projects. Google and Microsoft are contenders here too.
“Lock-in”:
From the press release: “research shows that 80 percent of business workloads have yet to move to the cloud, held back by the proprietary nature of today’s cloud market.” (No citation provided. I will assume it’s from the Anonymous Galactic Research Board Whose IP Licensing Policy Prohibits Your From Citing Us By Name Because We Prefer to Peacefully Float In Space Like Those Rasta Dudes in William Gibson Books But The Good Early Ones Not The Weird In The Present Ones Except For the Blue Color of Bigend’s Suit Which Was Actually Pretty Cool - But Cuban Parkour Ninja Cults? Boy.)
See also: Turns out Pareto was some kind of every single study ever genius. Shut it down, boys, turns out every survey result ends up in an 80/20 split.
As ever, this topic vexes me. I take lock-in to mean:
I don’t want to keep paying this rent-seeker, aka, “maintenance contracts - AMIRIGHT?.” I’m just interested in paying less. If you gave me a closed source offering that was free, I’d be just as happy.
I don’t want to get trapped in an aging stack that isn’t evolving (e.g., I want to use node.js on UNIVACs, or something), so I need “the freedom to leave” to get the benefits of new technologies.
I like having the source code for transparency, to make my own forks, and/or because rainbows and sandals.
Like, seriously, what options do you have to move to?
DIY stack - you’re going to take the IBM/Red Hat stack and run it all on your own, merging in new releases and patches, even forking and evolving it yourself. Will all the IBM stuff be available? What if you run on VMware or Azure or Softlayer? How do you rebuild that entire stack? So you just want to rebuild a little bit of it? If you throw OpenStack with KVM in there, plus whatever SDN and storage stuff you could get in open source, throw in some OSS network routing…you could get away with the only proprietary thing being chips and other rando hardware things. You’ll need some bare-metel BIOS/firmware update things.
Begged question: how far (and up!) the stack do you want to be un-proprietary? Only use OSS Android on jail-broken phones? No iPhones, clearly, and toss out Safari, macOS, and Windows - maybe you can cruise in with some HTML5 stuff through Firefox and Chrome on the desktop and mobile, then on some Eclipse for GUIs?
AWS, Azure, Google Cloud, AzureStack, Pivotal ready stack with VMware - perhaps you could take the thin k8s and PaaS layer from the Red Hat IBM stack and move it to those clouds? Will that work? Is it better, economically and innovation roadmap-ally than just sticking with IBM/Red Hat
Alibaba and the other non-Western clouds. Same.
MSPs like Rackspace. Maybe - the Rackspace people could just run whatever you want. See concerns of #1, plus the premium paid for “fanatical.” Maybe Rackspace has some SRE magic that allows them to do what you’d be doing at 80% of the cost, or something.
I don’t understand this reasoning. How is IBM + Red Hat lack of “proprietary nature”? If I’m running an IBM/RedHat stack, can I just move off all my workloads over night, paying nothing to move and then run my workloads, like, perfectly? If I’m running on that stack, and then I want to move to Google Cloud, does that work? Where-else would I go? Can I just take my pods and throw them onto Azure?
Also, if any of these are practically true - it’s a shitty business for IBM/Red Hat to be in, at least a huge risk for them to carry. Any time a customer cashes in on freedom to leave, that’s lost revenue to IBM/Red Hat.
My point is: I wish we’d stop talking about lock-in and focus on more practical matters, namely, does the technology work, does it work in a good ecosystem/community (I can find and make it work with other stuff), does it evolve/innovate at a pace I like, and am I happy with the initial and ongoing costs. If the answer to all of those is yes, I don’t think people care about OSS versus closed. But what do I know, I don’t know such stuff, I just do slides.
What really matters is getting the two sales forces to sell each other’s stuff, esp. accelerating OpenShift. The IBM sales force has to sell moving away from their traditional offerings (WebSphere, 3 tier, etc.) and instead sell modernizing to OpenShift. That’s fine, but a lot to ask. Also, the comp. plans might get dicey. Part of the point of modernizing is to reduce costs, implying a lower up-front deal-size and smaller ongoing deal-size. So, you’re asking the IBM rep to sell cheaper products, potentially. And if you’re not, see lock-in screed above on pricing. There’s not much upside to sales people here, aside from maybe holding onto an eroding market, but that’s years out, sales people are short-term focused by design. Red Hat sales people might fare better because they’re used to that deal size and can sell more; however, IBM sales people will resist these Red Hat people getting into their account and snatching their paper. All of this is not a killer, but likely the bulk of work that needs to be nailed to synergize maximally (my favorite type of synergizing).
