SATURN conference - Dag 2 - Devops & Architecture

Deze bijdrage is geleverd door Rogier Schrama

Dag 2 van de SATURN conference is achter de rug. Deze dag stond in het teken van de volgende onderwerpen:

• Architecture hoisting
• System design consequences of using DevOps practices
• Big Data – Architecture and technologies

System design consequences of using DevOps practices

Inmiddels wordt DevOps op steeds grotere schaal toegepast binnen organisaties. Sommige organisaties zijn hier succesvoller in dan andere. In veel gevallen bestaat het beeld dat de invoering van DevOps inhoudt dat het Dev team en het Ops team dichter bij elkaar worden gezet en dat er wat deployment handelingen worden geautomatiseerd. Maar als alleen die onderdelen worden aangepakt, zal vaak blijken dat de te de deployen software niet meewerkt. Releases en deployment zijn nog steeds intensieve en complexe processen met veel handwerk, applicaties zijn slecht in delen uit te rollen en verschillende ontwikkelteams zijn nog steeds te afhankelijk van elkaar.

De oorzaak hiervan is dat ook de architectuur van de oplossing bepaalde karakteristieken moet hebben die het mogelijk maken om te voldoen aan de criteria van DevOps als het gaat om continuous delivery en continuous deployment. De lijst met karakteristieken is opvallend lang, maar in deze post worden de belangrijkste genoemd.

Gebruik een micro service SOA

Micro services zijn (zeer) kleine services met een beperkte verantwoordelijkheid. De diepte van een micro service hiërarchie kan groot zijn. LinkedIn is hiervan een voorbeeld, met een diepte van 70. Kleine services maken uitrol eenvoudiger.

Asynchroon

Omdat services tijdelijk uit de lucht moeten kunnen zijn tijdens deployment, moet communicatie in alle gevallen asynchroon plaats vinden.

Robuustheid en tolerantie

Services moeten er tegen kunnen dat afhankelijke services tijdelijk niet beschikbaar zijn. Retry mechanismen moeten of in de infrastructuur of in de services zelf aanwezig zijn.

Interfaces en database schema’s mogen niet wijzigen

Wijzigingen aan service interfaces en database schema’s zijn in principe een no-go. Uitbreidingen zijn hierop de enige uitzondering.

Service discovery

De micro service architectuur maakt gebruik van discovery en zelf registratie bij een service registry na deployment

Deployment vs activatie

Er is een duidelijk verschil tussen uitrol en activatie. Nieuwe services worden eerst uitgerold waarbij ze in eerste instantie hun oude gedrag vertonen. Pas na activatie vertonen ze hun nieuwe gedrag.

Feature toggles

Oude en nieuwe versies van functionaliteit is aanwezig in services. Zogenaamde feature toggles, in wezen gewoon if-else statements, schakelen tussen oud en nieuw. Deze feature toggles kunnen zowel voor één als voor een groep services tegelijk gelden. De toggles worden beheerd door een feature toggle manager.

Kanarie test

Wanneer aan bovenstaande karakteristieken (en andere) wordt voldaan, kunnen services snel en onafhankelijk van elkaar worden uitgerold. Deze snelle uitrol heeft weer andere voordelen. Er kan namelijk worden getest ‘in productie’ door een nieuwe service samen met zijn voorgangers uit te rollen. De zogenaamde ‘kanarie test’. Door het gedrag van de nieuwe service of services te monitoren, kan bepaald worden of deze zich gedraagt zoals verwacht. Netflix bijvoorbeeld, monitort services op basis van 90 metrieke. Wanneer 90 procent hiervan ‘groen’ is, gaat een service definitief naar productie.

Conclusie

Deze post illustreert dat DevOps niet alleen een organisatorische en tool gerichte impact heeft, maar dat de opzet van de architectuur van de applicatie een significante invloed heeft op hoeveel winst er uit de methode kan worden gehaald.