What comes next after Kubernetes in app-infrastructure?
Jonas Bonér, CTO and co-founder at Lightbend, said, there is a huge gap between the infrastructure and building a full application. This means that, in the near future, they will need to add more tools in the toolbox and to extend the infrastructure model of isolation into the app itself, creating a powerful, yet simple, programming model.
But when a technology has reached a certain level of trust, it’s well-understood and easily managed, you can say that it is ”boring”, thus paying it the best compliment there is. Kubernetes has become just that: it is a standard cloud-enabling plumbing that ”works.”
Tesla, for example, relies on “digital twin” capabilities that power its electric grid, capabilities made possible by the combination of Akka and Kubernetes. Colin Breck, a Tesla engineer, says ”The majority of our microservices run in Kubernetes, and the pairing of Akka and Kubernetes is really fantastic”.
What are the unsolved areas on the cloud-native stack, that are evolving above Kubernetes? According to Boner, there are three: application layer composition, stateful use cases, and data-in-motion use cases.
Stateful use cases
Most of the cloud ecosystem is mainly tackling so-called 12-factor style applications. In the cloud, you’re forced back to the three-layer architecture of pushing everything down into the database every time. This happens unless you have a good model and the tools supporting it.
“The value is nowadays often in the data, and it’s often in the stateful use cases that most of the business value lies — making sure you can access that data fast, while ensuring correctness, consistency, and availability.” Boner says.
Data-in-motion use cases
The Kubernetes ecosystem doesn’t yet offer great support for streaming and event-based use-cases.
“Serverless gets us closer to addressing the problem of extending the model of Kubernetes into the application itself. That’s what it’s all about. Abstracting away as much as possible, and moving to a declarative model of configuration rather than coding, where you define what you should do and not how you do it.” said Boner.
Application layer composition
“People too often use old tools, habits, and patterns, often originating from the traditional (monolithic three-tier) designs that inhibit and constrain the cloud model delivered by Kubernetes,” Bonér says. So what needs to be done is to extend the model of containers, service meshes, and orchestration all the way up to the application/business logic. This way, we will leave the developer with the essence: the business logic and its workflow.
All in all, ss the cloud-native stack continues to evolve above the Kubernetes infrastructure level, it will be interesting to see how these concepts play out to serve specific language developers.
Read more on the topic here: https://www.infoworld.com/article/3567648/what-comes-after-kubernetes.html