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

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

CONTEXT

To create a sustainable future for our business by combining heritage assets with a new operating model. OUR CHALLENGE 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

• 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

ENGINEERING PRINCIPLES

APPROACH

Node Node Node Pod - api-content

CDN

Node Ingress Controller

NGINX

Browser

AZ AZ AZ

So what have we done?

Engineering - Kubernetes on AWS

WHAT HAVE WE DONE

• 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

Engineering - GraphQL & Microservices

WHAT HAVE WE DONE

• 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!)

Engineering - OpenSource

WHAT HAVE WE DONE

• 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

Engineering - SlackOps

WHAT HAVE WE DONE

Engineering - Pipelines

WHAT HAVE WE DONE

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

“Enterprise” packages No engineering voice Top down, centralised decision making Heavy pseudo-agile process overheads Deep hierarchical management structure Heavy open-source reliance “Equal partner” - strong engineering voice Bottom-up decisioning (with guardrails) Closely integrated product & design Shallow management structure; outcome driven engineering Before After

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

• 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

Everything has a price

Collateral Damage

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

A platform to serve new and emerging channels.

VISION

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