Google’s Cloud Code Plug-Ins Take the YAML out of Kubernetes

As Kubernetes has become more popular, so has the recognition that the developer experience is less than ideal, requiring developers to gain a lot of expertise in operations to become productive. Cloud Code is part of Google’s plan, along with Cloud Build and Cloud Run, to make Kubernetes more accessible for developers, Pali Bhat, Google vice president of product and design, told the New Stack.

“There’s a whole lot of development teams that never had to think about servers in a traditional sense, and now with Kubernetes, they’re thinking about it. What used to happen was developers would develop their app and then throw it over the wall and a sysadmin team would try to deploy it. That was broken,” Bhat explained. “We solved that problem with Kubernetes — except now the developer suddenly has to think about Kubernetes. The genesis of Cloud Code came from conversations with customers telling us ‘I have all these business app development teams that I want to have focus on business logic but unfortunately, they’re now having to figure out how to work with containers and do cloud native development.”

Kubernetes provides programmable infrastructure, but that’s not what developers actually want, Bhat suggested. “Development teams don’t want to think about the infrastructure at all.”

“If we can use things like Cloud Code and Cloud Run to ease the process and streamline the development of cloud native apps then the developer goes back to thinking about just their own code and app but they still get the benefits: the flexibility, the abstractions, the better utilization of their server, the scalability,” he said.

App code, not YAML

Cloud Code is designed to work with Cloud Build and Cloud Run and Knative, which Bhat suggests thinking of as “a great developer experience on top of Kubernetes and Istio.” Google obviously hopes that companies will use the whole chain from CI/CD and automated deployment using Cloud Build to autoscaling and serving from Cloud Run, but you can use Cloud Code to deploy and debug on any Kubernetes cluster.

“It builds both to local clusters but also to remote clusters automatically from their IDE. They can set breakpoints, they can do full debugging and they can do all those pieces within the existing development environment which your developers and appdev teams are comfortable with. It looks like completely local app development but it’s against a live cluster. Using pieces like Skaffold and Jib and kubectl, we’re monitoring it in near real time, so you look at clusters and get live real-time feedback on the entire experience. It gives you that end to end development lifecycle right within your IDE.”

Cloud Code includes a set of samples that are preset to publish to the Google Kubernetes Engine (GKE) and Cloud Run, but admins and development managers can customize those to deploy to their own Kubernetes environment (that uses Google’s Kustomize project. “We let you wire up which cluster you’re targeting and it can be any Kubernetes,” Bhat confirmed.

Developers can still see and customize the YAML files in their IDE, if necessary, and one useful option gives you a diff between a YAML file in source control and the YAML deployed on a cluster. Extensible YAML linting gives immediate feedback on any syntax errors, and again that can be customized for your policies.

Initially, the plugin works with Visual Studio Code and IntelliJ and supports Java, Python and Ruby, but Google is looking at other development environments customers are using, as well as more languages; .NET Core support is already in development but isn’t there at launch, and NodeJS and Go are also coming. This is a pragmatic decision to support the tools developers are already using.

The list of features is slightly different between the two IDEs. With Cloud Code, IntelliJ gets more integration for working with Google Cloud Storage and App Engine while the Visual Studio Code plugin lets developer browse Kubernetes resources, put secrets in volumes and environment variables, monitor and configure a local Minikube cluster, or create clusters in GKE, EKS and AKS without leaving the IDE.

Cloud Code will also integrate with other Kubernetes and DevOps tools in the future, Bhat said. “Over time we’re going to build this portfolio out and build customization abilities for your custom CI/CD pipeline. No two organizations have the exact same CI/CD process; every customer has something customized and tuned to their own needs because app development is such a core part of defining products and services. Our goal is to enable our toolchain, across Cloud Code and Cloud Build, to fit into that experience.”

Cloud Code in IntelliJ uses Stackdriver for snapshot-based production debugging on GKE and the plan is to bring more information back from Stackdriver so developers can see that inside their development environment, while they’re writing code. “What we want to do is ultimately start getting you operational metrics and bring those back into your IDE as well,” Bhat said.

That’s the kind of information that would be particularly useful with something like Visual Studio Code’s CodeLens, which gives you contextual information; seeing the response time for a piece of code in production could make it easier to improve the codebase generally. That’s the kind of developer productivity Bhat hopes the tool will provide for customers.

“The reason they’re going to the cloud is that they want to be more agile, and the way to support that agility is to take all the boring pieces away and automate those pieces and let developers focus on building amazing apps.”