Hoewel PaaS-oplossingen (Platform as a Service) op zichzelf niet in staat zijn om de manieren van individuele en teaminteractie te veranderen, dienen ze vaak als catalysator voor organisatieveranderingen als reactie op de toegenomen flexibiliteit van IT-technologieƫn.
In de praktijk is de maximale opbrengst van investeringen in PaaS meestal alleen mogelijk door veranderingen in organisatorische rollen, verantwoordelijkheden (taken) en relatiepatronen. Gelukkig hebben PaaS-oplossingen zoals OpenShift Container Platform voldoende flexibiliteit zodat elke IT-organisatie zelf de snelheid en omvang van veranderingen kan bepalen met betrekking tot de betrokken mensen en processen.
In de eerste fase van containerisatie is de belangrijkste prioriteit de implementatie van de containerplatform als nieuw systeem voor de inzet van applicaties. Op dit moment koppelen organisaties bekende werkzaamheden aan vertrouwde rollen, zodat ze kunnen reageren op standaardverzoeken van ontwikkelteams met betrekking tot opslag systemen, inzetomgevingen, enz. In latere fasen van containerisatie gaat het al om automatisering of het bieden van self-service mogelijkheden aan ontwikkelaars om de belasting van systeembeheerders te verlichten en de autonomie en efficiƫntie van ontwikkelaars naar een hoger niveau te tillen. Zo begint de organisatie de weg naar DevOps in te slaan. In de laatste fase van containerisatie komt de onderneming aan bij een schoner, canoniek DevOps-model, waarin veel van de eerdere taken en werkzaamheden onder controle komen van cross-functionele teams, die niet zijn gegroepeerd op basis van platforms of technologieƫn, maar vanuit het perspectief van het waarborgen van de werking van applicaties of toepassingsdiensten.
In deze post presenteren we een handleiding voor het doorvoeren van de noodzakelijke organisatorische veranderingen en bespreken we hoe traditionele IT-rollen veranderen met de invoering van containertechnologieƫn in de onderneming.
De koppeling van nieuwe werkzaamheden aan oude rollen
In zijn basisvorm wordt het organisatorische model PaaS gevormd om IT-middelen flexibeler en sneller aan applicaties te bieden als een runtime-omgeving. En hoewel dit bepaalde voordelen biedt voor systeemauditeurs, ontvangen ontwikkelaars hier doorgaans geen significante voordelen en nieuwe mogelijkheden, aangezien het bedrijf in deze fase prima zonder automatisering, zelfbediening of aanzienlijke verbeteringen van de implementatiepijplijn kan doorgaan. Ondanks dat het de ontwikkelingsprocessen in deze fase minimaal beĆÆnvloedt, verhoogt PaaS de dynamiek van het IT-systeem, waardoor beheerders beter kunnen inspelen op de aanvragen van ontwikkelaars. Bijvoorbeeld, als het vroeger dagen of zelfs weken kostte om een ontwikkelomgeving op te zetten uit verschillende virtuele machines en opslagvolumes, waarbij verschillende admins betrokken waren, gebeurt alles met PaaS veel sneller en door slechts Ć©Ć©n beheerder. Met andere woorden, ontwikkelteams dienen zoals voorheen aanvragen in, maar het werk om deze aanvragen te realiseren wordt volgens een nieuw schema uitgevoerd.
Op weg naar een DevOps-organisatie
Door PaaS in te voeren en IT-systeembeheerders en applicatieontwikkelaars naar deze omgeving te verplaatsen, kan de organisatie de implementatie van de DevOps-methodologie voortzetten, die onder andere de volgende kernprincipes omvat:
- Het werk opdelen in kleine fases, om vroegtijdig feedback te ontvangen, risico's te verminderen en 'analytische verlamming' te voorkomen;
- Operaties voldoende automatiseren, om geen hindernissen of knelpunten te creƫren in het implementatieproces van applicaties;
- Kennisdeling is de sleutel tot het opbouwen van vertrouwen;
- Regelmatig technische schulden aflossen, door in elke werkcyclus tijd vrij te maken voor systematische verbeteringen.
In de tweede fase van de implementatie van containertechnologieƫn beginnen de ontwikkelteams natuurlijk mogelijkheden voor verbeteringen te zien, en de organisatie neigt naar een meer canonieke DevOps-modell. Het traditionele mechanisme van aanvragen en uitvoeren van onderhoud wordt nu gezien als een knelpunt, waardoor de organisatie streeft naar automatisering van repetitieve taken en de mogelijkheid voor ontwikkelaars om zelfbediening te bieden. Bovendien worden deze mogelijkheden voor ontwikkelaars in het kader van een bepaalde aanvraag bepaald door de gezamenlijke inspanningen van IT-specialisten die verantwoordelijk zijn voor het platformbeheer en degenen die verantwoordelijk zijn voor de applicatiedelivery. Met andere woorden, in plaats van systeembeheerders die de aanvragen van ontwikkelaars afhandelen, komen twee hierboven genoemde categorieƫn medewerkers die verantwoordelijk zijn voor het beschrijven en toepassen van beleidsregels die reguleren wat ontwikkelaars zelf mogen doen. Geautomatiseerde procedures helpen ervoor te zorgen dat aan de genoemde vereisten wordt voldaan en coƶrdineren de acties in gevallen waarin de situatie buiten de geldende beleidslijnen valt.
De overgang naar een iteratieve tijdlijn, waarin de IT-omgeving en het operationele model in de loop van de tijd iteratieve veranderingen ondergaan, is een cruciale mijlpaal in het opbouwen van een volwassen DevOps-systeem binnen de organisatie. De mate van acceptatie van de DevOps-methodologie hangt af van de tolerantie van elke individuele organisatie voor veranderingen en van welke veranderingen de meeste voordelen opleveren. Bijvoorbeeld, als de behoefte aan het creƫren van nieuwe omgevingen of applicaties niet vaak voorkomt, zal de optimalisatie van de bijbehorende acties minder belangrijk zijn dan het versterken van de controle van ontwikkelaars over de levenscyclus van applicaties.
Nieuwe taken die ontstaan in IT-organisaties bij de overgang naar OpenShift
In dit deel zullen we de rollen en taken bekijken die organisaties die zijn overgestapt op OpenShift meestal toepassen om automatisering en zelfbediening te versnellen met behulp van technologieƫn en PaaS.
In de onderstaande tabel staan de belangrijkste taken op hoog niveau vermeld die bestaan in elke organisatie die OpenShift heeft geĆÆmplementeerd, met voorbeelden van bijbehorende werkzaamheden en vaardigheden. Deze lijst van taken moet niet verward worden met een taakverdelingsschema of de organisatiestructuur van teams; het is slechts een reeks taken die moeten worden uitgevoerd door de personen die verantwoordelijk zijn voor het beheer van de IT-omgeving, om een succesvolle implementatie van het containerplatform te waarborgen. In feite zullen we verderop laten zien dat de implementatie van containertechnologieĆ«n de basis legt voor een rijpere DevOps-strategie binnen de onderneming, wat op zijn beurt de cross-functionele samenwerking van teams vergroot en de risico's van een te nauwe specialisatie op zowel individueel als teamniveau vermindert.
Tabel 1. Definities van OpenShift-taken
Taken
Vereiste vaardigheden
Automatisering en provisioning van IT-infrastructuren
Taken:
- Ontwerpen en bouwen van hardwareoplossingen
- Organiseren en ondersteunen van automatisering van initiƫle configuratie
- Ontwerpen en automatiseren van de voorbereiding van VM's en hosts
- Ontwerpen en implementeren van datacenters
- Systeemadministratie van Linux
- Automatiseringsscripts
- Kennis van opslagoplossingen
- Kennis van netwerkontwerp en -implementatie
- Beveiliging
Installeren en beheren van het OpenShift-platform
Taken:
- Uitvoeren van clusterinstallatie
- Beheer van infrastructuurservices
- Beheer van de schaalbaarheid van het platform
- Authenticatie en autorisatie op platformniveau
- Systeemadministratie van Linux
- Kennis van netwerktechnologieƫn
- Automatiseringsscripts (Ansible)
- Kennis van opslagoplossingen
- Kennis van containertechnologieƫn en architecturen
- Kennis van Kubernetes- en OpenShift-architecturen
- Beveiliging van platforms
- Integratie van monitoring
Beheer van tenant provisioning, isolatie van IT-capaciteiten
Taken:
- Gebruikers en teams aanmaken binnen het platform
- Ontwerpen en beheren van quota
- Ontwerpen en implementeren van RBAC
- Kennis van Kubernetes- en OpenShift-architecturen
- Kennis van containertechnologieƫn en architecturen
- Automatiseringsscripts
- Goede kennis van projecten, quota, rolbinding en werken met planners
Samenstellen en beheren van basisonderdelen
Taken:
- Ontwikkelen van workflows voor het wijzigen van onderdelen
- Ontwikkelen van onderdelen op basis van standaarden
- Systeemadministratie van Linux
- Automatiseringsscripts
- Configureren van runtime-componenten van applicaties en middleware
- Kennis van containerarchitecturen
- Application build frameworks
- Goede kennis van onderdelen, imagestreams en sjablonen
Ontwerpen en beheren van deployment pipelines
Taken:
- Ontwerpen en documenteren van pipeline-standaarden
- Ontwikkeling van korte handleidingen en sjablonen
- Opleiding van ontwikkelaars
- Beheer van de broncode
- Ontwerpen en implementeren van applicaties
- Automatiseringsscripts
- Geautomatiseerd testen
- Kwaliteit van de code testen
- Kennis van containerarchitecturen
- Kennis van immutable infrastructuren
- Beveiliging - beheer van toegang tot pipeline-stadia, goedkeuring van workflows, enz.
- Goede kennis van OpenShift-sjablonen, buildconfigs, deploymentconfigs, services, routes, configmaps
Ontwikkelen van applicaties en testen
Taken:
- Coderen van applicaties
- Ontwikkelen van geautomatiseerde tests
- Reageren op testfouten tijdens de deployment pipeline
- Reageren op applicatiefouten
- Gebruikersacceptatietesten
- Ontwerpen en implementeren van applicaties
- Geautomatiseerd testen
- Beheer van de broncode
- Applicatiemonitoring
- Kennis van architecturen voor cloud-native applicaties
Operationele monitoring en beheer van applicaties
Taken:
- Ontwerpen van applicaties met het oog op prestaties
- Monitoren van applicaties tijdens uitvoering
- Schaalbaarheid van applicaties (of autoscaling)
- Beheer van applicatiebeschikbaarheid
- Quotas voor verzoeken en limieten voor resourcebeheer
- Prestatie- en IT-capaciteitstests
- Ontwerpen en implementeren van applicatieprestaties
- Monitoring van applicatiewerkprestaties
- Prestatie- en loadtesting
Gebruikersacceptatietesten
Taken:
- UI-testing (ontwerp en gebruikersinteractie)
- Ontwikkelen van geautomatiseerde tests
- Ontwerpen en verifiƫren van gebruikersinterfaces
- Sjablonen voor geautomatiseerd testen
- Testframeworks
- Ontwerpsjablonen voor applicaties
Nieuwe rollen die ontstaan binnen IT-organisaties tijdens de overstap naar OpenShift
Terwijl organisaties overgaan op een DevOps-gerichte organisatorische model, neemt over het algemeen het aantal gespecialiseerde rollen af, terwijl het aantal cross-functionele teams en rollen toeneemt om de efficiƫntie van samenwerking te maximaliseren. Dit is hoe wij de lijst met kernposities in een IT-organisatie die OpenShift benut, zien:
- Application Operations Engineer OF Site Reliability Engineer. Eerder stond deze functie bekend als 'Applicatieserverbeheerder'.
- Applicatieontwikkelaar/softwareontwikkelaar/programmeur.
- Cluster-/applicatieplatformbeheerder. Deze rol werd eerder aangeduid als 'Systeembeheerder' of 'Linux-platformbeheerder'.
- Release Manager / Build Engineer.
RACI-rolmatrix
Ten slotte komen we bij de afstemming van de hierboven besproken posities en taken om een algemeen overzicht te geven van hoe de organisatiestructuur eruit moet zien voor het implementeren van DevOps op het OpenShift-platform. Aanvankelijk kunnen de onderstaande rollen worden vervuld door verschillende afdelingen binnen de oude, traditionele organisatiestructuur. Maar na verloop van tijd vindt er consolidering plaats en ontstaan er nieuwe teams, geconcentreerd rond applicaties, die de meeste of zelfs alle hieronder genoemde taken op zich nemen.
Taken
Rollen
Applicatiebeheerder / Site Reliability Engineer
Applicatieontwikkelaar / Software Developer / Software Engineer
Cluster-/applicatieplatformbeheerder
Release Manager / Build Engineer
Automatisering en provisioning van IT-infrastructuren
I
I
R/A
C
Installeren en beheren van het OpenShift-platform
C
I
R/A
C
Ontwerpen en beheren van deployment pipelines
C
C
I
R/A
Beheer van tenant-provisioning, isolatie en IT-middelen
C
I
R/A
I
Samenstellen en beheren van basisonderdelen
R
C
R/A
C
Ontwikkelen van applicaties en testen
C
R/A
I
I
Operationele monitoring en beheer van applicaties
R/A
C
C
I
Gebruikersacceptatietesten
C
R
I
I
Symbolen in de RACI-matrix
Bron:
- Responsible ā Uitvoerder ā de persoon die alles doet wat nodig is om de taak uit te voeren.
- Accountable ā Verantwoordelijke ā de medewerker die uiteindelijk verantwoordelijk is voor de correcte en zorgvuldige uitvoering van de taak of het behalen van het resultaat; ook de enige die het werk aan uitvoerders kan delegeren.
- Consulted ā Consultants ā doorgaans experts op hun vakgebied wiens advies wordt ingeroepen; er is sprake van tweerichtingscommunicatie.
- Informed ā Informatieontvangers ā mensen die op de hoogte worden gehouden (vaak pas aan het einde van de taak of na het behalen van het resultaat); zij ontvangen informatie eenzijdig.
Hoe teams samenwerken in een DevOps-organisatie
Het traditionele model voor het verkrijgen van middelen bestaat meestal uit een cyclus van verzoeken om middelen, die dan door verschillende teams worden uitgevoerd. Uiteindelijk worden alle benodigde middelen toegewezen en bevestigd door de aanvragende partij. Vaak worden deze processen gedeeltelijk of zelfs volledig handmatig uitgevoerd en vereisen ze frequente en talrijke interacties tussen teams voor een succesvolle verwerking van elke aanvraag.
Figuur 1. Traditionele IT-organisatie
Het bovenstaande diagram illustreert de typische relaties tussen teams in een traditionele IT-organisatie. Binnen dit schema vragen sommige teams andere teams om de uitvoering van vereiste taken, gebruikmakend van meer of minder geformaliseerde communicatie middelen, zoals ticket systemen of e-mail. Vervolgens komen deze verzoeken in de wachtlijst en wachten op hun beurt, waarbij lange wachttijden vaak leiden tot verslechtering, of zelfs verergering van de relaties tussen teams. De spanning wordt verder verergerd doordat leden van verschillende teams elkaar zelden persoonlijk ontmoeten en doorgaans slechts de minimaal noodzakelijke informatie delen.
Figuur 2. IT-organisatie DevOps
In dit diagram wordt getoond hoe de samenwerking binnen een DevOps-organisatie is ingericht. Hier hebben dezelfde teams als in het vorige diagram afscheid genomen van ondoeltreffende communicatie, die de fragmentatie versterkte, en hebben deze vervangen door persoonlijke contacten, waardoor permanente communicatiekanalen tussen de teams zijn ontstaan. Deze kanalen bevorderen de ontwikkeling van een hybride vaardighedenmix, die medewerkers helpt om de behoeften, problemen en mogelijkheden van de teams die zij vertegenwoordigen beter te begrijpen en te verbeelden. Teams bieden elkaar de mogelijkheid om nodige werkzaamheden uit te voeren via geautomatiseerde selfserviceportalen in plaats van handmatig voldoen aan elkaars wijzigingsverzoeken, zoals voorheen het geval was. En dankzij de aanwezigheid van communicatiekanalen kunnen deze selfservice-systemen zich snel aanpassen aan de behoeften van de teams waarvoor ze zijn gemaakt. Voor nog meer wederzijds begrip en kennisuitwisseling binnen de organisatie, draaien teamleden periodiek van rol om ervaring op te doen in interactie met verschillende teams en om een beter overzicht te krijgen van de IT-systemen die zij ondersteunen, waardoor hun cross-functionele vaardigheden en nuttigheid toenemen.
Samenvattend
In deze post hebben we besproken hoe de implementatie van PaaS-oplossingen organisaties kan aanzetten tot het aannemen van de DevOps-methodologie, waarbij traditionele rollen en taken binnen dit proces worden veranderd. Daarom hebben we de belangrijkste IT-taken opgesomd die ontstaan in een organisatie bij de overstap naar OpenShift, evenals de vaardigheden die nodig zijn voor het uitvoeren ervan. We hebben ook de belangrijkste set organisatorische rollen gepresenteerd die ontstaan bij het opbouwen van cross-functionele DevOps-teams, en de RACI-matrix die de nieuwe rollen verbindt met nieuwe taken. Tot slot hebben we besproken hoe het OpenShift-platform en de bijbehorende DevOps-methodologie de organisatiestructuur van een organisatie kunnen veranderen bij de overgang van traditionele hiƫrarchieƫn en systemen voor het verwerken van aanvragen naar cross-functionele teams met een hoger niveau van persoonlijke communicatie.
Bron: habr.com
