STARTING FROM SCRATCH Damian Cronan, CTO - Fairfax Metro A small - PowerPoint PPT Presentation

STARTING FROM SCRATCH Damian Cronan, CTO - Fairfax Metro

A small detour

Media has zero barriers to entry

Change from within is hard Large enterprises have both inertia and an immune system Fairfax’s historical ability to affect meaningful change has been below the rate required to thrive

Why are we doing this? We need to compete at the speed of our smallest, most nimble competitor.

What we set out to do

CONTEXT What we were dealing with... Extensive legacy environment with mountains of tech debt ~150 FTEs in department Change cycles measured in months, “quasi-agile wrapped in waterfall” No unified engineering vision A frustrated business from lack of agility Entrenched “enterprisy” purchasing and technology decision making

OUR CHALLENGE To create a sustainable future for our business by combining heritage assets with a new operating model. Rebuild our metro news properties. Strengthen our brands and engineer our products for commercial growth. Equip our team with a demonstrably world-class publishing platform, fit for a modern newsroom. And deliver all this within a modest cost envelope.

The approach

Getting out of Dodge! ● Physical distance from the head-office mothership ● Practical, operational and funding autonomy ● Start with a small “day-zero” in-house engineering team (“desert island 6”) ● Mix with key talent, off-market to challenge assumptions & thinking ● Narrowly scope and plan critical path closely - and measure

ENGINEERING PRINCIPLES ● Retain control over points of differentiation ● Exploit open-source toolsets to minimise time to market ● Bias to release - from concept to market - measured in hours, not months ● Stay headless - content needs to be distributed far & wide ● Convention over constraints - Media demands pace and flexibility. Rather than build complex rules in, develop an adherence to convention to KIS ● Self-describing - Each application has the code defining the infrastructure requirements within its own repository

APPROACH Browser CDN NGINX Ingress Controller Node Pod - api-content Node Node Node AZ AZ AZ

So what have we done?

WHAT HAVE WE DONE Engineering - Kubernetes on AWS ● Container isolation promotes “stacking” of nodes ● Low-cycle time for deployments - automated pipelines ● Clean observability practices - Tracing, Health-checks ● Clear Application contract interface promotes consistent patterns - ○ Log collation & aggregation ○ Monitoring & Support ○ Deployments ○ Testing ● EBS for persistence ● Use of EC2 spot market to drive cost efficiencies - resilience

WHAT HAVE WE DONE Engineering - GraphQL & Microservices ● micro-service APIs ● Facebook’s GraphQL to orchestrate unified client fetch from microservice APIs ● GRPC for interprocess communication ● APIs written in Golang, sites in Node ● CI/CD pipelines orchestrated by Concourse, initiated by SlackOps ● Secret management using combination of AWS KMS & Confidant (open source) ○ injected into container at runtime ● Clear naming standards (no pet names!)

WHAT HAVE WE DONE Engineering - OpenSource ● Heavy User of CNCF (Cloud Native Computing Foundation) ○ Kubernetes - clustered compute ○ Prometheus - monitoring ○ gRPC - Inter-service communication ○ Jaeger - Tracing ○ Helm - Package management ● Others - ○ Grafrana - visualisation & dashboards ○ Snowplow - real-time event pipeline ○ Confidant - secrets manager ○ Elastic Search & Kibana - data store & analysis tool ○ Concourse - Pipelines ○ Wordpress - CMS ○ Coral Talk - Commenting ○ Golang / Node - Languages

WHAT HAVE WE DONE Engineering - SlackOps

WHAT HAVE WE DONE Engineering - Pipelines

A new approach to teams ● Small, autonomous teams withc lear goals & greater accountability ● Flat, efficient structures ● Data transparency to increase visibility of problems and responsiveness ● Showcase to drive team accountability, alignment & celebrate any wins ● Focus on shared understanding and context to improve decision making

Co-opting open-source ways of working ● Anyone can commit to any code-base - pull vs push ● Team that cares about the outcome is accountable for it’s delivery ● Focused, high-quality Pull Request culture

Project reporting in real-time, with hard data

Shift culture through signalling what you care about, and modelling behaviours, consistently Before After “Enterprise” packages Heavy open-source reliance No engineering voice “Equal partner” - strong engineering voice Top down, centralised decision making Bottom-up decisioning (with guardrails) Heavy pseudo-agile process overheads Closely integrated product & design Deep hierarchical management structure Shallow management structure; outcome driven engineering

The economic reality of working this way is that we can get more done in a shorter time frame for fewer dollars. ...with happier people

Collateral Damage Everything has a price ● Alienation & exclusion from staff ‘left behind’ ● Sense of A-Team vs B-Team ● Lack of communication to dispel rumours ● High rates of churn for those not ‘inside the tent’ ● Poor business alignment for some priorities ● Significant skills gap

It’s faster to prepare a story in a way that looks good … It’s a testament to INK how easy it was for reporters to get in there and start doing it … INK’s flexibility and stability are real assets. Mathew Dunckley, BusinessDay editor

VISION A platform to serve new and emerging channels.

In 12 months we delivered: ● Successful commercial and audience strategies through our metro web products ● A world-class publishing platform, on par with anything globally ● An engaged and productive Product & Technology team ● A complex technological change without issue or disruption to our core business.

Thankyou