Everybody loves new technology. Just like that shiny toy on Christmas morning, new tech is desirable simply because it’s new.
Software marketers are keenly aware of this ‘shiny things’ principle, and are only too happy to position the most recent addition to the product list as the must-have of the season.
Open source efforts, of course, can be just as shiny – regardless of whether the latest and greatest is really the solution to the business problems at hand.
Over the years, every new aspect of the technology story – software, hardware, methodologies, architectural approaches, etc. – has succumbed to this shiny things syndrome, for better or worse.
Sad to say, usually for the worse. Shininess bears little correlation to the best tool for the job, and given that ‘new’ usually means ‘immature,’ it can often lead decision makers astray.
Today, there’s no question that Kubernetes is so shiny, you need to wear shades just to talk about it. This open source container orchestration platform has soundly out-shined all the competition, and is now the wunderkind of cloud-native computing – which, of course, is plenty shiny in its own right.
The question we must answer, therefore, is whether the excitement around the still-new Kubernetes (and cloud-native computing in general) has gone overboard, leading to the counterproductive shiny things scenario.
Or perhaps – just possibly – we’ve learned our lesson this time, and we’ll be able to avoid overplaying Kubernetes’ hand.
Understanding Cloud-Native Computing
The notion of cloud-native computing may be basking in Kubernetes’ reflected glow, but we must still place the platform into cloud-native’s broader context.
The core principle of cloud-native computing is to take the best practices of the cloud and extend them to all of IT. Massive horizontal scalability, elasticity, pay-as-you-go pricing, and all the other wonderfulness we enjoy with cloud computing should now be a core benefit of the rest of IT beyond the cloud, namely on-premises as well as edge computing.
Furthermore, to be cloud-native, we want to build comprehensive abstractions that let us handle all of this complex heterogeneity beneath a seamless management layer, enabling us to focus on the needs of workloads and the applications they support, regardless of the particular choice of execution environment.
Cloud-native computing thus encompasses all of hybrid IT as well as the world of containers and microservices that Kubernetes inhabits. And that’s not all – both serverless and edge computing fall under the cloud-native banner as well.
It may sound like my definition of cloud-native is so broad that it’s merely a bucket we throw everything into – but that perspective misses the key point: cloud-native brings cloud best practices to this heterogeneous mix of environments and technologies.
In other words, cloud-native hybrid IT brings the best of the cloud to the full gamut of hybrid environments, including legacy and virtualized on-premises as well as public and private clouds.
Just because you’re implementing hybrid IT, however, doesn’t mean you’re cloud native – and the same goes for serverless and edge computing as well for that matter.
Why Cloud-Native Computing Might Be Different
What does this exploration of the finer points of cloud-native computing have to do with the shiny things problem? It acts as an antidote.
Kubernetes on its own (without the rest of the cloud-native context) is plenty shiny. Developers and infrastructure engineers are only too happy to focus on all the new and cool parts of the Kubernetes ecosystem at the expense of all that dull, boring tech that came before.
But taking that shiny things path is inherently at odds with the cloud-native story. Cloud-native by design abstracts both shiny and dull, new and old, cloud and on-prem, modern and legacy.
No organization can ever become cloud-native simply by answering the question, ‘how can we leverage Kubernetes at scale?’ Instead, people must ask questions like, ‘how can we bring Kubernetes, on-premises virtualization, and everything else we’re doing under a single comprehensive abstraction in order to achieve the benefits of the cloud across our entire IT landscape?’
Answering that question will lead you away from shiny things, not toward them.
Keeping the Vendors away from Shiny
The risk of the shiny things syndrome to enterprises is choosing inappropriate, often immature technology for the wrong reason. For the vendors peddling shiny things, however, the risks are more subtle.
We could think of the ‘washing’ metaphor (as in ‘cloudwashing’) as a kind of vendor-centric shiny things problem. For example, we might coin the term ‘Kubernetes-washing’ to refer to vendors who rush to stick the term Kubernetes on their products, even though their Kubernetes support may be mostly theoretical.
In fact, ‘cloud-native-washing’ may be a bigger problem than ‘Kubernetes-washing.’ I’ve already seen several vendors slapping ‘cloud-native’ on their old tech, where what they really mean is that the tech might run in the cloud, or perhaps works with software that does.
There is more to cloud-native than running in the cloud, of course. For a vendor’s product to qualify as cloud-native, the vendor must rearchitect it to take advantage of modern cloud best practices, which typically (but doesn’t necessarily) mean reworking it as containerized microservices.
But even rewriting a piece of tech as microservices isn’t sufficient. The technology must be able to support and take advantage of the comprehensive abstraction that cloud-native computing requires.
For example, there are plenty of zero-trust security solutions on the market today. But in order to be cloud-native zero-trust, a product must fully abstract the physical network, including IP addresses, VLANs, etc.
In the cloud-native world, workloads – and the people that manage them – shouldn’t have to care about such details.
The Dreaded ‘Embrace and Extend’
In addition to cloud-native-washing and Kubernetes-washing, furthermore, there is another nefarious side effect of the shiny things syndrome on the horizon: the dreaded ‘embrace and extend.’
With embrace and extend, a vendor takes some open source software and creates a proprietary offering on top of it that is incompatible with other vendors’ proprietary offerings, as well as with the plain vanilla open source product itself.
Embrace and extend was the primary tactic the vendors fought with on the browser wars battleground of the late 1990s, and has also given us multiple, generally incompatible versions of Linux.
There are indications, however, that Kubernetes may be different. True, there are already many flavors of Kubernetes out there. Red Hat (IBM), Pivotal (VMware), Google, Microsoft, and AWS to name a few all offer their own flavors of Kubernetes.
Unlike Linux and other earlier open source efforts, however, the creators of Kubernetes designed it to be extensible as opposed to customizable – giving vendors the ability to embrace and extend the core open source platform without creating versions that would be incompatible with the other versions.
But of course, vendor lock-in is the reason so many vendors leverage shininess to convince customers to buy their proprietary gear. Having a proprietary version of Kubernetes that customers get locked into might be a huge win for the commercial Kubernetes leaders.
Will they fall for their own shiny things syndrome and build incompatible versions of Kubernetes in spite of its inherent extensibility, or will they divert their eyes from the shine and build out tech that supports full compatibility with other Kubernetes flavors?
Only time will tell. Unfortunately, there are already indications that at least some of the big Kubernetes players may be falling for the shiny things syndrome.
The Intellyx Take
Enterprises who are committed to becoming cloud-native should have nothing to do with such incompatible implementations of Kubernetes (or anything else, for that matter).
After all, cloud-native means building an abstraction across all environments that supports compatibility and portability. The last thing anyone wants to do is have to extend this abstraction across different flavors of Kubernetes, simply because the vendors in question don’t want to play ball.
There is hope, of course. Enterprises vote with their wallets. If a vendor is working at cross purposes to your organization’s cloud-native priorities, simply take your business elsewhere.
The smart vendors will get your message. The others? You don’t want to do business with them anyway.
Copyright © Intellyx LLC. Intellyx publishes the Agile Digital Transformation Roadmap poster, advises companies on their digital transformation initiatives, and helps vendors communicate their agility stories. IBM is an Intellyx customer. Microsoft and VMware are former Intellyx customers. None of the other vendors mentioned in this article are Intellyx customers. Image credit: Lisa Brewster.
