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?

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

    View Slide