Hibri Marzook • Software Practice Lead Stuart Shelton • Senior Consultant A Tale of 3 Cloud Platforms in Government

2 Hibri Marzook Software Practice Lead Likes the challenge of using Public Cloud and Continuous Delivery to help teams deliver at a sustainable pace. Likes to use systems thinking to navigate the challenges of complexity @hibri www.hibri.net

3 Stuart Shelton Public Sector Team Lead Has been involved with a variety of public-sector clients over the past 8 years, and has both DevOps and Team Leadership experience of working on large-scale Cloud-enablement projects. Helping to build a great Engineering Culture through adoption of Agile best-practices, and accelerating Public Cloud Adoption with a DevSecOps approach. @srcshelton

Why is DevOps and Public Cloud in Gov hard?

Discontinuous Change https://flickr.com/photos/loopzilla/14028102901

Build Transition Own? Run? Support? Disjointed Delivery Someone’s problem Someone else’s problem Not our problem

Multi-party landscape Each 3rd party is governed by its own goals and contracts, and not aligned to the same goal

Distrust of Cloud Provider ● Public Cloud shared responsibility model was not understood ● Assessing Public Cloud like a on-prem data center would be assessed ● Need for approved approach from the Public Cloud provider

The 5 Essential Capabilities of Cloud Computing The NIST Definition of Public Cloud Computing 800-145 01 On-demand self-service 02 Broad network access 03 Resource pooling 04 Rapid elasticity 05 Measured/ Metered service 9

The Restricted Platform

Challenges ● IaaS in the Cloud ● Trusted only a few services from the Cloud Provider ● “DevOps” team was a blocker ● No viable path to production ● No elasticity ● Raise a ticket to allocate resources https://www.flickr.com/photos/stars6/4381853092

Provide a path for software delivery from Day 1

No content

Pipeline as a Product ● A versioned library of pipeline steps ● Opinionated Pipeline ● Abstract the platform behind pipelines ● Jenkins Pipeline as Code ● Evolve pipeline with Governance needs ● Cater to 95% of workloads ● Convention based

Opinionated Terraform Modules 1. Building blocks allow application teams to compose their application stack 2. Terraform modules abstract capability a. Web Application Module b. Backend module c. Relational Database module d. Caching Module 3. Infrastructure details are not exposed

No content

Internal Open Source ● Collaboration on Github.com ● Anyone can send a pull request ● All code for pipeline and TF modules are visible ● Breaks down the barriers between vendors ● Code belongs to the organisation

The Developer-autonomy (“everything and anything goes”) platform

Challenges ● Initial Cloud rollout started by a small team, only to fit their needs... ● … with no consideration for wider scale-out ● Need to enable pioneer teams in the organisation to learn how to work in the Cloud ● Need to cater for varied workloads

A Shared Responsibility Model

Give Autonomy

Give Autonomy within boundaries

Internal Open Source ● Platform code is visible to everyone ● Product code is segregated on a need to know basis ● Anyone can send a PR, to create an account or add/remove guard rails

No content

The Enterprise Platform

Challenges ● Platform run and owned by a 3rd party (managed service provider) ● Platform not validated with an application team ● Platform risk on the managed service provider

Dev Team Ops Team (Managed Service) App App App App Handover Tension

(Skelton and Pais, 2019, p. 105) Wall of confusion

What we learned

Define clear interaction boundaries and evolve within them

Understand risk and delegate it

Internal Open Source enables multiple parties to work transparently

Thank You 33

Q&A 34

Atlanta atlanta@contino.io Thank You contino.io continohq contino London london@contino.io New York newyork@contino.io Melbourne melbourne@contino.io Sydney sydney@contino.io 35 Brisbane brisbane@contino.io