Slide 1

Slide 1 text

@jezhumble #oredev2019 7 November 2019 Is DevOps Still Relevant in a Cloud Native World?

Slide 2

Slide 2 text

A perspective from Devopsdays Portland 2019 https://www.darkcoding.net/software/a-developer-goes-to-a-devops-conference/

Slide 3

Slide 3 text

DevOps movement a cross-functional community of practice dedicated to the study of building, evolving and operating rapidly changing, secure, resilient systems at scale

Slide 4

Slide 4 text

DevOps An organizational and cultural movement that aims to increase software delivery velocity, improve service reliability, and build shared ownership among software stakeholders. cloud.google.com/devops

Slide 5

Slide 5 text

01 Measuring software delivery performance

Slide 6

Slide 6 text

2019 State of DevOps Report: cloud.google.com/devops

Slide 7

Slide 7 text

Software delivery as a competitive advantage Elite performers are twice as likely to meet or exceed their organizational performance goals: ● Profitability ● Productivity ● Market share ● Number of customers ● Quality of products or services ● Operating efficiency ● Customer satisfaction ● Quantity of products or services provided ● Achieving organizational and mission goals 2019 State of DevOps Report: cloud.google.com/devops

Slide 8

Slide 8 text

2019 State of DevOps Report: cloud.google.com/devops

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

State of DevOps Report: cloud.google.com/devops Continuous delivery

Slide 11

Slide 11 text

Cloud is a differentiator Elite performers were 24 times more likely to have met all essential cloud characteristics than low performers*. But only 29% of respondents met all five! 2019 State of DevOps Report: cloud.google.com/devops *Five essential characteristics of cloud computing defined by NIST in Special Publication 800-145 On-demand self-service Broad network access Resource pooling 1 2 3 Rapid elasticity 4 5 Measured service

Slide 12

Slide 12 text

02 Enterprise cloud native platforms

Slide 13

Slide 13 text

Enterprise Edition ● Hundreds / thousands of services ● Heterogeneous technology ● 70%+ of IT budget is keeping lights on & adding capacity* ● Now we’re supposed to support CI/CD Photo: Joshua Heller https://www.flickr.com/photos/joshuaheller/4452150826 CC BY 2.0 * https://www.forrester.com/go?objectid=RES115762

Slide 14

Slide 14 text

Operations “Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance.” — Kurt Vonnegut, Hocus Pocus Photo: By WNET-TV/ PBS - eBayfrontback, Public Domain, https:// commons.wikimedia.org/w/index.php?curid=38530410

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

Designing an enterprise PaaS 01 Garbage collection “Whom should I be billing for this virtual load balancer / db instance?” “What would happen if I deleted this service? Is anybody even using it?” 02 Making changes “This application has a vulnerability: How would I fix and redeploy it?” “I need to update this dependent service: where is the source code? Does anyone who built it still work here?” 04 Managing complexity “How do we make sure we can hire people who know how to work on this?” “How can we make sure the application and stack are up-to-date?” 03 Multi-tenancy “How do we enable developers to self-service deployments or config changes without impacting other services on our platform?”

Slide 17

Slide 17 text

Lead time “How long would it take your organization to deploy a change that involves just one single line of code? Do you do this on a repeatable, reliable basis?” Mary and Tom Popppendieck, Implementing Lean Software Development: From Concept to Cash, p59.

Slide 18

Slide 18 text

Lead time and TTR in the enterprise When you discover a vulnerability in your stack, how long would it take you to find, patch and redeploy all impacted applications? https://arstechnica.com/information-technology/2017/09/massive- equifax-breach-caused-by-failure-to-patch-two-month-old-bug/

Slide 19

Slide 19 text

Key principle for Platform- as-a-service: Separation of Responsibilities 1. Platform team is responsible for the PaaS. 2. Make the application part as small as possible! 3. Self-service API for deployment. Ideally application stacks are part of the platform too (function-as-a-service model) so we can keep them patched easily. Photo: Uwe Kills License: CC-BY-SA https:// commons.wikimedia.org/wiki/File:Iceberg.jpg Apps Platform

Slide 20

Slide 20 text

Compliance https://18f.gsa.gov/2017/02/02/cloud-gov-is-now-fedramp-authorized/

Slide 21

Slide 21 text

Designing an enterprise PaaS 01 Garbage collection Platform should ensure that every virtual resource is assigned either to an app or the platform itself. 02 Making changes It should be possible to redeploy any app at the click of a button. 04 Managing complexity Limit options! For example, all apps must used predefined, approved runtime stacks that PaaS operators can patch and redeploy on demand 03 Multi-tenancy Essential requirement of any enterprise PaaS

Slide 22

Slide 22 text

03 Apps

Slide 23

Slide 23 text

Architectural outcomes: can my team... 01 ...make large-scale changes to the design of its system without the permission of somebody outside the team, or depending on other teams? 03 ...deploy and release its product or service on demand, independently of other services the product or service depends upon? 04 ...do most of its testing on demand, without requiring an integrated test environment? 05 ...perform deployments during normal business hours with negligible downtime? 02 …complete its work without needing fine-grained communication and coordination with people outside the team?

Slide 24

Slide 24 text

JAM stack JavaScript APIs Markup

Slide 25

Slide 25 text

JAM stack advantages ● Extremely cheap, highly scalable ● Minimizes attack surface area ● Separation of concerns between content and functionality ● Super easy to configure and deploy ● Decouples presentation and services, easier to develop / test

Slide 26

Slide 26 text

JAM stack disadvantages ● You don’t get to put containers / kubernetes on your CV ● You have to think about service boundaries and dependencies ● You have to rely on your platform for canary / autoscale / cold start

Slide 27

Slide 27 text

building security in http://bit.ly/2018-devops-report | https://devops-research.com/research.html

Slide 28

Slide 28 text

You can’t just install kubernetes & start deploying apps! ● Self-service multi-tenant PaaS that minimizes attack surface area ● Architect for continuous delivery ● Develop the necessary technical skills ● Process change For more on cloud and devops, visit cloud.google.com/devops