Upgrade to Pro — share decks privately, control downloads, hide ads and more …

A Tale of 3 Cloud Platforms in Government

A Tale of 3 Cloud Platforms in Government

DevOps and Public Cloud adoption in Government is complex and can be frustrating. However, making it work is rewarding and helps civic institutions use digital tools to better our lives.

What makes DevOps succeed in large Government organisations?
What hinders Public Cloud adoption?
How do you build a DevOps culture in risk-averse Government organisations?


Hibri Marzook

October 28, 2021

More Decks by Hibri Marzook

Other Decks in Technology


  1. Hibri Marzook • Software Practice Lead Stuart Shelton • Senior

    Consultant A Tale of 3 Cloud Platforms in Government
  2. 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. 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
  4. Why is DevOps and Public Cloud in Gov hard?

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

  6. Build Transition Own? Run? Support? Disjointed Delivery Someone’s problem Someone

    else’s problem Not our problem
  7. Multi-party landscape Each 3rd party is governed by its own

    goals and contracts, and not aligned to the same goal
  8. 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
  9. 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
  10. The Restricted Platform

  11. 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
  12. Provide a path for software delivery from Day 1

  13. None
  14. 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
  15. 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
  16. None
  17. 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
  18. The Developer-autonomy (“everything and anything goes”) platform

  19. 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
  20. A Shared Responsibility Model

  21. Give Autonomy

  22. Give Autonomy within boundaries

  23. 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
  24. None
  25. The Enterprise Platform

  26. 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
  27. Dev Team Ops Team (Managed Service) App App App App

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

  29. What we learned

  30. Define clear interaction boundaries and evolve within them

  31. Understand risk and delegate it

  32. Internal Open Source enables multiple parties to work transparently

  33. Thank You 33

  34. Q&A 34

  35. 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