The cornerstone of effective, scalable, cloud native development is establishing a personal laboratory, which is the focus of this chapter. This space serves as a secure playground for innovation. Your laboratory is your development environment, typically a local workstation or laptop, where you have the freedom to experiment, iterate, and rapidly observe the results. You may do this yourself, or if you are using pair programming, with a partner.
Given that your laboratory explorations will mainly involve coding, the quality of your developer experience (DX) can make a big difference. It plays a crucial role in streamlining work and driving productivity.
The primary objective of the laboratory in cloud native development is to produce a recipe for generating a containerized microservice. This recipe should be designed so that it can be seamlessly transitioned to the factory, preparing it for real-world, production deployment.
The secret to individual productivity and effective local development lies in optimizing inner loop agility. This term refers to the time taken between writing code and validating the results. The key is to minimize this duration as much as possible, allowing for rapid testing, feedback, and improvements. By enhancing your inner loop agility, you can quickly iterate and evolve your code, ultimately accelerating the pace of your cloud native development.
Note
The code for this chapter is in the laboratory folder of the GitHub repository.
The Inner Loop
The software development process can be visualized as two distinct loops, both pivoting around the central act of pushing updates to source control.
The right diagram in Figure 10-1 represents the outer loop, which is initiated once the revised code is pushed to the source control system. This phase incorporates the integration of new code and its testing against the preexisting code base. I cover this in Chapter 12.
Figure 10-1. Inner loop
The inner stage is your day-to-day work. It consists of three steps: write code, build it to a testable state, and run the tests. The starting point might change if you’re using test-driven development (TDD).
You write code, build it to a state where it can be tested, execute the test, and then repeat the test. Of course, in TDD, the starting point is a failing test rather than code, but the loop is the same either way.
You will likely go through these micro feedback loops hundreds of times daily as a developer. The shorter the loop, the more productive you will be. The better your tests are, the earlier you can run them and the earlier you find bugs. However, your tests must run fast, so your feedback loop remains short.
Let’s see how Google Cloud helps us build a short inner loop that forms the laboratory’s core.
Tip
I find it liberating if my inner loop runs efficiently on a modest laptop. This means I can be productive wherever I am without worrying about my battery life. It is also great for that all-important carbon usage.