When I first heard about this position and learned that it entailed writing blog posts, little did I know that I would be introduced to an expansive breadth of topics and given the autonomy to explore often overlooked questions of the latest trends in the cloud-native ecosystem. I’ve had the amazing opportunity to work directly with and learn from Dominik Tornow, Principal Engineer at Cisco, as an intern in the Cisco Emerging Technologies and Incubation Group (ET&I).
During my first meeting with Dominik, he posed a question for me: “What is the cloud?” Though short, the question was far from simple. Remembering the various blog posts and videos I’ve consulted before when I first learned the topic, I started to list the benefits of scalability and reliability, the difference from traditional on-premises solutions, and even referenced microservices and containers. He paused me, and rephrased, “What defines the cloud?” After more exchanges and incorrect guesses, Dominik points out that I’m referencing the business implications and common cloud attributes, not what the cloud is. He ultimately reveals the punchline: the cloud is a service provider that enables a service consumer to request and release resources on demand.
That simple exchange set the foundation for the types of questions and problems that I’ll be tackling during the rest of the internship. It’s no longer about being content with what something is like but striving to identify its defining criteria. Though true that cloud-native solutions usually provide great flexibility for organizations and often involve microservices and containers, those characteristics don’t define the cloud and configurations without them aren’t any lesser of cloud solutions. Instead, the definition succinctly provides the bare requirements.
In the following months, I delved into similar questions, working to concisely convey these concepts and develop articles for the Cisco ET&I publications.
My first project was to understand Kubernetes Services, and I soon realized that constructing a mental model, or a formal understanding of the concept, required first understanding its key components and the relationship among each other.
In the case of Kubernetes Services, it was identifying that there are two main elements: the service and the pods. Working through the mathematical relation, I formalized my understanding and identified the anycast domain nature such that one service relates to one pod out of many options.
Afterward, I created visuals to effectively convey the idea by organizing the complex topic into states. As I diagrammed out each step and its associated logic of how a packet is delivered using Kubernetes Services, I practiced ways to create organized and informative graphics.
Concurrently as I was working on the Kubernetes Services project, Dominik introduced me to tools like TLA+ and Alloy, and I learned the benefits of a specification language and software abstractions for creating robust programs. I embraced that abstract thinking and mental models, generalizing away specific debugging, allowed for high-level understandings of any program.
After the Kubernetes Networking piece, my internship experience pivoted. Dominik and I decided to elaborate on the network model formalized in that blog and create an educational tool so that anyone can visualize the network of their Kubernetes cluster.
As I developed the program, I tested various graphing packages and layouts. The new challenge became creating an interactive and intuitive tool in addition to describing the concept through the article and visualizations.
The end-product is a program that parses through the configurations of the user’s current Kubernetes cluster and visualizes how a packet with a certain IP and port would travel between pods in the cluster.
Outside of the day-to-day project work, Dominik and Cisco have provided me with continual opportunities to grow and discover. From attending KubeCon to joining regular Emerging Technologies & Innovation ideation calls, I’ve been incredibly supported to discover and grow freely.
By the end of the internship, I have not only learned a vast array of topics through the projects but also established a strong foundation of fundamental research skills and practiced explaining ideas clearly and concisely. I’ve been able to experiment with an eclectic array of technologies and have been inspired by the possibilities I can further pursue in my continued journey in tech.
— Special thanks to Dominik Tornow and Cisco for this internship experience.