DevOps

What is your perspective of DevOps? Start een discussie over wat men zelf onder de term DevOps verstaat. Schrijf kernwoorden op een flowchart

Consider the following Every company is a kind of IT company Software operations is only a concern of the IT guy The IT department is the least automated department of the company Doorloop de stellingen 1 voor 1. Wat vind het publiek van deze stellingen?

What’s the challenge? Given: Businesses grow continuously at an increasing speed to maintain their competitive advantage Businesses will change Technology (not only IT!) will evolve As a result: Businesses continue to have an increasing need for new features, higher throughput and adoption of new platforms (machine learning, augmented reality, internet of things.....) Software needs to adapt to keep up that speed Teams need to adapt to keep up that speed Tegenwoordig is de uitdaging om in steeds hogere snelheid te kunnen blijven voldoen aan de veranderingen in de organisatie, markt en wereld. Kijk maar eens in de wereld om ons heen. Alleen al de afgelopen 10 jaar. Introductie smartphones, tablets, smart devices. Maar ook de manier waarop we media content tot ons nemen (Spotify, Netflix) ......

2009: when the term DevOps was first mentioned “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr” Velocity 2009 presentation by John Allspaw and Paul Hammond Flicker was 1 van de eerste organisaties die deze uitdaging inzag en wilde aangeaan. Allspaw en Hammond vertelden hun verhaal van Flicker waarbij in 2009 voor de eerste keer de term ‘DevOps’ werd genoemd https://www.youtube.com/watch?v=LdOe18KhtT4

My perspective DevOps is the Way of Working of a team which has full control and responsibility of the application lifecycle Full Control: the team makes its own (technology) decisions Responsibility: the team receives KPI metrics of the Accountable product owner and steers on those metrics Application: the boundary (context) is often a (set of) services Dit is mijn perspectief op DevOps. Met vrijheid komt verantwoordelijkheid. Een DevOps team krijgt de vrijheid om haar omgeving volledig in beheer te nemen. De omgeving (context) is veelal een service of set of services/apps. Het team maakt de technologie keuzes zelf en biedt transparantie over de performance van de diensten die de context levert.

DevOps Way of Working - organization Analysts Architects Developers Testers Security engineers Network engineers Cloud engineers Hardware engineers A DevOps team contains all the skills required to meet the objective Define Design Build Test Deploy Monitor DevOps is not solely about technology or code. It can only be successful with culture and organization in mind. People get new roles and responsibilities. Testers produce code to automate tests.

The pipeline Commit code Integrate code Test Deploy Release Als we 1 cyclus van het continue process platslaan ontstaat een “pipeline” van activiteiten. De pipeline is de waardeketen van stappen die worden doorlopen in 1 ronde van DevOps.

DevOps Way of Working Minimize risk and impact  small increments of change which are pushed through the pipeline Shorten the feedback loop Automation of tests* Shorten the feedback loop Automation of code integration and deployment* Automate (almost) everything  What can be scripted, make it part of your delivery pipeline (infrastructure too!) Kleine batches / unit of work. Altijd forward releasen. Bij fouten niet terugrollen maar concentreren op het wegnemen van de oorzaak en vervolgens opnieuw releasen Als het deployen risico vol en moeizaam is, doe het dan vaak! Klikt tegenstrijdig, maar door het vaak te doen, leert de organisatie sneller de deployment onder controle te krijgen. Herhaling is de sleutel naar leren! Elimineer de handmatige taken zoals bijvoorbeeld goedkeuringen. Als iemand zijn stempel erop moet zetten, waarnaar kijkt deze person? Welke criteria wordt door hem gehanteerd om een release goed te keuren? Fail fast, fail often. “If It Hurts, Do It More Frequently, and Bring the Pain Forward”, from: Continuous Delivery by Farley & Humble

Behavior principles (The Three Ways) Stop Starting. Start finishing! Optimize the value chain by removing constraints and bottlenecks. Automate and eliminate manual turn-overs Eliminate manual approvals by introducing automated controls Techniques: reduce batch size, short intervals of work, build in quality controls, focus on a single task (no context switching), one goal Automate and amplify feedback from right to left (“Ops to Dev”) Automate testing Integrate monitoring and telemetry Techniques: unit testing, integration testing, UI testing. Apply telemetry platforms such as ApplicationInsights and DataDog. Integrate Quality Control platform such as SonarQube Dit is allemaal mooi als stip op de horizon, maar waar begin je? Stel je hebt de ambitie om de volgende Netflix te worden. Hoe pak je dat aan? Welk gedrag / cultuur moet je in de organisatie aanbrengen om naar de stip te reizen? DevOps gaat onderaan de streep over ‘lean’ software engineering. Lean is geen nieuwe term. In productie omgevingen worden lean principes al vele Jaren toegepast om alles uit een fabriek te halen in de meest efficiente manier en snelste tijd. Het orginele gedachte goed is ontworpen door Toyota in de Jaren ‘80. De DevOps gedachte bouwt voort uit de Lean Manufacturing principes. Resulterend in drie gedragsprincipes. Deze worden de “Three ways” genoemd. Facilitate a culture of experimentation, learning. Eliminate punishment after failure. Promote experimentation. Promote discoveries to working software Techniques: self managing teams, knowledge sharing sessions. Dedicate work time for experimentation. Fed-Ex days

What does it promise? Data from the field Wat zijn de beloften van DevOps? Deze beloften kan je gebruiken om beslissers en beinvloeders te overtuigen van de toegevoegde waarde van DevOps. Eerst vooraf, het is niet een process wat je als project aanvliegt. Ja, je hebt een begin, maar er is geen einde. Het is een continue evolutie. Zie deze quote uit de 2018 State of DevOps report.

DDD – DevOps – Microservices - Cloud How are all these buzzwords relate to each other..... Eerder dit jaar hebben we avonden als dit georganiseerd. We zijn in het voorjaar gestart met Git. Daarna zijn we ingegaan op Domain Driven Design. Vanavond dus DevOps. Hoe verhouden deze onderwerpen zich nu tot elkaar? Microservices, DDD, cloud. Deze buzzwords zijn naar mijn idee transporten om tot een DevOps operatie te komen. DDD maakt het mogelijk om via domeinen naar microservices te ontwikkelen waarbij het team volledige autonomie en verantwoordelijkheid heeft over de implementatie van het domein. Cloud technologien maakt het mogelijk om geautomatiseerd het domein in leven te houden en verder te evolueren. For some years now, many organizations spend lot of wording on these buzzwords. My take on it how they relate is the following. I see these paradigms complementary to each other. Yet, they can be utilized independently from each other. However, when blended together, organizations like Netflix, Amazon can exist. Not every organization has the means to go all-in on these paradigms. There is to my knowledge also not one correct starting point. So the question “where do I begin” is hard to answer. Use the classic “it depends”. Blending these concepts together is just since a few years possible because of having containers and microservices mainstream in Linux and Microsoft technologies. However still learning each day, I do see DDD as the catalyst and foundation of the software design. Using a deployment strategy to microservice or container for a bounded context, we can assure that the statement “it works on my machine” does apply. It does not matter whether the container runs in the cloud or locally on the developer workstation (yes, configuration management neglecting....  ). I am a technologist in basis. I like pictures. Recently I ran into a picture which covers the typical (reference) architecture of modern software systems. When you apply the architecture, the software should be able to run in a container in the cloud for its own bounded context.

The picture is split into 2 areas The picture is split into 2 areas. The left side presents te user / business perspective. The right side presents the technology side of the domain. In the center there is the domain. The domain is a protected area which holds the entities with their state and behavior. The domain is encapsulated with a services boundary to interact with the domain. The Domain Services responds to messages delivered on a bus. The flow of control is from the left to the right. That means that the driving side is sending commands/requests to the domain. The domain is sending commands/requests to the driven side. The driven side holds the dependencies the domain has. Yet, the dependencies are flowing inside towards the domain. In code, the domain talks to interfaces. The interfaces are made concrete by Inversion of Control containers at runtime.

Other sources (highly recommended!) Puppets’ State of DevOps reports (2016, 2017, 2018) How does Netflix manage their product: https://bit.ly/2I799VK

What is your perspective of DevOps? Start een discussie over wat men zelf onder de term DevOps verstaat. Schrijf kernwoorden op een flowchart