Making infrastructure more resilient at Roche

At Roche, I worked on a feature that lets teams manage infrastructure across multiple nodes. The aim was to provide a stronger foundation for resilience and growth, while making the system practical to operate.

I carried the work from early stakeholder discussions through design, implementation, delivery and support. I was part of an engineering team, with responsibility that connected the technical work to the people who would use it.

Understanding the whole job

Adding more machines is only one part of the problem. The feature also had to support the everyday work around them, including adding, removing and replacing nodes, and understanding their status. Those operations needed to fit into a management experience that people could actually use.

My work started with conversations about those needs. I helped turn them into a design, worked through the technical decisions with the team and implemented the functionality. Keeping the operational experience in view mattered throughout that process.

Connecting the pieces

The platform brought together Kubernetes and services written in Go and Python. My work connected the backend APIs and management experience with the infrastructure underneath. A cluster and an individual node are different things, so the software needed to represent both clearly. That distinction affected the data exposed through the APIs and the way people understood the system.

Having multiple nodes creates options for resilience, but it does not make every application immune to interruption. Infrastructure behaviour and application behaviour both matter. The engineering problem included understanding those boundaries, alongside making the new capability available through the product.

Another challenge was that infrastructure operations take time. Accepting a request does not mean the change has finished. The APIs and management experience needed to make that difference clear, including when an operation was still in progress. Working across those boundaries was a substantial part of turning the infrastructure capability into a usable feature.

Following it through

I stayed involved through delivery and continued supporting the feature afterwards. That meant carrying context from the original discussions into implementation and keeping responsibility for the work once it was in use.

The result was a delivered capability for managing infrastructure across multiple nodes. My responsibility covered the feature as a whole, within the team building it. Supporting it afterwards was part of that responsibility too.