The adoption of Kubernetes clusters within enterprise IT environments is after nearly a decade of effort is most certainly on the rise, but the pace at which cloud-native applications are being built for the platform still lags.
It’s estimated there are more than seven million developers of varying skill levels that can build cloud-native applications out of a pool of 50 million developers that today build enterprise applications. The two primary reasons for this state of affairs are that the cloud-native applications constructed using microservices are harder to build and the tools developers have been asked to master are more challenging to employ.
The best way to make Kubernetes more accessible is to deploy some type of platform-as-a-service (PaaS) environment that abstracts away the complexity. Red Hat, VMware, Porter, Nutanix, Okteto, Platform.sh, DEIS, Gondor and the Cloud Foundry Foundation (CFF) are all making a case for employing a PaaS to accelerate development of cloud-native applications destined to be deployed on Kubernetes clusters. The challenge is that PaaS environments have not been warmly embraced by developers. Many of them find the environment is too opinionated in the sense that they can’t easily add new tools and processes that might help accelerate the development of an application as they best see fit.
The irony of all this is that as more organizations embrace platform engineering, they are deploying more instances of Kubernetes to make it simpler to automate the deployment of application using a consistent set of application programming interfaces (APIs). One of the reasons so many organizations had not previously moved to centralize the management of DevOps is that each platform had its own unique set of APIs.
Kubernetes resolves that issue to the point where enterprise IT organizations are now mandating that cloud-native applications be deployed on Kubernetes to make it possible to programmatically manage IT environments. In some cases, organizations are even going so far as to employ open source kubevirt software to make it possible to deploy legacy monolithic applications as well.
The challenge, of course, is that in addition to the pool of developers that have skillsets required to build these applications is still relatively small it’s expensive to develop cloud-native applications. A recent report from OutSystems, a provider of a low-code application development platform, recently pegged the cost of building and maintaining a cloud-native IT environment is, on average, $5.6 million. More challenging still, the report notes it can take 18 months to achieve that goal, the report finds.
Mandates can also have unintended consequences. More than a few of the applications now being deployed on Kubernetes might have been better served by another platform. Instead of being fit for purpose, these applications are being deployed on Kubernetes clusters either because a centralized IT team required it, or the developer may have been looking to add some skills to their resume regardless of how well an application may actually run.
Given all these challenges IT leaders need to proceed with caution. Initially, a small cadre of elite developers were the primary advocates for Kubernetes but it’s clear the rest of the developer community still needs to be brought around. Developers, if required, will try to build and deploy applications on any platform required but that doesn’t necessarily always mean those projects will turn out well. In fact, the total cost of supporting those applications may very well turn out to be much higher than anticipated, which may make justifying a return on investments (ROI) difficult rather difficult.
None of this means organizations should not be embracing Kubernetes to run highly distributed applications at scale but it’s clear that they should take a good long look for taking that next leap.
