SUSE Acquire Rancher Labs

Jul 9, 2020| Daniel Jones

Yesterday SUSE announced that they are to acquire Rancher Labs, the folks who have helped thousands of customers deploy Kubernetes just about everywhere.

What it means for the market

This makes for an interesting marketplace. We’ve got VMware, who went on a spending spree to give them everything they need for their Tanzu initiative. IBM bought Red Hat and with it Openshift, and now SUSE have undeniable Kubernetes credentials with the Rancher acquisition. Several big players all with competent offerings, presumably all going for the same market.

Notably, these folks are all offering insurance against vendor lock-in. For all the announcements of SomeBank partnering with ThatCloud, they’re all eyeing multi-cloud strategies.

What it means for SUSE and Rancher Labs

It’s a nice move for SUSE. I can imagine that historically they’ve been great at selling to Derek, who has been managing SLES servers in BankCo for the last 25 years, wears a tie and spends most of his day in Excel or Service Now.

Through Rancher, they’ll now have access to Taylor, who works for a microservices-oriented startup, drinks cold-press coffee and writes YAML all day.

SUSE get a route into the young and hip market (to go with their young and hip cloud CTO), and the credentials of one of the most visible forces in the Kubernetes ecosystem. Rancher get into the world of the enterprise, with its long sales cycles, and risk-averse nature.

What it means for SUSE CaaSP

SUSE already have a Kubernetes offering, called SUSE Containers-as-a-Service Platform. Or CaaSP, which is mercifully shorter.

As my colleague Jessica Stenning recently discovered, deploying CaaSP isn’t quite as straightforward as one might hope for. Presumably now this can be sun-setted in favour of Rancher Lab’s hugely popular solution.

What about Cloud Foundry?

SUSE have teams of folks working on KubeCF and its commercial flavour SUSE Cloud Application Platform, as well as the rather spiffy Stratos UI. What will happen to these products, and to these folks?

An Optional History Lesson

SUSE bought out the part of Hewlett Packard Enterprise (HPE) that created HPE Helion, a BOSH-less Cloud Foundry distribution. HPE in turn bought these folks from ActiveState, where the Cloud Foundry distro was called Stackato, and presciently also forewent BOSH.

I should imagine that Rancher Labs’ engineering crew is much bigger than the CAP team. Rancher Labs’ CTO Darren Shepherd is on the record as not-loving efforts like the Open Service Broker API, and I expect that extends to Cloud Foundry, too.

I get this - Rancher Labs is stock full of infrastructure engineers who are down with the cloud native hotness. I’m sure that for them, kubectl and YAML are a perfectly acceptable way to get business value delivered.

I’m kinda in agreement with him on the OSBAPI front. It’s not a very Kube-native mechanism for doing things, and seems oh, so manual. You could make the same argument regarding cf push - does it have a place in the GitOps world?

These views miss something though - empathy for the typical enterprise developer.

kubectl should absolutely not be the interface for app developers to consume a platform.

Folks who think developers should have to wrestle with the tens of first-class concepts in the Kubernetes API, and worry about it’s not-secure-by-default approach, are deluding themselves as to the number of concerns app developers already have. Developers don’t need more to worry about.

An abstraction is needed. Ideally one that’s self-service and exploratory. That same user experience doesn’t need to persist all the way to production (I don’t want humans doing stuff in prod!), but it needs to exist somewhere.

An Opportunity

Cloud Foundry, if it hurries up and moves with the times, should be ’easy mode’ for Kubernetes.

• Developers: don’t want to faff about with kubectl to push code? Then ask your operators to install Cloud Foundry!
• Operators: don’t want app developers screwing up your carefully-configured cluster? Give them access to Cloud Foundry on a cluster instead of kubectl!

What if KubeCF/CAP and Stratos end up being an optional feature when deploying a Kubernetes cluster with Rancher? It’s a value-add for those situations where you don’t want app developers getting down and dirty with kubectl.

An Opportunity Missed

Want to know what scares the hell out of me though?

Being here in five years, and finding all the industry has done is swap out VMs for containers. Finding that we still have a separate (not) DevOps team that pipelines the apps made another team.

As an industry we need to get over the new shiny, and keep a darned eye on lead-time-to-production, flow efficiency and the amount of effort it takes to achieve business outcomes.

Good for Them

It’s great news for SUSE, and presumably there will soon be lots of people at Rancher Labs diving into swimming pools filled with money. Not to mention all the tasty enterprise accounts they’ll now have access to.

Let’s hope that this another of the steps that accelerates the industry to a place where Kubernetes is a given, and we can focus on how to be more productive.