Why Apps Are Fundamentally Different in the Kubernetes Era
In a guest post on The New Stack last week, Spectro Cloud‘s Tina Nolte wrote about the state of cloud computing in the current era of containers and Kubernetes (which she termed “Cloud 2.0”). I found her comments on how applications have changed to be particularly intriguing. In Cloud 2.0:
“Your app looks different. It is architected and built differently. It behaves differently. You don’t generally just take your old workloads and lift and shift them into this world; these applications didn’t exist before.”
Kubernetes encompasses many things — in many respects, it’s the default operating system for the cloud now. But if we look at it just from an application context, it’s really a modern app server. Alexis Richardson, founder and CEO of Weaveworks, said as much in response to Nolte.
K8s is an app server
— Alexis Richardson (@monadic) April 24, 2020
But what Nolte seemed to be suggesting is that the application itself has fundamentally changed in the Kubernetes era — that it’s more than just a change in servers. She noted further into the article that what developers are doing with “microservices and deep platform services” is very different to the old web development model.
I reached out to Nolte to ask if she’d elaborate further on why apps are a different beast now.
“Apps in Cloud 2.0 are cloud native,” she replied. “They are distributed, built to scale up and down with demand, and resilient to failures.”
“This is where Kubernetes really shines,” she continued. “It focuses on the distributed computing aspects of managing an application. This isn’t to say that you can’t lift and shift legacy apps into containers managed by Kubernetes — people do. However, this is generally a step in a journey to get to truly distributed application environments.”
Another thing that makes Kubernetes apps different is that they’re typically a lot more complex, due to their distributed and scalable properties. Add to that, Kubernetes is itself a large and sometimes unwieldy platform. Plus Kubernetes is relatively new, so its ecosystem of third-party services is still being built out. All of this means the developer experience in Kubernetes is difficult at best, fiendishly complicated at worst.
Yet another factor against developers is that Kubernetes is, at heart, an infrastructure platform. While DevOps has bridged the gap between developers and IT teams in recent years, Kubernetes is still more of a natural fit with the latter.
In a podcast last December, respected industry analyst Janakiram MSV told The New Stack, “Kubernetes is considered to be infrastructure and is still the foundational infrastructure for modern applications, but it lacks the context of an application. And that is one of the biggest drawbacks for developers embracing Kubernetes.”
Then there’s configuration to deal with. In a recent article on The New Stack, Emily Omier had described the developer experience on Kubernetes as “a mixed bag.” She went on to note:
“On the one hand, it eases the provisioning and management of complex applications. But it can also quickly throw the developer into a kind of configuration hellscape, and — though this may not be the fault of Kubernetes itself — architectural chaos as different IT teams struggle to incorporate into existing operations.”
All this is to say that the developer experience is much different in Kubernetes, compared to traditional web development.
But let’s get back to Nolte’s original point: that the app itself has fundamentally changed in this era.
There is at least one industry initiative to try and define what a “modern application” is, and thus how it should best be developed. Last October, Microsoft and Alibaba jointly launched an open source project called the Open Application Model (OAM). Janakiram MSV described it as “a specification to define modern applications irrespective of where they are deployed.”
In the OAM application delivery lifecycle, there are three key roles: the web developer, the application operator, and the infrastructure operator (some of these roles may be partly or even fully automated). The following description tells us where the developer fits into the picture:
“To let the developers focus on implementing the application’s business logic, application operators (either human or automated operation platforms) take care of operational tasks. This provides a “serverless” experience to the developers. The developers only need to develop and package the application, and then deliver it to the application operators.”
What’s perhaps most interesting here is that the final app needs all three roles to play their part. It’s no longer a case of simply publishing an app to a web server (cloud or no), something which any developer could easily do in “Cloud 1.0” or prior. Now the developer needs to pass it over to the operators to finish the deployment.
Indeed, you could even argue that the modern web application has essentially become one with the server. A developer’s job may end with the container, but the application itself now extends into the infrastructure and cannot be distinguished from it.
I won’t pretend to understand the level of detail Janakiram MSV gets into in his post about OAM (please read it if you’re a developer), but this extract neatly sums up why apps are just plain different now:
“OAM’s core premise is that the job of a developer ends with building the container image from the source code and an operator’s job starts from there. Ops team is responsible for the configuration and deployment of a set of container images as a single application.”
The problem is that “single application” is made up of a multitude of objects, some of them beyond the ken of developers. It’s the first time in the web’s history that developers don’t have full control over their creations.
The Cloud Native Computing Foundation, which manages Kubernetes, is a sponsor of The New Stack.
Feature image via Pixabay.
