One of the foundations of cloud native is packaging code as containers. If you are used to developing in noncontainerized environments, you may already have a fast feedback loop. In noncompiled languages like Python or Node.js, getting feedback is a case of making a change and running the code. One of the strengths of Go, for example, is that even though it is a compiled language, it is fast to compile and run. When using Java with Spring Boot, it is also possible to have a rapid code, build, and testing of the local loop, especially when using Spring’s developer tools.
So why slow everything down by adding the complication of containers to the inner loop? Isn’t this colossal overhead? Whereas before you could just run the code, now you have to build a container, push it to a repository, and redeploy it after each code change. I have seen Java developers horrified when they are presented with Kubernetes and have their productivity destroyed as their inner loop goes from a few seconds to minutes due to all the extra steps that containers add.
There is an excellent reason to develop using containers, though; it eliminates the “it runs on my machine” issue. This is also the goal of the dev/prod parity principle of the 12-factor applications. A container is immutable; if it runs in one place, it will run everywhere. This is a valuable benefit because, as I said earlier, the sooner you can find an issue, the simpler it is to resolve. Fortunately, tools can automate and streamline the process, so the container overhead becomes insignificant.
To illustrate, let’s take a Spring Boot development inner loop as an example (see Figure 10-2). Before containers, you would have had three steps: code, build, and test.
Figure 10-2. Spring Boot: code, build, test
Add containers, and you have to build a container image, tag the image, push the image to a container registry, patch the deployment to use the new container image, and redeploy with the new image before being able to test (Figure 10-3).
Figure 10-3. Spring Boot with Docker and Kubernetes
This is where Google provides tools to automate the extra steps and eliminate the overhead (Figure 10-4). The first is Skaffold; this tool automates most of these additional steps. The second is a tool needed for simplifying and automating building the container itself. For Spring Boot, Jib is a good choice, but I will cover more options later.
Figure 10-4. Jib and Skaffold providing automation
Tools like these form the basis of a laboratory as they allow cloud native developers to automate away the overhead of working with containers. Let’s explore some more Google Cloud tools that fit together to support you.
Inside the Laboratory
A laboratory should provide everything needed to execute the inner loop automatically, from making a change in code to testing and getting feedback. You then break out of the loop by pushing changes into source control to be picked up by the factory’s build and testing processes.
The laboratory needs the following:
- An IDE in which to write the code
- A way of building a container
- A place to store built containers
- A way of testing containerized microservices
- A way of testing dependent services
