From a developer to infrastructure expert: the story of Toby Archer

Toby Archer is a self-taught specialist who transitioned from a developer capacity to a DevOps consultant. We spoke with him about his background, how he got started with DevOps, and what’s happening right now in his field.

Could you tell us your story and your steps to where you are now?

I am Toby Archer, a DevOps consultant for Polar Squad, currently living in Berlin.

I am self-taught. Playing games as a young kid, I was interested in how they work. From RuneScape – and how they ran ‘illegal’ underground private servers to early Minecraft modding and SourcePawn for Counter-Strike, I was asking myself: ‘how do you build something like this? How do I run a CS server?’ This was my first introduction to coding, copy-pasting Java classes from RuneScape private server forums, etc.

When I went to school in a little village in the South East of the UK, there were no courses about programming and little about technology; the thing I was passionate about. We did have a computing course with the basics of Python, but mostly Scratch, the visual programming tool for kids. However, the teacher did not know anything about programming, so I failed the class. Soon I was skipping lessons and using the video-editing rooms (the only rooms with unlocked C:/ drive access!) to write javascript, build websites, etc. And at some point, I learned about Go, I think 1.4 and taught myself.

Ultimately, I decided to leave school to pursue my interests in programming. Somehow, I found a job as a Go developer at a little startup in Bristol. I learned a lot there, working with Ansible and virtual machines whilst writing Go services (shout out to the Fresh8 Bookie crew.) It was my first exposure to what we now call DevOps - especially running the wrong playbook and deploying development branches to production.

After some time, I left my first workplace, searching for a bigger paycheck and new challenges. Since then, I have observed many patterns in CI/CD pipelines, how companies manage their infrastructure and becoming involved in Kubernetes. The value it delivers to developers, all whilst building pretty much the same API in Go. That’s the path I am still on, but much less rinse-repeat on the Go microservices.

As someone who has been doing development for some time, how do you see the difference between doing that and, say, an SRE role?

In my past work, I have had to wear many hats. I often met stakeholders to understand what is needed – building it, running it, and maintaining it. There was no concept of SRE or maintenance. Everyone was doing their own thing, and as a perfectionist, I wanted things to be better. As a professional, I don’t want any smoke and mirrors, and I have a fundamental concept of learning as much as possible.

I worked in small teams, and we did not have dedicated SRE or DevOps teams. Our work merged into the development team. My idea was to gather as much knowledge about things and implement them from the get-go.

I was driven by working with others, learning from them, and making their life easier; at some point, it clicked. What I am doing is what we call DevOps or SRE.

What do you think about the divide between Dev and Ops?

During my career, I never worked with an operational team, and the developers had to do the work of the operations team. In that environment, the key question to me is: How do we innovate while keeping what we have intact?

Now, I see a fundamental shift underway: The idea of operations has changed and is being abstracted. We can use new tools that would enable us to be innovative without asking for someone else’s help.

The stability of the product should be taken into account from day one. We can’t be naive anymore and think of a product only as a set of features.

Our time makes ideas such as maintenance windows redundant. Consumers have changed, and they demand a different kind of service.

Let it crash, but be aware of it; everything has to be tolerant.

How do you see the new cloud-native tooling bridging the gap between developers and classic operation work?

Tools such as Kubernetes make life easier to work with. It’s an abstraction that will, in a certain way, make my life easier. There is a lot of maintenance work to be done when using it, but when used right, it can help developers to deliver and observe in a consistent way. That’s the power of abstraction.

For me, observability is about developer experience. As a technical individual, some software pinning the CPU for 100% is something that I don’t care about. Observability is there to help achieve a better developer experience and make us build better tools.

The concept of a unified API is a contract between the devs and Kubernetes, with YAML and versions. This pattern can be reused and reapplied. The idea of operators in Kubernetes extends beyond just running containers and databases.

This is, of course, on the conceptual level. Building an operator in Go is not the most beautiful thing in the world. But the good part is that only a few people need to know the internals of this thing; the rest can just implement it.

What comes next in the realm of Dev and Ops?

Right now, we have a fragmented ecosystem in which we have many tools, and they all use different implementations. Operators using YAML manifests as a specification for something were a huge step forward. But can you use them for everything? I am not sure.

We have a lot of new foundations now, but the question is: Which of them will survive? 

As an individual highlight, I am interested in Crossplane, which acts as a universal control plane. It takes K8s control planes and can create resources like TF but for K8s. Another interesting thing is a project called Cluster-API from the Kubernetes SIGs: It is about provisioning K8s clusters but uses the same patterns to do that.