6 Myths of delivering software that will destroy your sleep nights

Copyright © 2018, Oracle and/or its affiliates. All rights reserved.
| 6 Myths of delivering software that will destroy your sleep nights Elder Moraes | @elderjava Developer Advocate March, 2019

| Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

| “If I could change the world…” –  Eric Clapton

| 5 https://medium.com/@neonrocket/devops-is-a-culture-not-a-role-be1bed149b0

| 6

| 7

| 8 Let’s talk about…

| 9 replaces Myth #1

| “In DevOps ideal, developers receive fast, constant feedback on their work, which enables them to quickly and independently implement, integrate, and validate their code, and have the code deployed into production” –  The DevOps Handbook Confidential – Oracle Internal/Restricted/Highly Restricted 10 DevOps and Agile can get along

| The “DevOps ideal” described is achieved by: •  Checking small code changes in the repository •  Performing automated and explanatory testing •  Deploying into production Confidential – Oracle Internal/Restricted/Highly Restricted 11 DevOps and Agile can get along

| Despites DevOps can be a natural continuation from Agile journey, they are not pre-required for each other. Confidential – Oracle Internal/Restricted/Highly Restricted 12 DevOps and Agile can get along

| 13 replaces Myth #2

| ITIL is still relevant ITIL describes capabilities that are also needed to support a DevOps-style work stream: •  Management •  Organization •  Processes •  Knowledge •  People 14

| ITIL is still relevant To deploy more and faster, ITIL processes need automation around: •  Change •  Configuration •  Release 15

| ITIL is still relevant To detect and recover fast from incidents, ITIL disciplines are important as always around: •  Service design •  Incident and problem management 16

| 17 means NOOPS Myth #3

| 18 https://devops.com/noops-devops-disaster-waiting-happen/ There’s no NOOPS

| There are three ways where Ops helps Devs to improve their results: •  Creating self-service capabilities to increase developers productivity •  Embedding Ops engineers into the developers teams •  Assigning Ops liaisons to the developers teams when embedding isn’t possible Confidential – Oracle Internal/Restricted/Highly Restricted 19 There’s no NOOPS

| “…we build tools to enable self- service. It’s okay for people to be dependent on our tools, but it’s important that they don’t become dependent on us.” –  Diane Marsh, Director of Engineering Tools at Netflix Confidential – Oracle Internal/Restricted/Highly Restricted 20 There’s no NOOPS

| 21 only for Myth #4

| 22 DevOps …and DevOps for all

| Maybe some reasons for this myth is that some DevOps patterns have some technology requirements such as: •  Support for automated testing •  Being able to expose configurations that can be checked into version control Which are more common on OSS, but not completely missing in others. Confidential – Oracle Internal/Restricted/Highly Restricted 23 …and DevOps for all

| DevOps principles are: •  Universal •  Usually independent of the technology being used Confidential – Oracle Internal/Restricted/Highly Restricted 24 …and DevOps for all

| 25 means only Infrastructure as Code Automation Myth #5

| DevOps is all about people Every aspect of DevOps is related to people. For example: •  Sharing goals and pains •  Adopting practices who transform the team •  Delivering value to the customer 26

| “Organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.” –  Conway’s Law (from Dr. Melvin Conway) Confidential – Oracle Internal/Restricted/Highly Restricted 27 DevOps is all about people

| Dr. Conway performed an experiment in 1968: •  The goal: to produce a COBOL and an ALGOL compilers •  The team: 8 people •  The organization: 5 for COBOL, 3 for ALGOL •  The results: COBOL compiler ran in 5 phases, and ALGOL compiler ran in 3 phases Confidential – Oracle Internal/Restricted/Highly Restricted 28 DevOps is all about people

| With teams poorly organized, according to Conway’s Law, organizations will: •  Prevent teams from working safely and independently •  Make teams tightly-coupled, all waiting on each other for work to be done •  Make even small changes to be potentially catastrophic Confidential – Oracle Internal/Restricted/Highly Restricted 29 DevOps is all about people

| 30 DevOps is all about people

| 31 only for Myth #6

| 32 All Unicorns were once Horses

| 33 Many Horses adopted DevOps

| “If there’s anything that all horses hate, it’s hearing stories about unicorns. Which is strange, because horses and unicorns are probably the same species. Unicorns are just horses with horns.” –  Christopher Little, Research Director, Gartner Group Confidential – Oracle Internal/Restricted/Highly Restricted 34 …and DevOps for all (again!)

| 35

| book.eldermoraes.com @elderjava

6 Myths of delivering software that will destroy your sleep nights

6 Myths of delivering software that will destroy your sleep nights

More Decks by Elder Moraes

Other Decks in Technology

Featured

Transcript