Kubernetes without the Developer Experience
The cloud native computing community seems to coalesce around a single idea: that applications should be distributed across multiple nodes. This approach is essential not only for scalability but also for resilience and continuity of operations. The industry has settled on Kubernetes as the de-facto platform for running these distributed applications, as well as the idea that the process of developing distributed applications should be as possible. As a result, developers should need to know little, if anything, about how Kubernetes — not known for its simplicity — actually works.
In a talk earlier this year, Microsoft Azure Chief Technology Officer Mark Russinovich discussed the challenges that raw Kubernetes bring to the developer, thanks to the inadequate separation of concerns: “When somebody's creating a deployment for Kubernetes, they're mixing application developer concerns in with operator concerns, in with infrastructure operator concerns. And so, as a developer authoring one of these manifests, you've got to know all of these different concepts related to the infrastructure, which distracts you from your core goal, which is to define the application.” In his talk, he was introducing the Rudr runtime application platform, and the Dapr distributed application runtime — two projects to take the worry of infrastructure from the developer’s plate.
And those aren’t the only projects to try to abstract away Kubernetes. Last week, for instance, HashiCorp’s released open source remote access software Boundary that promises to provide an easy way for developers to hook into cloud native services, such as those run on Kubernetes. The old way relied on VPNs, or ssh access, which could compromise a private network with leaked credentials. This approach was also difficult to maintain given that the IP numbers of the needed services might always be changing. HashiCorp instead built access on policy, which restricts access and can be set through Infrastructure-as-code tools.
Microsoft is also working to make Kubernetes easier through its new Akri project. Akri brings Kubernetes to the edge by exposing leaf devices, such as the sensors, cameras, controllers, and microcontroller unit (MCU) class devices that produce data and perform actions. Again, the goal is to take the complexity out of managing these edge devices through Kubernetes. The dev simply instructs Akri what type of device to detect and the discovery protocol needed to do so, then Akri deploys an agent on each node that can discover that specific type of leaf device and exposes those devices to Kubernetes clusters as extended resources.
As the focus of development moves from Kubernetes itself to the cloud experience for the developer, The New Stack will continue to keep you apprised of the latest news.