De omgeving waarin DevOps-teams actief zijn verandert continu. Wat vandaag nog een compleet normale werkwijze is, kan morgen al hopeloos verouderd zijn. Als DevOps-team moet je je hieraan kunnen aanpassen. Het is daarbij van groot belang te weten wat de achterliggende krachten zijn die deze veranderingen sturen. In de wereld van DevOps zijn er drie sterke krachten te onderscheiden:

1. De kracht van cloud platforms
2. De kracht van systeemarchitectuur
3. De kracht van samenwerking

Let op: het is gebruikelijk dat een DevOps-team wordt ondersteund door een service delivery team. Wanneer het DevOps-team bijvoorbeeld weinig ervaring heeft met een cloud infrastructuur, kan het service delivery team bijspringen. Door bijvoorbeeld omgevingen in te richten of releases te configureren. De krachten die ik in dit artikel bespreek, zijn van toepassing op zowel DevOps- als service delivery teams.

1. De kracht van cloud platforms

Dankzij hun razendsnelle ontwikkeling, zijn cloud platforms een sterke aanjager van veranderingen in de wereld van DevOps. Traditioneel werkte een Ops-team on-premise: op locatie bij de opdrachtgever. In deze situatie was het gemakkelijk machines te beheren, onderhouden, monitoren, patchen, etc. Ergens in een datacentrum knipperden de lichtjes en bungelden de kabeltjes, terwijl het team vrolijk peperdure SLA’s in het rond stuurde aangezien alles binnen de eigen invloedsfeer lag. Deze situatie veranderde met de opkomst van cloud platforms, in grofweg vier fases:

• IaaS (Infrastructure as a Service)
• Container based systems
• PaaS (Platform as a Service)
• Serverless platforms

Fase 1: IaaS

In fase 1 bestaan cloud platforms nog uit machines, die in een bepaalde samenstelling georganiseerd zijn (zoals in onderstaande afbeelding).

Deze vorm van cloud computing betekent voor de betrokken teams een geleidelijke en niet al te ingewikkelde verandering. De teamleden moeten de belangrijkste valkuilen kennen van werken in de cloud, maar kunnen verder vertrouwen op hun kennis en ervaring van de on-premise-situatie. Teams die meer aan de development-kant zitten, zullen iets over infrastructuur moeten bijleren. Voor Ops-geörienteerde teams verandert er nauwelijks iets.

Fase 2: Container based systems

Cloud platforms kunnen gaandeweg steeds meer. Ook op het gebied van service delivery. Vooral de mogelijkheden van container based systems zijn in deze context interessant. Docker containers verpakken een stuk software binnen een bestaand (en compleet) systeem, voorzien van alles wat nodig is om het te laten draaien. Zo weet je zeker dat de software altijd op dezelfde manier werkt, ongeacht de omgeving.

Containers maken het leven van DevOps-teams een stuk makkelijker, doordat ze gemakkelijk kunnen worden aangemaakt en verplaatst. Vanuit operationeel oogpunt is er weinig verschil met IaaS: het containersysteem is een infrastructuur met een besturingssysteem en een netwerkbehoefte. Toch zijn er op het gebied van operations wel wat uitdagingen. SumoLogic(externe link), leverancier van cloud-oplossingen, verwoordt het als volgt:

“Docker allows you to quickly and easily deploy hundreds or thousands of containers with minimal overhead. But once deployed, managing and tracking that environment can be a challenge. How do you know:

• Which containers are using the most system resources?
• Which containers are down?
• How many containers are currently running in my environment?”

Fase 3: PaaS

Azure Cloud Services en Google App Engine zijn voorbeelden van PaaS-toepassingen (Platform as a Service). De invloed van deze toepassingen op het operationele vlak is nog groter dan die van de containers. Kort door de bocht kun je zeggen dat het onderhouden en monitoren van de infrastructuur overbodig is geworden dankzij PaaS. Helaas is dat wat te makkelijk gedacht.

Een complicerende factor is de ‘mate van PaaS’ die verschillende toepassingen hebben. RedHat OpenShift bijvoorbeeld, is feitelijk meer een IaaS dan een PaaS. Terwijl er ook aanbieders zijn die aan de compleet andere kant zitten en meer op een SaaS lijken (Software as a Service). Binnen Microsoft Azure is het onderscheid duidelijk te zien: vergelijk de Azure App Services maar eens met de meer klassieke toepassingen Azure Worker en Azure Web Roles.

In algemene zin: hoe dichter een PaaS-toepassing bij IaaS ligt, hoe groter de behoefte is aan traditionele operationele activiteiten. Als het gaat om onderhoud verandert er in de meeste gevallen niet zoveel ten opzichte van de on-premise-aanpak.

Fase 4: serverless platform

De zogenaamde serverless platforms zijn de ultieme vorm van PaaS. Hierbij hoeft er niet te worden geïnvesteerd in platformkennis, aangezien alles (scaling, netwerk, etc.) wordt georganiseerd en onderhouden door de provider. De enige uitzondering wordt gevormd door de functies. Kijk voor een volledige definitie van het serverless platform hier(externe link). Voorbeelden van serverless platforms zijn Azure Functions, Azure Service Fabric, AWS Lambda, Google Functions en IBM Bluemix OpenWhisk.

Op operationeel vlak komen er bij serverless platforms andere zaken kijken dan bij traditionele IaaS- en PaaS-toepassingen. Het vereist monitoring van de functies en hoe deze zich gedragen. Met andere woorden: niet het platform, maar de kernfunctionaliteiten van het systeem moeten bewaakt worden. InformationWeek beschrijft het verschil als volgt:

“In the future, […] the enterprise IT staff developer will be focused on constantly improving the logic of the customer’s interaction with the business, instead of figuring out how to set up and maintain a database server and other infrastructure issues. (Uit: How Serverless Applications Will Change Your Business(externe link))

Cloud providers bieden een breed spectrum van serverless platforms aan, allemaal met hun eigen operationele en organisatorische behoeften. Microsoft Azure kent veel verschillende diensten.

De meeste van deze diensten zijn PaaS-oplossingen en allemaal hebben ze hun eigen onderhoud nodig. Zo kan een PaaS SQL-server niet zonder het traditionele SQL-onderhoud. Verder dienen alle diensten te worden ondersteund door het DevOps-team, waardoor er specialistische kennis vereist is. Het gaat dan bijvoorbeeld om kennis van machine learning of van big-data-oplossingen als Hadoop en Azure IoT Stream Analytics. Dit kan een behoorlijke uitdaging zijn voor het DevOps-team.

2. De kracht van systeemarchitectuur

Cloud platforms mogen dan een invloedrijke kracht vormen (‘The force is strong in this one’), ze zijn niet de enige drijvende kracht achter DevOps. Ook de architectuur van het systeem speelt een niet te onderschatten rol. Deze heeft zich al ontwikkeld van een monoliet-achtige samenstelling (met operationele collega’s in doktersjassen), naar losjes samenhangende aparte systemen. Van een ‘one stop shop’ met een ‘deploy and maintain’-instelling, tot een systeem van verdeelde functionaliteiten en afgebakende verantwoordelijkheden. Zie ook de Microservices Resource Guide(externe link).

Deze nieuwe vormen van service design vragen om kennisontwikkeling van developers, maar ook aan de operationele kant moet hierop worden ingespeeld. Dit alles om te zorgen voor een flexibel, snel inzetbaar en loosely coupled systeem met gescheiden verantwoordelijkheden. Grote spelers als Netflix en Spotify wijzen op het belang van dit soort microservices: “He argues that Microservices are easier to test, deploy and monitor than monolithic applications. Spotify also aims to have as few as possible dependencies in their product, and microservices are very helpful for that. With rise of the amount of services also the amount of integration increases. Architectural Integration patterns are getting more important, and also the operations of these loosely systems are getting more complex.”
(Uit: Microservices at Spotify(externe link))

“At Netflix we pioneer new cloud architectures and technologies to operate at massive scale – a scale which breaks most monitoring and analysis tools. The challenge is not just handling a massive instance count but to also provide quick, actionable insight for a large-scale, microservice-based architecture.” (Uit: Netflix blog(externe link))

Als gezegd bieden cloud providers steeds meer keus, waardoor het steeds makkelijker wordt om een passend systeem (of een combinatie van verschillende systemen) te vinden. Van combinaties tussen PaaS-, SaaS-, IaaS- en on-premise-systemen hoeven we niet meer raar op te kijken. Een mooie mix van Azure-oplossingen vind je hier: Building a DevOps Assessment tool with VSTS, Azure PaaS and OneShare in minutes.(externe link)

Een microservice-gerichte systeemarchitectuur brengt specifieke eisen met zich mee voor operations en onderhoud, maar ook voor het DevOps-team. Denk hierbij bijvoorbeeld aan het releasen van componenten in een OTAP-omgeving.

3. De kracht van samenwerking

‘Agility’ is een belangrijk aandachtspunt voor bedrijven. De kracht van cloud platforms speelt hierop in. Met de kracht van systeemarchitectuur kunnen we systemen in kleinere subsystemen opdelen en daarmee de functionaliteit van (small) business verbeteren. Maar hiermee zijn we er nog niet. Ook de manier waarop het DevOps-team de werkzaamheden inricht en de processen stroomlijnt, is een invloedrijke kracht. En dan gaat het vooral om de culturele kant, om het samenwerken met meerdere disciplines en met de klant. Teams hebben tegenwoordig de intentie om betere producten te maken door dichter bij de klant te staan en flexibeler te werk te gaan in cross-functionele teams. Het is een ontwikkeling die ouder is dan we denken, want deze komt voort uit een manifest van alweer vijftien jaar oud.

DevOps-teams zijn ontstaan in traditionele DTAP-omgevingen. Het sequentieel implementeren van een nieuw systeem in al deze omgevingen, met alle goedkeuringsfases die daarbij horen, is een traag en duur proces. Zie: The Time of DevTest Labs is over. DevOps to the Max.(externe link)

Vrijwel alle teams gaan aan de slag vanuit de gedachte om de release cycle te verkorten. DevOps dient hiervoor als katalysator. Voorbeelden van methoden zijn Infrastructure as Code en het soortgelijke Immutable Servers. Beide hebben een grote invloed op het DevOps-team (zie ook: Treating Servers as Cattle, Not as Pets(externe link)). Ook containers, ooit bedoeld om DevTest-scenario’s(externe link) te versnellen, spelen hierin een rol. Dankzij dit soort DevOps-toepassingen, die in hoog tempo voorzien in nieuwe omgevingen, is het mogelijk om prettiger te werken (en samen te werken) met klanten en business owners.

Daarnaast is het mogelijk om het hele proces van development en testing over te slaan en direct aandacht te besteden aan de business features die door de klant zelf worden gebruikt. Voorbeelden van methoden die dit faciliteren zijn Feature Toggles, Testing in Production, A/B-testen en Canary Release. De invloed van deze werkwijzen op DevOps is groot, vooral vanuit operationeel oogpunt. Dit zit ‘m vooral in de directe interactie met productie.

De aanjagers van de kracht van samenwerking zijn flexibel blijven, de complexiteit beheersen en continu communiceren. Deze aandachtspunten moeten organisatiebreed gedragen worden. 

Meer informatie over DevOps? 

Bent u benieuwd naar hoe DevOps in de praktijk werkt, welke krachten dan spelen en hoe u dit voor uw organisatie kunt toepassen? Neem dan contact met ons op via de contactgegevens hiernaast.