Question

From Data Science to Kubernetes: Adeoye’s Journey Into DevOps and MLOps

Developer Stories | CoderLegion

What happens when a curiosity about computers leads from geology and data science to machine learning, cloud computing, DevOps, and eventually Kubernetes?

For Adeoye, the journey has been anything but linear. His path has taken him from working with geological datasets and machine learning to exploring infrastructure, cloud platforms, containers, Kubernetes, and MLOps.

Along the way, he has learned an important lesson: building an application or model is only part of the journey. Understanding what happens underneath — how systems are deployed, connected, scaled, monitored, and recovered — can be just as important.

In this Developer Stories interview, Adeoye talks about his transition into DevOps and MLOps, his hands-on #40DaysOfKubernetes journey, troubleshooting Kubernetes failures, learning through writing, and the advice he has for developers entering DevOps or MLOps.

From Data Science to DevOps

Your profile describes you as a Data Scientist focused on DevOps and MLOps. How did you get from working with data and machine learning to becoming interested in infrastructure, DevOps and Kubernetes?

My journey into DevOps and infrastructure has been quite organic. I’ve always been fascinated by computers and the internet.

I remember seeing a computer for the first time when I was about seven years old. Watching the screen light up and respond to the actions of a senior family friend was fascinating to me. From that point on, I was always curious about what computers could do and how they worked.

As I got older, that curiosity led me into different areas of technology. At one point, I became interested in cybersecurity and ethical hacking. Like many curious teenagers experimenting with technology, I tried things like testing the security of Wi-Fi networks and eventually installed Linux on my computer.

That early exposure introduced me to a completely different side of computing and gave me my first real experience working with operating systems beyond the typical user level.

Later, when I studied Geology and Earth Sciences at university, my academic work introduced me to the world of data. Geology can be extremely data-intensive, and I found myself working with increasingly complex datasets, especially during my final-year research project.

I started with tools like Excel and eventually expanded into Power BI, Python, and R.

That experience naturally led me toward Data Science and Machine Learning. After graduation, I attended a Google Developers Bootcamp, where I learned the fundamentals of machine learning and earned a TensorFlow Developer Certificate.

At that point, I wanted to build a portfolio that demonstrated what I had learned and the projects I had worked on.

Interestingly, building that portfolio became the bridge into software development.

While trying to create and deploy websites for my projects, I started learning more about web development. I eventually built a number of websites, desktop applications, and mobile applications and experimented with hosting them on free cloud platforms.

But I became increasingly curious about how applications were actually deployed and managed in real-world cloud environments such as AWS and Google Cloud.

That curiosity led me to start learning about cloud computing and DevOps practices. I took online courses covering DevOps concepts and Google Cloud, and during that stage of my journey, I came across a free course offered by the Linux Foundation.

I applied, was accepted, and that was really where Kubernetes and infrastructure started to become a major focus for me.

As I learned more about containers, orchestration, networking, deployments, and the infrastructure behind modern applications, I realized that I genuinely enjoyed it.

Kubernetes especially changed the way I thought about software.

I had previously focused largely on building models and applications, but DevOps and infrastructure helped me understand what happens after you build something — how it is deployed, scaled, connected, monitored, and kept running.

Since then, it has been a really interesting journey.

Why MLOps?

What attracted you to MLOps specifically? What do you think developers or data scientists often underestimate about what it takes to move a machine-learning project from an experiment into something that can actually run reliably?

I became interested in MLOps during my Data Science phase.

After completing the Google Developers Bootcamp, I had a lot of ambitious ideas, one of which was to build an AI-powered seismic analyzer that could use machine learning and seismic data to identify patterns that might help with earthquake prediction.

It started as a small-scale personal project, but once I began implementing it, I quickly realized that there was much more to building an ML project than just training a model.

One of the biggest challenges I ran into was compute and the size of the datasets I would potentially need.

At the time, I was working on a Dell laptop with 16 GB of RAM, and I began to understand the practical limitations of trying to build something like that with limited resources.

I think that is something developers and data scientists often underestimate.

There is a big difference between getting a model to work in an experiment and building something that can actually run reliably in the real world.

When you're experimenting, the focus is usually on the model itself: can you train it, does it work, and how accurate is it?

But once you want to move beyond that, you start dealing with questions about where the data comes from, how it is managed, whether your work can be reproduced, and whether you have the infrastructure and compute needed to support the system.

A model might work perfectly on your local machine, but that does not necessarily mean it can be easily deployed or scaled.

You also have to think about what happens when the system fails or when the data changes over time and starts affecting the model's performance.

This realization is what really attracts me to MLOps. I am very interested in understanding what happens around the model and what it takes to move from an experiment to a useful project that can be deployed in the real world.

Learning Kubernetes by Doing

You've been documenting a hands-on #40DaysOfKubernetes journey. What made you decide to learn Kubernetes this way, and what has surprised you most along the way?

There’s a learning style that works very well for me: when I write about what I’m learning, it tends to stick.

It almost feels like I’m teaching myself the subject all over again, which is why I decided to document my Kubernetes journey.

What has surprised me most is how much I’ve learned from troubleshooting.

Sometimes I would spend days trying to fix a deployment issue, and once I finally solved it, I understood the problem so well that I knew exactly what to look for if I encountered it again.

I could also see myself getting faster with Kubernetes commands and better at diagnosing problems with each lesson.

When Kubernetes Breaks

You recently wrote about troubleshooting a real Kubernetes application failure. What did that debugging experience teach you about troubleshooting distributed systems compared with debugging a normal application?

It taught me that debugging distributed systems requires following the entire path of a request rather than focusing on one application.

In my case, the Pods were running, but small mismatches in ports, labels, and NetworkPolicies were silently breaking communication.

I learned to troubleshoot systematically, moving layer by layer from:

Service → Endpoint → Pod → Network Policy

That experience reinforced how important it is to understand the relationships between the different components rather than looking at each component in isolation.

Understanding Instead of Memorising

A lot of Kubernetes learning can become a collection of commands and YAML files. How do you approach learning the underlying concepts so that you're not simply memorising commands?

I tend to read a lot, so when I come across a Kubernetes concept I don’t understand, I take the time to dig into it through articles, documentation, or YouTube videos that explain it in detail.

I try not to just learn the command that fixes a problem, but understand why it works.

So, with every problem I encounter and every concept I initially struggle with, I come away with a stronger understanding of how Kubernetes actually works.

The Hard Parts of Kubernetes

You've been working through topics such as Ingress, ConfigMaps, Secrets, resource requests and limits, HPA/VPA, and etcd backup and recovery. Which Kubernetes concept has been the most difficult to truly understand, and why?

The concept I found most difficult to truly understand was Service Accounts and authentication, especially the certificates and tokens involved.

At first, I struggled to understand how Pods authenticate with the Kubernetes API and how that differs from authorization and RBAC.

Working through Service Accounts and CA certificates, and how they are mounted into Pods, helped me understand that authentication is about proving who you are, while authorization determines what you are allowed to do.

That distinction was one of the biggest hurdles for me.

Why Backups and Recovery Matter

You recently worked through etcd backup and restore. Why do you think developers often pay more attention to making systems work than to proving that they can actually recover when something goes wrong?

I think it often comes from the assumption that if you’ve built something correctly, it won’t fail.

Confidence in your abilities is important, but errors are inevitable.

Even machines fail, so systems need to be designed with the assumption that something will eventually go wrong.

Learning in Public

You regularly share your progress and technical discoveries publicly. What have you learned from explaining your work to other developers, and has writing about something ever exposed gaps in your own understanding?

Like I mentioned earlier, my learning style is such that when I write about something, it tends to stick more, and it also helps me identify gaps or areas where I might be wrong.

I remember while learning CS50 from Harvard, the instructor explained that one of the best ways to understand something is to explain it to a rubber duck.

A rubber duck is a complete beginner, so you have to break the concept down as simply as possible.

That is what I’ve been trying to do with my writing: break technical concepts down to the point where almost anyone can understand them.

The Developer You’re Becoming

How has your approach to technology changed since you started? Are you now more interested in understanding how systems work underneath rather than simply getting an application running?

To be honest, I’m much more interested in understanding how a system works underneath now.

Earlier in my journey, my approach was more about making sure the application worked and didn’t break during testing, even if I didn’t fully understand what was happening underneath or why something was breaking.

My mindset has shifted quite a bit since then.

Now I want to understand what makes the system work in the first place, so that when something does break, I can trace the problem back to the specific component that caused it rather than simply trying to find a quick fix.

Advice for Developers Entering DevOps or MLOps

For someone coming from software development, data science, or machine learning who wants to move into DevOps or MLOps, what would you recommend they learn first — and what mistakes should they avoid?

I would say start with Linux, networking, and Docker.

These give you a good understanding of what is happening underneath before moving into tools like Kubernetes.

I’d also say don’t focus too much on memorising commands.

Learn how to troubleshoot and understand why things work or break, because that knowledge will follow you across different tools and technologies.

Final Thoughts

Adeoye’s journey is a good reminder that careers in technology don't always follow a straight path.

A background in Geology led to working with data. Data Science led to Machine Learning. Building ML projects created an interest in software development, which eventually led to cloud computing, DevOps, MLOps, and Kubernetes.

And perhaps the biggest lesson from his journey is that understanding why something works can be far more valuable than simply knowing the command that makes it work.

His #40DaysOfKubernetes journey also highlights another powerful approach to learning: build, troubleshoot, explain what you learned, and repeat.

That process doesn't just create technical knowledge — it helps develop the ability to understand complex systems from the inside out.