Cloud Native / Development / Kubernetes

Cloud Foundry Summit: Kubernetes Must Do Better by Developers

2 Aug 2021 9:45am, by

Kubernetes remains a source of concern — and bother — for developers, when they must devote an inordinate amount of time and resources to ensuring their code will run correctly on Kubernetes clusters. In the worst case, developers must also reconfigure their code to meet the demands of different cluster environments. Ultimately, the idea is to allow developers to do their software engineering magic, while Kubernetes, as an infrastructure layer like, for example, virtual machines, is not something that developers should have to struggle with as much in the future, according to speakers at the recent Cloud Foundry Summit.

“The rush of developers onto Kubernetes was a little bit of… I would say… a red herring. Kubernetes is an infrastructure abstraction, similar to virtual machines in many ways: it’s extraordinarily powerful and is absolutely the next version of infrastructure that is going to be common across all clouds and on-premises infrastructure environments,” Cloud Foundry Foundation Executive Director Chip Childers said during the Q&A session ahead of Cloud Foundry Summit 2021. “It has a lot of potential, and we’re seeing that potential being fulfilled as it gets adopted throughout the market, but it’s infrastructure.”

During the Cloud Foundry Foundation’s virtual summit, the theme of Childers’ comments and keynotes, as well as a number of talks, were about Cloud Foundry’s mission to help lower the barriers of entry and improve processes for developers working in cloud native environments. Cloud Foundry’s support for cloud native initiatives largely consists of its open platform as a service (PaaS) offerings, but it also seeks to foster partnerships and collaborations, as well as to instill values and culture in DevOps, including promoting diversity.

However, despite progress made, developers that choose to interact directly with Kubernetes, are “finding that they have to do an awful lot of work to go from their code to [deploying] software,” Childers said. “The operations of that software is not application-aware and if you’re working with Kubernetes directly, it’s more about the discrete kind of infrastructure abstraction components.”

In other words, more work needs to be done for Kubernetes to become more developer-ready, meanwhile, tool makers are stepping up. “This service you need to describe it in terms of its infrastructure needs,” Childers said. “So, there’s almost a Cambrian explosion of new approaches to making developers’ lives easier.”

As a means to help improve the developer experience for Kubernetes, Cloud Foundry released cf-for-k8s v5, which combined Cloud Foundery’s developer API with Kubernetes, Istio and other open source tools and platforms, during the week of the Cloud Foundry Summit. The fifth version of cf-for-k8s, while applicable for large enterprises, was particularly designed with the needs in mind of smaller organizations and developer teams, as well as individual developers, with the addition of new operational capabilities for users. According to Cloud Foundry’s documentation, the release helps to improve the upgrade process for underlying Istio service mesh networking components, as well as for the latest-generation Paketo buildpacks.

The “bumps” in capabilities for version five of cf-for-k8s include improvements to the core API, authentication and access control servers, “which bring a bunch of new capabilities, unique to running in the Kubernetes environment,” Childers said. More specifically, as communicated in the documentation, support for Kubernetes clusters covers the K8s version range of 1.18-1.21. The Istio 1.10.2 bump consists of the cluster version range increased to include Kubernetes 1.21.

As Childers noted, Istio service mesh is certainly “notoriously difficult” to upgrade and install, while the improvements to cf-for-k8s were largely in support of the operation teams, as well as for developers.

“The goal of Cloud Foundry has always been simplification of the underlying technology for developers, but also for operators, and as the developer and operator persona has come together in a smaller environment where a developer is actually doing the installation of Cloud Foundry,” Childers said. “It’s very important that we can make those upgrade cycles very easy. And so a lot of work went into making sure that the upgrade to the underlying Istio service mesh happens very smoothly.”

Another key upgrade includes improvements to Kpack v0.3.1 and support for new buildpacks, while Childers described Kpack as “the magic behind the Cloud Foundry buildpack process or the process of building containers from source code. Based on the Heroku cloud platform, improvements to buildpacks are thus a key component in Cloud Foundry’s support of cloud native developers.

“Buildpacks is a concept that is the magic sauce that goes from your source code to a container image,” Childers said.

Because buildpacks are programmatically built in a way that can recreate a container, they also provide operational benefits within the platform. These include being able to replace what would traditionally be operating system libraries in order to patch entire fleets of applications as an operator versus having to go back to the developers and ask them to recompile, Childers said.

“Buildpacks are really powerful, and they’re being adopted now across most of the CI/CD tools that are out there,” Childers said. “They are now a first-class citizen and are being used in many of the hyperscale cloud provider services. And so this model that Cloud Foundry has been using for a long time is now becoming one of the more attractive ways for developers to interact with a tool that then interacts with Kubernetes to deploy themselves. I think we’re going to continue to see developers shift from thinking about who has the environment that makes sense for them to work directly with, and they’ll think about Kubernetes as the way that infrastructure is presented, but they’re looking for the tooling that will either sit on top of, or sit next to, and push, finished containers into Kubernetes.”

The Wasm Equation in Cloud Native

Virtual machine language WebAssembly (Wasm) was originally created to help improve code efficiency for web applications. Its use and application have since expanded into the purview of cloud native computing — this includes its increasing integration into Kubernetes environments by serving as an API gateway for Envoy configuration and management. By combing JavaScript (JS), C++ and Rust into a single runtime platform, Wasm’s creators are continuing to widen its scope for use for cloud native deployments, including edge Kubernetes, as well as service mesh support.

For Cloud Foundry users, this means that Wasm provides “a polyglot kind of nature of computing, where you can have different languages that can come into play and then they can just be compiled into WebAssembly runtime,” Shashank Mohan Jain, a chiefs architect, with SAP, said during his talk “An Introduction to WebAssembly.”

For service mesh, for example, Jain said WebAssembly can allow for “all kinds of filters, and other logic to be built into the Istio world.” Jain also showed in a demo a browser-based scenario where Rust-based code was compiled into WebAssembly with functions defined and exported before being executed in the browser.

Culture Matters

The use of the best tools and practices from Cloud Foundry and other sources in the best way possible is obviously not enough alone to achieve cloud native, as well as DevOps, goals in general. Developers’ creativity and the best use of their talents also hinge on cultural aspects of the job, which include promoting diversity, preventing burnout and implementing other important factors. Simply eliminating job tickets DevOps teams must contend with is but one example of improvements fostering a more healthy working environment, Kerry Schaffer, senior director of information technology for marketing and communications services provider OneMagnify and a Women’s Security Alliance board member, said during her talk “15 mins with Kerry Schaffer from OneMagnify.”

“Removing the need for our tickets decreased the operational toil and it increased [DevOps team members’] ability to deploy during business hours because of the way that containers work, and that actually meant we had faster results for our clients,” Schaffer said. “For developers, that meant fewer after-work hours.”

Schaffer also said she was “passionate” about trying to increase the number of women in IT, both through her work at OneMagnify and as a Women’s Security Alliance board member. “It was alarming to me when I found out that the number of women going into IT is dropping year over year from 1985, which just seems crazy because there are great jobs, and great career opportunities for women in IT,” Schaffer said. “And when you look at what happened in 2020 with the COVID 19 pandemic, we’ve actually seen more women drop out of the workforce.”

The New Stack is a wholly owned subsidiary of Insight Partners. TNS owner Insight Partners is an investor in the following companies: MADE, Bit.

A newsletter digest of the week’s most important stories & analyses.