Onze visie op DevOps in 2024

De CTO's van onze drie units - Data, DevOps en Development - vormen samen met de CTO van CINQ een denktank: de CINQTank. Zij houden zich bezig met het “voorspellen” van de toekomst. Samen met de mensen uit de units kijken zij in de verschillende vakgebieden naar de ontwikkeling van technieken en tools. Hiermee wordt een technische visie gecreëerd. Deze wordt onder andere gebruikt om richting te geven aan de opleiding van medewerkers. Tevens wordt het gebruikt als input voor de jaarplannen van elke afdeling. Tot slot is het natuurlijk ook gewoon leuk om na te denken hoe de toekomst eruit zou kunnen zien. Hieronder lees je onze verwachtingen op het gebied van DevOps in 2024.

Terugblik

Onze DevOps unit heeft zich goed ontwikkeld het afgelopen jaar. We hebben veel nieuwe kennis en kunde naar binnen gehaald en zijn samen hard aan het werk om hier een hecht team van te maken.

In het afgelopen jaar hebben we geprobeerd de DevOps unit zich meer te laten specialiseren in SRE en CI/CD specialisaties. Deze exercitie bleef alleen achter bij de markt. De komst van Platform Engineering gaat in volle vaart. Waar we voorheen te maken hadden met SRE en DevOps, hebben we nu meer te maken met termen als Platform Engineering, Customer Facing Teams, Enabling Teams en Feature Teams. Bij CINQ volgen we deze ontwikkelingen nauwkeurig en passen we onze trainingssessies en certificeringen indien nodig aan gedurende het jaar.

In de afgelopen jaren hebben we gemerkt dat Azure de belangrijkste cloudleverancier is voor Nederlandse bedrijven. Hierdoor hebben de meeste consultants binnen de DevOps unit inmiddels ervaring met Azure opgedaan bij diverse klanten.

Een jaar vooruit

Wat blijft

Er blijft een beperkte markt voor OpenShift en Rancher. Deze tools zorgen ervoor dat bedrijven ‘on-premise’ nog steeds gebruik kunnen maken van Kubernetes clusters. Dit geeft ze de vrijheid om zonder cloud toch op een relatief makkelijke manier Kubernetes te gebruiken.
Hoewel er niet heel veel bedrijven zijn die per se hun eigen lokale datacenter willen beheren, zullen ze ook waarschijnlijk niet helemaal verdwijnen. Deze bedrijven hebben vaak een heel specifieke reden om toch onafhankelijk te blijven van de cloud. Denk hierbij aan eisen om onafhankelijk van het Internet te kunnen blijven functioneren of strikte eisen rondom onafhankelijkheid eisen als het gaat om de makers van de software.

Wat komt eraan

Nu Kubernetes volledig ingeburgerd is, stijgt de vraag naar complexere setups voor specifieke doeleinden. Onder andere tools als Flux en ArgoCD die de plek van GitOps deployment tools innemen, zijn sterk in opkomst. Hierbij nemen ze een stuk van het speelveld van Azure DevOps en GitLab over als het gaat om de verantwoordelijkheid over het deployen van applicaties en containers.
Er blijft een titanenstrijd in de markt als het gaat om bijvoorbeeld het gebruik van Azure DevOps, GitHub en GitLab als het gaat om het deployen van applicaties op Kubernetes.

We zien een sterke opkomst voor Cilium, een moderne Container Network Interface (CNI) provider, welke daarnaast ook nog uitgebreide networking en security features bevat.
Azure ondersteunt tegenwoordig Cilium als default CNI. CINQ wil daarom volgend jaar extra aandacht besteden aan haar kennis rondom Cilium.

Kubernetes is en blijft populair. We zien een stijging in aanvragen rondom hulp bij migratie vanuit ouderwetse on-premise omgevingen naar Cloud of private-cloud(-achtige) omgevingen, ook bij de kleinere bedrijven. We verwachten dat we hier het komende jaar nog meer van gaan zien.

We zien een sterke stijging in de vraag naar Security tooling. Waar het eerst belangrijk was hoe we op Kubernetes deployen, is het nu belangrijk wat we deployen. Bedrijven willen beter inzicht in waar deployments fout gaan en betere indicaties waar afwijkingen zitten in het gedrag van applicaties. Men wil hiermee beter inzicht krijgen in de werkzaamheden van gebruikers (en beheerders) op de diverse systemen.
Hiermee willen de bedrijven zich wapenen tegen de alsmaar complexere methodes die gebruikt worden om systemen over te nemen of op andere manieren onterecht te belasten (denk aan bijvoorbeeld cryptominers).

Er is een sterke focus gekomen op het inzichtelijk maken van kosten binnen Kubernetes. Waar voorheen vrijwel alles mocht op Kubernetes binnen de security boundaries van het platform, wordt er nu meer gestuurd op kosten. De vraag naar tooling die deze kosten inzichtelijk maakt is daarmee sterk stijgende. Tools als OpenCost, Kubecost, maar ook diverse SaaS oplossingen spelen hierin een grote rol.

We zien een beperkte maar toch wel duidelijke nieuwkomer binnen het DevOps landschap in AI (Artificial Intelligence). Met de lancering van ChatGPT is er voor een heel aantal markten best wat veranderd. Deze veranderingen bleven voor de DevOps unit beperkt, maar lijken wel hun weg te vinden in de tools die we gebruiken. Zo zien we op verschillende SaaS omgevingen de mogelijkheid om door middel van AI vragen te stellen, of probleemoplossers te gebruiken. Deze trend zal zich in de komende jaren mogelijk uitbreiden naar meer van onze tooling.

Naast alle hippe nieuwe technieken die de kop op steken, hebben we soms ook de ‘slow-and-steady’ groei onderwerpen. Zo is er ook de trend rondom API Gateways. Deze gateways helpen developers (en afnemers) een inzichtelijk, veilig en ontwikkelaars vriendelijk platform te bieden om (veelal REST) API’s makkelijk te kunnen publiceren. We zien steeds meer vraag naar tooling in dit landschap, en we gaan hier in het nieuwe jaar meer aandacht aan besteden binnen onze unit.

Wat gaat er weg

We zien een sterke daling bij oplossingen die niet ‘cloud-native’ zijn in hun deployment model. We denken daarbij aan oplossingen als het deployen van applicaties door middel van Jenkins of XLDeploy. Deze tools zijn minder geliefd onder developers en beheerders, waardoor ze sterk dalen in populariteit.

Ook de oudere “machine-beheer” oplossingen als Puppet, Chef en Ansible zijn op zijn retour, waar de laatste nog wel redelijk veel wordt gebruikt in combinatie met workflow-achtige zaken.

Voor een overzicht van de technieken die prevalent zijn, is er hieronder (afbeelding 1) een Hype diagram gemaakt. Dit diagram weerspiegelt onze visie op de positie van verschillende tools en technieken als het gaat om de fase waarin ze zich bevinden.

• Innovating: Een tool/techniek is opkomend en heeft mogelijk potentie, maar nog niet de 'tractie' om daadwerkelijk het verschil te kunnen maken.
• Peaking: De tool/techniek is veel gevraagd en er is veel aandacht voor, maar de markt heeft zich nog niet aan de tool aangepast.
• Disillusionment: De fase dat een tool/techniek hoog in de hype zit, waardoor veel mensen en bedrijven die het gaan proberen, erachter komen dat de techniek nog niet volwassen genoeg is, waardoor er vaak veel integratieproblemen worden gevonden.
• Enlightenment: De tool/techniek bevindt zich in een fase waarin deze zich aan het ontplooien is en goed samen kan werken met andere applicaties in het landschap.
• Productivity: De tool/techniek is zover doorontwikkeld dat deze echte productiviteit oplevert voor haar gebruikers.

Afbeelding 1: Overzicht hype per tool / techniek

Verder vooruit

Wat blijft

We denken dat er een lange termijn plek is voor tools als de ELK-Stack (ElasticSearch, Logstash  en Kibana), Prometheus, AlertManager en Grafana. Deze monitoring en logging tools zijn diep ingebed in diverse omgevingen en we zien deze niet snel verdwijnen.

Wat komt eraan

De verwachting is dat Kubernetes nog een flinke tijd relevant blijft. De community is sterk groeiend en het momentum blijft sterk. Diverse grote partijen blijven hevig investeren in het landschap, waardoor steeds meer uiteenlopende problemen in de IT opgelost kunnen worden door middel van Kubernetes.

We zien bijvoorbeeld dat er complete security stacks en digitale ontwikkelomgevingen op Kubernetes worden gedraaid. Daarnaast zien we ook een stijging in de mate van controle die bedrijven toe willen passen en beperking van de vrijheid voor ontwikkelaars door oplossingen als Kyverno en Polaris. Deze oplossingen helpen en beschermen developers op het gebied van de beveiliging van hun container landschap.

Als DevOps unit houden we ons daarnaast bezig met het beter in kaart brengen van onze klanten. Vanuit de Data unit is er een uitstekend model gemaakt, waarin het landschap kan worden gecategoriseerd. Deze categorisering heeft als doel om zowel ons als de klant duidelijk inzicht te geven in welke aspecten van hun IT landschap en/of omgeving CINQ een versterkende rol kan spelen. Deze aspecten zijn geclassificeerd om duidelijk uitvoerbaar te zijn door onze consultants. Hierdoor geven we beide partijen een leidraad om duidelijk aan te kunnen sluiten bij de wederzijdse verwachtingen.

We willen ons als DevOps unit ook sterk gaan maken voor een Terraform standaard.
Deze standaard wordt een leidraad om te laten zien dat we weten waar we over praten. Zowel voor onszelf (tussen onze collega’s) als de markt (wat kunnen wij als bedrijf) laten we hiermee zien dat we echt verstand van zaken hebben en deze kennis willen delen.

Het idee is om samen als unit een aantal dagen bij elkaar te komen om een standaard op poten te zetten en deze daarna uit te werken tot een werkende implementatie. Deze standaard gaan we proberen zo gedetailleerd uit te werken, dat het niet alleen maar ideeën zijn die met potlood in een workshop gebruikt kunnen worden, maar die echt herbruikbare code op zouden moeten leveren, welke als grondbeginsel kan fungeren bij diverse klanten.

Wat gaat er weg

Zoals eerder geschreven, merken we dat de term SRE binnen het DevOps landschap minder tractie heeft. De term Reliability Engineering wordt vaker als een losse pijler neergezet bij grotere bedrijven en daarmee ook anders aangepakt. We zien een stijging in het gebruik van de term in specifieke afdelingen die hiervoor speciaal ingericht worden. Deze afdelingen zijn dan ook vaker verantwoordelijk voor de tooling die daar bij komt kijken. Hierdoor zijn mensen uit onze unit minder vaak verantwoordelijk voor deze tools en verdwijnt het werk hieraan dus.

Onze verwachting vorig jaar was dat Docker zou verdwijnen als Container Runtime. Inmiddels zijn alle grote Cloud omgevingen, en Kubernetes distributies overgestapt op `containerd`. Daarmee is de noodzaak voor Docker in productieomgevingen weg en is Docker alleen nog een veelgekozen applicatie in het bouwproces van containers. Veel ontwikkelaars begrijpen wat Docker is en weten wat het doet, en gebruiken het dan ook als een term om een algemene container omgeving aan te duiden. (Platform) beheerders begrijpen daarentegen vaak beter dat Docker niet meer nodig is om containers te draaien en weten dat het niet meer nodig is om Docker te draaien onder Kubernetes clusters.

Kruisbestuiving

Als DevOps unit zien we een steeds sterkere drang om onze krachten te bundelen binnen CINQ. We merken dat met tools als Terraform en Ansible de kunst van het programmeren sterk helpt in het leveren van hoogwaardige en kwalitatieve oplossingen.

We merken dat als we echt aan de voet van de complexe architectuur vraagstukken, ontwerp discussies en uitvoering van deze tools moeten staan, men echt stevige ontwikkel skills nodig heeft. Begrippen als resiliency, do-not-repeat-yourself, interfacing en dependency management zijn programmeer skills die hard nodig zijn bij deze vraagstukken. Daarom zoeken we ook sterke toenadering tot de Development unit en willen we samen deze vaardigheden naar een hoger niveau tillen.