When SUSE, the world’s largest independent open source company, announced its acquisition of Rancher Labs in early July 2020, the industry took notice. Clearly, the Kubernetes management industry is very much alive. But, the merger also raised the question of what this means for users? After all, a key value proposition of cloud native technologies, like SUSE, is that they are modular, interoperable, and flexible.
What’s at stake from consolidation?
Are we experiencing a paradigm shift? Certainly, we’ve witnessed a change in enterprise technology as all-in-one solutions -- like those from Microsoft, Oracle, or IBM -- that lock companies in are being increasingly sidelined in favor of modular, flexible, IT systems bundled together by interoperable cloud native modules (in a tech-agnostic way such as Rancher or Kublr).
Although cloud native can increase implementation complexity, it offers unprecedented flexibility. This flexibility allows businesses to quickly adapt to future needs, without being locked into those all-in-one solutions.
But industry consolidation puts this flexibility at risk. Platforms that have embraced an agnostic approach are being absorbed by more traditional IT business models. This negates the very benefit of cloud native. Although these acquirers may promise that nothing will change, history usually proves them wrong. They expect a return on their investment, and this means leveraging their association with cloud native to sell more of their own solutions.
How will the newly joined forces of SUSE and Rancher play out? Rancher users may find themselves tied to a certain operating system, as Red Hat users are. Furthermore, SUSE’s CaaS and App platforms only run SUSE products. Will SUSE keep its cloud native promise? We’ll have to see.
How to maintain vendor independences, despite consolidation
As the industry continues to consolidate, what options do enterprises have to avoid lock-in and maintain vendor independence?
First, they must ensure that the Kubernetes distribution that they select doesn’t lock them in. The market is flooded with distribution options, some of which tie their customers to a tech stack or infrastructure that makes it hard to switch. Vendors may come and go, but if the underlying platform doesn’t lock the enterprise in then it’s free to migrate to another platform if the worst happens.
Warning signs of Kubernetes distribution lock-in
When researching options to avoid lock-in, organizations should keep the following warning signs in mind.
- Forked Kubernetes - These platforms include proprietary features that are incompatible with upstream Kubernetes or other vendors and will lock-in any apps that are deployed on them.
- A vendor provisioned Kubernetes cluster that relies on the vendor platform - In these instances, the Kubernetes cluster can’t survive or be used without vendor-specific components or licenses.
- A lack of portability in the target environment - For example, the enterprise is limited to a single cloud for managed Kubernetes or only a specific operating system is supported.
- A lack of cluster deployment uniformity across environments - When a vendor uses managed clusters provisioned by other tools.
Summary
Market dynamics are beyond anyone’s control, but organizations can pursue a strategy that enables them to flexibly pivot without being held hostage to the forces of consolidation. With cloud native technologies, vendor lock-in is a thing of the past.
Here at EastBanc Tech, we've implemented Rancher, PKS, AKS/EKS/GKE, and of course Kublr which we built because the solutions on the market didn't fully meet enterprise needs. Since we've been building modular, flexible architectures long before cloud native shook up the world -- it's deeply ingrained in our team's DNA -- we designed Kublr not to lock users in. Otherwise we'd be contradicting our own advice.
Need help jump starting your Kubernetes journey? Set up a free consultation with our Kubernetes experts -- no strings attached!