Dan Illson

Organizations interested in taking advantage of new platforms such as the public cloud or containers often face challenges in adapting their existing applications to these new environments. In this post, I examine a method to adapt existing code without changing its intended behavior, refactoring. Let’s look at what refactoring is, and how it can apply to microservice applications. What is Refactoring? This section could be a full blog post on its own (and I’m sure it already is in multiple corners of the internet).

The Apperati authors been focused on developing the concept of Continuous Verification since we published our first post on it in July. As we’ve discussed it people outside our immediate team, it became evident that a concrete example of these concepts would help to clarify these concepts. As a result, we built a pipeline to demonstrate these ideas. The pipeline was built with the cooperation of our partner GitLab on top of their SaaS offering.

When I began working with Kubernetes, I deployed simple applications from tutorials with very basic YAML manifests into my clusters. As my comfort level with the technology grew, I wanted to deploy more complex applications to continue learning. After creating some YAML manifests from scratch, I felt things were moving too slowly, and I enlisted a common aid for new Kubernetes users, Helm. Helm interested me because it was billed as “The Package Manager for Kubernetes” which fit my needs at the time.

Before I get started, I’d like to give special thanks to two of my colleagues at VMware, Duffie Cooley and Scott Lowe of the Kubernetes Architecture team for helping me think through and better understand this subject. I’d highly recommend following both for their thoughts on cloud native architectures and Kubernetes. Services are one of the most commonly configured and used configuration object in Kubernetes. Through I used them frequently as I was learning how to use Kubernetes, I found recently that I didn’t understand how services interacted with the other objects within a Kubernetes cluster.

This post represents an interesting departure for me. Typically, I cover technical topics related to applications, Kubernetes, and portions of the “cloud native” world. In this piece, however, I’d like to address an issue much more steeped in people and process concerns; cloud operations. My colleagues and I spend quite a bit of time interacting with administrators and operators representing a wide variety of organizations. Whether these conversations begin with a particular set of technologies or projects, the discussion inevitably turns to the differences in operating across public cloud and software-as-a-service environments.