The team, as finalists for MYOB’s Ignition awards

Outcomes first: in a year, we had 100 production apps across 26 tribes running on our Kubernetes clusters; we drove ISO 27001 compliance across 12 products, and taught 200 developers how to build secure, production-ready apps. And we built this on a foundation of empathy, mentoring, and a belief in propagating change starting from developers up.

Oh, and we were the finalists for a company team award. I like awards.

This is how we did it.

The platform.

I’m a big believer in judging the culture and values of a system by the artifact it produces, so I’m going to outline what we had at the start of the year vs. what we have now: in January 2018, we had a Kubernetes cluster that provided easy TLS through annotations (with 3 apps). By December 2018, we had:

A internal product referred to internally as “ The Jupiter Platform ”

” Single sign-on for metrics, logging, and dashboarding services

Easy provisioning of databases and queues through operators

Automated backup and restoration services for developers

ISO 27001 compliance

Training programs (synchronous and self-service) for developers

…and easy TLS through annotations

The team

The 5-person crew runs on a couple of foundational principles:

We are not a DevOps crew. While we use DevOpsy tools and paradigms, we primarily operate and surface ourselves to the organization as a product-platform crew. We’ll unpack this later.

Our work is not in clusters, but change. We develop on Kubernetes not as a container scheduler, but as a organizational policy driver. Again, unpacking later.

Our processes start on empathy; proactive and reactive work operate on a starting need to actively interrogate what our clients (development crews, effectively) need.

What problem were we trying to solve?

Many organizations have adopted the Spotify model as a way of structuring an organization to optimize for quicker delivery and autonomy (while accepting and compensating for creating silos). And while I agree with its tenets, it produces a couple of problems especially in the DevOps space.

When implementing DevOps across a Spotify-ish organization, organizations usually create a DevOps role per team or tribe. While this creates autonomy by removing coupling from a central team, it introduces practice explosion: you always end up with many different ways of doing the same thing.

This explosion creates problems when the need for an organization-wide initiative arises: something that commonly happens in the infrastructure space. Off the top of my head:

Standards Compliance (e.g., ISO 27001, IRAP, SOX). Compliance requires enumeration of how you do things — which becomes a big problem when you have many ways of doing things.

Infrastructure cost accounting (and reduction). A delivery team’s primary concern is delivery, and it is often hard to relay the importance of efficient software.

Reducing the friction of moving teams. When you have many ways of doing things, you end up with non-transferrable knowledge when you move teams. I find it absurd for developers to have to relearn everything when you just have to move a couple of desks away.

The Not-Solution

The idea by late 2017 was that we would create a Kubernetes cluster, and have people move to it. I didn’t particularly agree with this, as this sounded like a technological fix to an organizational issue. You do not just build it and have people come.

However, we agreed that practice convergence in the infrastructure space was at least preferable. While I don’t hold any particular religious zeal towards K8s, it was more important that the organization picked a solution, and converged upon it as a deliberate choice.

From here on, we’ll unpack how we attempted to solve this problem in three areas: Adoption, Product Thinking, and Policy.