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