Empowering Engineers: How Cambridge University Press Adopted a Shift Left Culture

Companies must be agile and respond quickly to changing customer needs in today's fast-paced and constantly evolving technology landscape. That's why DevOps practices that emphasise collaboration and communication between development and operations teams to deliver software rapidly, reliably, and at scale have become increasingly popular.

Shifting left, a core principle of DevOps can significantly benefit companies of all sizes. By empowering engineers to take on more operations responsibilities and promoting a culture of experimentation and innovation, companies can improve collaboration, increase reliability, and deliver high-quality software at scale.

In this post, I'll discuss how and why Cambridge University Press adopted a shift left culture.

A New Culture

Cambridge University Press had a small operations team responsible for hosting Node.js applications used by millions of users daily on EC2.

They realised engineers needed more operations responsibilities to accommodate new and scale existing applications, so they adopted a shift left culture.

This led to the developing of a DevOps culture where engineers worked collaboratively with operations to build and deploy high-quality software at scale.

One of the most critical aspects of our culture was having a no "assholes" attitude, which made it possible for everyone to work together harmoniously towards a common goal.

There was no gatekeeping, and teams were encouraged to experiment and try new things without permission, creating an environment of trust and empowerment.

In addition, teams were encouraged to find solutions to their use cases and problems rather than adopting a one-size-fits-all approach, ultimately leading to better outcomes.

Migrating to Kubernetes

To foster this new culture, our engineers and operations teams worked closely to migrate the first application to run in Kubernetes.

While the operations team set constraints, such as structuring environment variables and capturing metrics in Prometheus and dashboards in Grafana, they did not dictate solutions to the engineering teams.

Keeping things simple, easy and consistent was crucial to our success.

For example:

• Collaboration to create predefined templates for services, deployment, and ingress files.

• A folder called' infrastructure' in the root directory was all that was required for a Node.js application to run in Kubernetes.

• Infrastructure as code was in the same repository as the application source code, making continuous integration and delivery easy.

Experimentation and Innovation

Teams were encouraged to innovate, create, and explore. Our team was the first in the company to have feature branch previews, allowing product owners, testers and stakeholders to be agile and use features earlier in the development process.

In addition, we streamlined our deployment process to have zero downtime between deployments and automatic rollbacks if errors were detected.

Following the principle of "you build it, you own it", teams were responsible for ensuring they had enough logging and instrumentation to diagnose bugs and performance issues.

Operations did not intrude on teams but made themselves available for guidance and support. This helped teams be more productive as they didn't need an embedded ops person, and we were fortunate enough to have curious engineers who wanted to learn and tech.

Teams would get together to share their learning and adopt each other's practices, which helped raise the bar in what we accomplished and our SRE skills and knowledge.

The outcome of adopting a shift left culture

Cambridge University Press's adoption of a shift left culture had significant benefits.

Within a few months of starting the initiative, we migrated applications to serve traffic from production Kubernetes clusters.

By empowering engineers with more operations responsibilities and promoting a culture of experimentation and innovation, they could build and deploy high-quality software at scale collaboratively with the operations team.

The migration to Kubernetes was a critical milestone in this journey. Within a few months of starting the initiative, we migrated applications to serve traffic from production Kubernetes clusters.

The simplicity, consistency and ease of deployment made it possible for new applications to be Kubernetes-first.

The benefits of this approach were improved team collaboration, faster time-to-market, increased reliability, reduced downtime and streamlined deployment processes. This approach also helped save costs while maintaining high-quality services for its users.

Ultimately, Cambridge University Press's shift left culture allowed them to stay ahead of the curve and respond more quickly to changing market needs.