Due to container-orchestration platforms like Kubernetes and Red Hat OpenShift, developers have become very efficient about deploying and managing distributed and containerized applications. But can we say the same about application development and testing?
In this article, I briefly discuss how cloud-native development is transforming the traditional development cycle of coding, building, and testing. I then introduce the idea of testing on production, not as a meme but as a necessity. Finally, I introduce Istio Workspace, a tool for developers working with distributed systems running on Kubernetes or OpenShift.
Note: This article includes a video demonstration for testing on production with Istio Workspace, you can find it at the end.
Cloud-native redefines the inner loop of development
Those of us who come from a traditional background of working on self-contained systems (also known as monoliths) are accustomed to certain things: Running our applications locally, having instant access to the entire codebase, and being able to debug and reason about the application with ease. We are so spoiled by the undisturbed, inner-loop development cycle of coding, building, and testing that we take it for granted. Figure 1 illustrates the inner loop of a traditional development cycle.
These days, when embracing the new world of containerized, cloud-native applications, we want the traditional activities of inner-loop development to be available out of the box. But, in addition to convenience, these technologies introduce layers of complexity. The cloud-native inner loop has to accommodate activities like building and pushing images, and deploying new services, as shown in Figure 2.
Each of these new activities adds time to the development process. Most developers would rather spend that time doing interesting things, not waiting on the build process. Luckily, we have plenty of tools to shorten the development cycle, improve productivity, and provide faster feedback. Microservices are not that new, nor are containers and their orchestration platforms. Some of these tools require changing the traditional application infrastructure, and adopting new technologies comes with a learning curve—but that's the exciting part.
The challenges of testing locally
Testing new functionality before it reaches production has always been hard, but the shift from monoliths to microservices has brought scale, which has increased the challenge of testing locally. We see developers trying to use tools like Red Hat CodeReady Containers or Minikube to spin up whole applications composed of multiple services. While this approach works well when projects are relatively small, it's not so easy when you introduce more fine-grained services, and the graph starts to grow. It is not feasible to spin up even a medium-sized distributed system on your own machine.
Using replicated environments such as staging or quality engineering (QE) gives some confidence, but it's expensive in terms of both cost and maintenance. Despite the effort of defining infrastructure as code, there are still potential differences in the target machines' configuration; they just show up on the operating system and hardware level. It is also frequently impossible to get the same load and volume of data on the test system that is in the actual system. Therefore, testing on production is no longer a meme: It's a reality and a necessity.
What's needed is a way to use your favorite tools to develop, build, and debug your code locally, but have your application behave as if it were running in the production cluster.
Testing on production with Istio Workspace
Testing on production sounds scary and dangerous because a lot of things can go wrong. One thing to worry about is the impact on regular application users. Fortunately, Istio Workspace supports testing on production in an unobtrusive way. It lets you test your changes without users noticing a glitch.
In the following video, we introduce Istio Workspace as a tool for developing and testing distributed systems running on Kubernetes or OpenShift, while leveraging a service mesh. As you will see, Istio Workspace lets you run the service you are working on locally while interacting with other services running in the cluster. All you need to do is invoke ike develop. Sounds interesting? Watch the demo to get a feeling for what you can do with Istio Workspace.
