ORDINA BLOGT

DevOps en microservices?

DevOps krijgt de laatste jaren steeds meer aandacht. Waaraan moet je denken, welke aspecten spelen een rol en hoe passen microservices hierin? Mijn visie hierover wil ik met jullie delen.

  • Henrich Gronloh
  • 17 mei 2016

Wat is DevOps?

DevOps is ontstaan als beweging waarin gezocht wordt om de samenwerking en communicatie van Development (Dev) en Operations (Ops) te verbeteren. Patrick Debois heeft deze verandering in denken aangewakkerd samen met Andrew Clay Shafer door in 2009 de eerste DevOps days te organiseren in Gent.

Afbeelding van de dit jaar geplande DevOps events op de site http://www.devopsdays.org/

Wat zou je onder deze verandering in denken kunnen verstaan? Wat mij betreft, het opzoeken van de samenwerking, experimenteren, fouten maken en daar van leren, denken in Win/Win en dus rekening houden met andermans belangen.

Ondertussen is DevOps een wereldwijde beweging waarin de volgende aspecten centraal staan (CALMS, Damon Edwards, Jez Humble):

  • Cultuur, je hebt het immers over de interactie van individuen, communicatie en samenwerken (Agile manifesto).
  • Automatisering, want je wilt versnellen door herhalende activiteiten te standaardiseren en automatiseren. Dit draagt bij aan het continue opleveren van waardevolle software. (Eerste Principe achter Agile manifesto).
  • Lean, de aspecten van het lean gedachtegoed, zoals b.v. het leveren van waarde aan je klant en continu verbeteren staan ook centraal.
  • Meten, zonder te meten is er geen feedbackloop mogelijk en die is essentieel om te verbeteren en te leren.
  • Sharing, zonder het delen van kennis kom je niet verder in de steeds veranderende wereld. Dit draagt bij aan het continu leren in een Agile omgeving.

Wat zijn microservices?

Volgens Martin Fowler gaat het bij een microservice architectuur om het bouwen van een softwareprogramma als verzameling van kleine services die je onafhankelijk van elkaar in productie gezet kunnen worden. De interactie tussen de services verloopt meestal via een API. Door het programma op te delen in kleinere onafhankelijke services creëer je flexibiliteit.

Business service die bestaat uit losse microservices waardoor er een flexibel geheel ontstaat

 

Waarom zijn softwareprogramma’s in het verleden als een geheel gebouwd?

Wat mij opvalt bij een aantal bedrijven is de complexiteit van het IT landschap. De ontstane architectuur heeft er onder andere toe geleid dat er veel afhankelijkheden zijn, grote downtijd bij incidenten en daardoor hoge beheer en onderhoudskosten. Dit is zo gegroeid in de loop van de jaren. Vaak zie ik een opsplitsing van functionaliteit in delen die de afdelingsgrenzen (silo’s) volgen. Denk hierbij b.v. aan de website, business logica services, de onderliggende database en de infrastructuur waarop deze draait. Voor elk onderdeel is weer een andere silo verantwoordelijk. Hier zie ik in de techniek de afspiegeling van de analytische bedrijfscultuur, waarbij efficiency-denken het belangrijkste is. Wel wordt de efficiency lokaal, per afdeling ingericht en wordt er niet vanuit de end to end ketens gedacht.

 

Waar zou je met je architectuur heen willen in een Agile omgeving?

In een Agile omgeving wil je zo snel mogelijk, de juiste producten met de juiste kwaliteit leveren. Eén van de mogelijkheden om dit te bereiken is om processen te verbeteren, ofwel de L uit CALMS. Het inrichten van een microservice architectuur zou ik hier onder scharen. Deze manier van anders je programma inrichten draagt bij aan flexibiliteit en zorgt er voor dat je sneller met je functionaliteit naar productie kunt met behoud van de kwaliteit. De verantwoordelijkheid voor de betreffende microservice komt dan bij één product team te liggen. Zo’n product team zou ik een DevOps team noemen.

Hoe kun je dan van de complexe rigide programma’s afkomen?

De eerste stap om naar een microservice architectuur te komen is om de samenwerking te stimuleren door meer waarde te hechten aan individuen en interacties dan aan processen en tools, de C in CALMS.
Hoe kun je hiermee aan de slag?

  • Denk in eindklant producten en niet in afdelingen.
  • Zoek de samenwerking op tussen architecten, ontwikkelaars, infra-specialisten en wie er verder ook nodig is om je plannen te realiseren.
  • Onderzoek samen de situatie. Denk hier bijvoorbeeld aan de volgende aspecten:
    • Welke service gaat het betreffende programmaonderdeel jouw klanten bieden?
    • Hoe ziet dan de bijpassende architectuur er uit?

Conclusie?

Een microservice architectuur zorgt voor een flexibele applicatie-omgeving en sluit goed aan bij het Agile gedachtegoed. Om dit te realiseren heb je de individuen en interactie nodig, een cultuur van Continuous Interaction. Het begint met de Agile mindset en van daaruit neem je de volgende stap.

Over de auteur:

Henrich Gronloh

Henrich Grönloh is een ervaren Agile Coach. Hij adviseert, traint, coacht en begeleid management en medewerkers bij het toepassen van Agile en Lean in de organisatie. Hij heeft diverse uitrollen gedaan van Scrum, Kanban, DevOps en verschillende processen verbeterd.