The Road from Local Development to Cloud Native Kubernetes
Cloud native computing, microservice architecture, containerization and Kubernetes have now solidly entered mainstream DevOps conversations. Developers must now adapt to this fundamental change. While these approaches sound great in principle, when it comes down to implementation, the changes they introduce are non-trivial and extensive. Though these new methods promise faster development, setting up a working “code to production” cycle for a development team takes anywhere from days to weeks — which can mean critical lost time.
“With any new setup, there are two problems that developers need to solve,” says Andrew Phillips, a Product Manager in Google Cloud Platform’s DevOps division, “One, how can a developer view the results of code changes quickly on their development machine, and two, how can they easily get code running in a stable shared environment that’s not on their laptop?” This shared environment is usually a staging or production environment and is hosted in the cloud.
If you’re accustomed to traditional methods, cloud native development presents new obstacles. Configuring the required environments, handling dependencies between microservices, automating test and deployment tasks and tracking the process end to end all come with challenges at every step. But modern tools and patterns can greatly reduce the time it takes to get started with a working software delivery pipeline. Among them are Minikube and Skaffold for local development, and Google Cloud Build for setting up a simple deployment pipeline in a cloud environment. Let’s discuss each of these tools in their context.
Deploying Locally Via Minikube
The first step to developing a cloud native application nowadays is to choose Kubernetes for your target runtime, and that means configuring Kubernetes locally. This is a multistep process of downloading and modifying configuration files. (Tools such as Homebrew, VirtualBox, Minikube and Kubectl can help, depending on what system you’re running.)
Once the local environment is configured, the next step is to run the app locally. Create a Minikube cluster using the minikube start command. This will create a single-node Kubernetes cluster running inside a VM.
With the local environment configured, you’re ready to launch your first Kubernetes app. Typically, you’d have to perform these tasks: first, build a Docker container and tag it. Second, remember to update your Kubernetes manifests to point to the new container image. Third, go back to the command line to execute kubectl run. As you can imagine, this process is tedious and prone to error.
Once the app launches, every time you make a code change you’ll want to preview it locally before deployment. To do this, you’ll need to repeat the steps above all over again. Fortunately, there’s another tool that can bring more control and efficiency to this clunky process.
Skaffold Automates Local Deployments
Skaffold is a tool that helps simplify development in a local environment. It watches for code changes, and once a change is detected, Skaffold automatically initiates the steps to build, push and deploy the new code to a Kubernetes cluster. The benefit is that, as a developer, you can make iterative changes to your code in a continuous manner without having to manually deploy every change yourself. Skaffold can be used in a continuous mode to automatically deploy all changes as they happen, or in a single-deploy mode, where it exits after executing just the change you ask it to deploy. This brings a new level of ease and simplicity to local development and accelerates new feature development.
Skaffold is efficient. It can identify and deploy only the parts of code that have been changed. It works with local Kubernetes tooling or a remote cluster and lets you choose which tools to use for the build, push, and deploy phases. Skaffold and Minikube are helpful tools to automate the build, push, and deployment phases in a local Kubernetes cluster.
Skaffold also includes some cool features. It automatically changes the manifests with new tags as it rebuilds container images, for example. It understands which images have been impacted by a change and rebuilds only the changed ones. And when it’s done, it runs a routine that cleans up the deployed Kubernetes resources.
Deploying in the Cloud
Deploying an app locally is just the first step in your journey to cloud-native development. Eventually, you’ll want to share your code with others, or make the application available to external users by hosting it in a cloud environment. Usually, you would deploy the app to a staging or production environment.
Deploying in the cloud is more challenging than local deployment because deployments happen on a remote cluster, there’s a cloud vendor platform to work with, and all the usual issues that come with authentication and networking. At this stage, you need to find ways to automate and codify the entire process that takes your code from your laptop to the cloud.
Ideally, once a cloud environment is set up, every time the code is pushed to the team’s shared code repository, it should be automatically updated in the cloud. While Skaffold is good to get off the ground in a local environment, there are additional options that are worth looking at to achieve automation in the cloud.
Cloud Build Automates Deployments in the Cloud
Cloud Build is an automation tool that’s part of Google Cloud Platform. Going beyond development on a local machine, Cloud Build lets you run fast, consistent and reliable builds in the cloud, based on a simple build config file in YAML or JSON. Based on the instructions in the config file, Cloud Build builds the source code, runs tests, and deploys the code to a target location. It can also go from a single build on a local machine to multiple builds in parallel in the cloud across numerous projects, all in a matter of minutes.
For advanced use cases, teams can include a cloudbuild.yaml file when setting up continuous integration (CI) using Cloud Build. This allows them to define custom build steps, speed up builds by caching a Docker image, build leaner containers and deploy directly to Google Kubernetes Engine, Google App Engine, on-premises clusters (in alpha soon) or another cloud provider.
“Cloud Build helps developers avoid all the complexity of setting up and managing a CI process on their own,” Phillips said. “It enables developers to configure an automated CI process right from their GitHub repository with a few clicks.” Once integrated you can view the status of deployments right from within GitHub.
Similar to Skaffold’s automated local deployment feature, Cloud Build includes Build Triggers that “watch” for updates and automatically build container images based on a trigger that you define. This reduces manual effort to deploy to the cloud, and lets you focus on development.
The power of Cloud Build is in its ability to tie together the entire process from GitHub to a final cloud target like GKE or Firebase. Cloud Build lets you control and automate the entire process using instructions that are repeatable and easily customizable.
Rather than spend time setting up and configuring infrastructure and tooling, today’s developers should be able to focus on pushing out code fast and enjoying the benefits of cloud native Kubernetes. Tools like Skaffold and Cloud Build take the pain out of build automation by managing the tooling for you and giving you control over the process. This way, you can focus on what’s really important: writing great code.
In this episode of The New Stack Makers podcast, hosted by Alex Williams, founder and editor-in-chief of The New Stack, Michael Winser, product management lead for Google’s Cloud Build, described what CI/CD means for Google as well as the term’s meaning for the software industry.
A Google Product Management Lead on What CI/CD Really Means
