Is Rancher going in the SUSE Box?
- July 10, 2020
SUSE's $600 million (USD) acquisition of Rancher Labs means that the Kubernetes market is heading towards a major decision-point between freedom of choice and solutions tied to an enterprise Linux distribution and its agenda.
For a long time, Rancher has been telling customers that they're committed to open source, and has claimed freedom of choice as a core part of their value proposition. But in hitching their steers to an OS-maker's wagon, will they be turning their back on these principles? We think there's ample reason for Rancher customers to be concerned, and for those evaluating and comparing enterprise Kubernetes solutions to be cautious.
SUSE's CaaS and App platforms, after all, both ran only on SUSE products. Their strategy -- just like Red Hat's with OpenShift -- seems pretty clear: build a tall Kubernetes enterprise application stack -- each layer locked into the one below it, all grounded on an enterprise Linux spin that they control.
Now, the risk to Rancher users is that SUSE will double down on this strategy, copying Red Hat, Canonical, and other Linux providers in closely coupling Kubernetes offerings to their core OS platform. Cloud-hosted Kubernetes service providers have done this too, of course, though in different ways.
(In fact, this leaves Mirantis as the only leading enterprise Kubernetes solution provider still unambiguously committed to providing a zero lock-in platform and empowering customer freedom of choice.)
How could this look? Lots of small changes, with valuable bits moving around from place to place. Red Hat does this a lot: for example, they implemented FIPS 140-2 compliance (use of NIST-certified ciphers for traffic encryption within nodes) in RHEL, rather than OpenShift, locking platform and OS tighter than ever together for users who need this level of encryption.
What will it mean for Rancher users, if it happens? First, there's cost. They'll need to pay for the OS their platform runs on, just like you can't run OpenShift without running Red Hat Enterprise Linux. Every new node adds a fixed (or, on cloud platforms, recurring) charge, plus maybe the additional cost of skilling-up to support a new flavor of Linux. This may not sit well with top developers and IT ops talent, who tend to want control over the operating systems they work with and depend on.
Then there are roadblocks. For example, you might be barred from deploying Kubernetes on certain platform footprints, simply because they can't run the required host OS.
Will all this happen to Rancher users? Only time will tell -- for now, though, we know for sure that lock-in is profitable for (some) vendors, and that others are strongly compelled to try to duplicate that success. We saw this with OS-vendor-driven OpenStack distributions, for example, which became more and more dependent on proprietary OS features and associated services. We see it now with Kubernetes offerings from Red Hat, Canonical, and similar quasi-proprietary spins from every cloud provider.
If this concerns you, please get in touch, and let's discuss the cost and productivity benefits of opting for Kubernetes freedom of choice.
For a long time, Rancher has been telling customers that they're committed to open source, and has claimed freedom of choice as a core part of their value proposition. But in hitching their steers to an OS-maker's wagon, will they be turning their back on these principles? We think there's ample reason for Rancher customers to be concerned, and for those evaluating and comparing enterprise Kubernetes solutions to be cautious.
SUSE's CaaS and App platforms, after all, both ran only on SUSE products. Their strategy -- just like Red Hat's with OpenShift -- seems pretty clear: build a tall Kubernetes enterprise application stack -- each layer locked into the one below it, all grounded on an enterprise Linux spin that they control.
Now, the risk to Rancher users is that SUSE will double down on this strategy, copying Red Hat, Canonical, and other Linux providers in closely coupling Kubernetes offerings to their core OS platform. Cloud-hosted Kubernetes service providers have done this too, of course, though in different ways.
(In fact, this leaves Mirantis as the only leading enterprise Kubernetes solution provider still unambiguously committed to providing a zero lock-in platform and empowering customer freedom of choice.)
How's this likely to roll out?
For a while, current Rancher users will be unaffected: they'll keep running the platform on any OS Rancher currently supports. Gradually, though, economics and profit motives will likely urge creation of hard dependencies between Rancher and SUSE Linux Enterprise Server, gradually limiting customer choice and promoting lock-in.How could this look? Lots of small changes, with valuable bits moving around from place to place. Red Hat does this a lot: for example, they implemented FIPS 140-2 compliance (use of NIST-certified ciphers for traffic encryption within nodes) in RHEL, rather than OpenShift, locking platform and OS tighter than ever together for users who need this level of encryption.
What will it mean for Rancher users, if it happens? First, there's cost. They'll need to pay for the OS their platform runs on, just like you can't run OpenShift without running Red Hat Enterprise Linux. Every new node adds a fixed (or, on cloud platforms, recurring) charge, plus maybe the additional cost of skilling-up to support a new flavor of Linux. This may not sit well with top developers and IT ops talent, who tend to want control over the operating systems they work with and depend on.
Then there are roadblocks. For example, you might be barred from deploying Kubernetes on certain platform footprints, simply because they can't run the required host OS.
Will all this happen to Rancher users? Only time will tell -- for now, though, we know for sure that lock-in is profitable for (some) vendors, and that others are strongly compelled to try to duplicate that success. We saw this with OS-vendor-driven OpenStack distributions, for example, which became more and more dependent on proprietary OS features and associated services. We see it now with Kubernetes offerings from Red Hat, Canonical, and similar quasi-proprietary spins from every cloud provider.
If this concerns you, please get in touch, and let's discuss the cost and productivity benefits of opting for Kubernetes freedom of choice.
