I have a degree in Economics, but now I’m a Cloud Native developer.

How I stumbled into the world of “Cloud Native”

Photo by Gabriel Heinzer on Unsplash

Leaving my previous job in Machine Learning Operations (MLOps) was not part of a well-thought-out career plan. The company was restructuring, and the uncertainty made me desperate for a change. When the first job offer came my way, I grabbed it without a second thought. Little did I know, this impulsive decision would catapult me into the world of cloud-native development — a field I knew almost nothing about.

The New Beginning

The team I joined specialized in colocation of services using native Kubernetes and leveraged some advanced Linux kernel technologies for resource isolation. Initially, the terminology alone was overwhelming. My new colleagues spoke in a language filled with terms like “pods,” “node affinity,” “cgroups,” and “namespaces.” However, as daunting as it seemed, I was determined to dive in and understand the nuances of this new field.

Understanding Colocation

Colocation in Kubernetes involves running multiple, related services on the same node or within the same pod. This strategy aims to reduce latency by ensuring that services that frequently communicate are physically close to each other. The concept sounded simple enough, but implementing it was a different story.

We used Kubernetes pods to run multiple containers together, sharing the same network namespace and storage. This setup allowed services to communicate efficiently and reduced the overhead associated with network communication. However, it also required careful planning to avoid resource contention. For example, we had to meticulously define resource limits and requests for each container to ensure fair sharing of CPU and memory.

In fact, my team takes this a step further by using “overcommit” as a strategy to allow more workloads to live on a node than it can necessarily fit. How is this even possible? Well, because most services use less resources than it actually requires, and also online services experiences periods of peak and off-peak, we take advantage of this difference in actual usage and supposed usage to squeeze some extra mileage from each node.

And because the company has tens of thousands of machines, the extra mileage the team can squeeze out from all the clusters could sum up to thousands and thousands of CPU cores.

Resource Isolation with Linux Kernel Technologies

Now, back to some nitty gritty techie details.

To enhance resource isolation, we employed Linux kernel technologies like cgroups (control groups) and namespaces. Cgroups allowed us to limit, account for, and isolate the resource usage (CPU, memory, disk I/O, etc.) of a collection of processes. Namespaces, on the other hand, provided isolation for system resources such as process IDs, hostnames, user IDs, and network access.

Combining these technologies with Kubernetes’ native capabilities created a robust environment where services could operate efficiently without stepping on each other’s toes. However, this setup was not without its challenges. Ensuring proper isolation while maintaining performance required constant monitoring and fine-tuning.

The Bigger Picture: Cloud Native Architecture

Our colocation efforts were part of a broader cloud-native architecture that the company adopted. Cloud-native development is all about designing applications specifically for cloud environments, leveraging microservices, containerization, continuous integration, and continuous delivery (CI/CD), and using managed cloud services.

In this architecture, colocation played a crucial role in optimizing performance and resource utilization. By colocating services, we reduced latency and improved response times, which is vital for maintaining high-performance applications. This approach also facilitated easier scaling and management of microservices, contributing to the overall agility and resilience of our systems.

Reflections on the Journey

Reflecting on my journey, it’s remarkable how far I’ve come. With an Economics degree, my career path has been anything but linear. Transitioning from Economics to AI and now to cloud-native development has been a rollercoaster ride. Each step has been marked by a steep learning curve, but also by significant personal and professional growth.

In the past six months, I have learned to navigate complex technologies, adapt to new workflows, and embrace a culture of continuous learning and collaboration. The lessons I’ve learned have not only broadened my technical skillset but also reshaped my approach to problem-solving and innovation.

Conclusion: Embracing the Future

My unexpected plunge into cloud-native development has been both challenging and rewarding. It has opened my eyes to new possibilities and has equipped me with the skills to build more efficient, scalable, and resilient systems. As I continue to explore this ever-evolving field, I am excited about the future and the endless opportunities it holds.

The journey from Economics to AI to cloud-native development is a testament to the power of adaptability and the willingness to embrace change. It’s a reminder that sometimes, the most unexpected paths can lead to the most rewarding destinations. And with every new challenge, I am reminded of why I chose this path — to innovate, to learn, and to make a lasting impact in the world of technology.