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
Tweet

More Decks by Hibri Marzook

Other Decks in Technology

Transcript

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

    View Slide

  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

    View Slide

  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

    View Slide

  4. Why is DevOps and
    Public Cloud in Gov hard?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  10. The Restricted Platform

    View Slide

  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

    View Slide

  12. Provide a path for
    software delivery from
    Day 1

    View Slide

  13. View Slide

  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

    View Slide

  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

    View Slide

  16. View Slide

  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

    View Slide

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

    View Slide

  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

    View Slide

  20. A Shared Responsibility Model

    View Slide

  21. Give Autonomy

    View Slide

  22. Give Autonomy within boundaries

    View Slide

  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

    View Slide

  24. View Slide

  25. The Enterprise Platform

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

  29. What we learned

    View Slide

  30. Define clear interaction boundaries and evolve within
    them

    View Slide

  31. Understand risk and delegate it

    View Slide

  32. Internal Open Source enables
    multiple parties to work
    transparently

    View Slide

  33. Thank You
    33

    View Slide

  34. Q&A
    34

    View Slide

  35. Atlanta
    [email protected]
    Thank You
    contino.io continohq contino
    London
    [email protected]
    New York
    [email protected]
    Melbourne
    [email protected]
    Sydney
    [email protected]
    35
    Brisbane
    [email protected]

    View Slide