Waar zijn de IT Operations (Ops) in DevOps?

IT Operations zijn de Ops in DevOps, maar waar zijn ze ingebed binnen de organisatie? En hoe ziet de toekomst van IT operations er uit?

Kleine bedrijven, start-ups of software ontwikkelaars beweren vaak dat ze werken volgens het DevOps-model.

Wat ze eigenlijk bedoelen is: “We hebben vrijwel geen IT Operations capaciteit en we vertrouwen op de ontwikkelaars om alle omgevingen, van ontwikkeling tot test en productie, te bouwen, te implementeren en te beheren. Meestal met de hand.”

DevOps is niet hetzelfde als ‘ontwikkelaars die productie beheren’

IT Operations is een discipline, met zijn eigen patronen en werkwijzen, methodologieën, modellen, tools, technologie, enz. Cloudhosting maakt het gemakkelijker om servers te implementeren, maar betekent niet dat je weet hoe je zo’n omgeving moet beheren.

DevOps betekent dat Development en IT Operations samenwerken om de Operations-vereisten inzake stabiliteit, betrouwbaarheid en prestaties in te passen in de ontwikkelingspraktijken en tegelijkertijd Development in het beheer van de productieomgeving te brengen. 

Het betekent niet dat we terug moeten gaan naar het laissez-faire ‘anything goes’-model, waar ontwikkelaars onbeperkte toegang hebben tot de productieomgeving en 24x7x365 instellingen kunnen veranderen wanneer ze willen.

Gestructureerde aanpak

Denk na over wat je wilt veranderen, automatiseer het, test het en denk na wat je moet doen als het mis gaat. Documenteer de wijzigingen, zorg ervoor dat iedereen weet wanneer, waar en hoe je de wijziging doorvoert en zorg ervoor dat de opdrachtgever dit goedkeurt.

Devalueer het DevOps-concept niet door te zeggen dat je DevOps doet als je dat niet doet maar verdeel de taken en werk goed samen. Als je Development en IT Operations apart goed doet probeer dan een betere, meer flexibele, meer cloudgeoriënteerde manier van samenwerken te bewerkstelligen. Dat is een manier die het beste uit beide disciplines haalt.

Hoe ziet de toekomst van IT operations eruit in een DevOps-wereld?

Steeds meer bedrijven zijn afhankelijk van virtualisatie, containers, cloud computing, Infrastructure as a Service en Microservices. In die omgeving is er nog steeds ruimte voor IT Operations. Deze DevOps teams zullen veranderen en waarde te blijven leveren bij het ondersteunen van Agile IT Operations.

De rol van IT Operations (Ops) wordt meer applicatiegericht met inzicht in de applicaties die op de platformen draaien die ze bieden. Het ​​smalle beeld dat zegt: “Mijn servers zijn in orde, het is niet mijn schuld dat de applicatie niet werkt.”, zal verdwijnen. Het is misschien niet jouw schuld, maar je deelt de verantwoordelijkheid voor de beschikbaarheid van de applicatie voor de gebruikers.

De veranderingen zijn evident

• Operationele mensen moeten bijna zeker leren te coderen, omdat we op weg zijn naar een code-gestuurde, API-enabled wereld. Als je niet kunt coderen loop je het risico om buiten de boot te vallen.
• De IT Operations Engineer / Ontwikkelaar van de toekomst zal digitale toeleveringsketens en digitale productielijnen bouwen vergelijkbaar met een proces engineer in een chemische fabriek.
• Deze digitale toeleveringsketens zullen grondstoffen (broncode) transformeren via continue integratie, testautomatisering, verpakking, release-automatisering, infrastructuur-als-code in applicaties die worden uitgevoerd in door de cloud gehoste omgevingen.
• Het aantal wijzigingen dat langs de digitale toeleveringsketen stroomt, zal ver uitstijgen boven het oude Change Management proces. Je kan geen wekelijkse CAB-vergadering (Change Advisory Board) houden als je meerdere implementaties per dag uitvoert.

DevOps IT operations vereisten

Een van de belangrijkste principes in DevOps is om IT Operations te betrekken bij de volledige levenscyclus van software-ontwikkeling en, in het bijzonder, om ervoor te zorgen dat operationele vereisten worden opgenomen in de ontwerp- en bouwfasen. De DevOps operationele vereisten:

1. Documentatie

Samenwerken aan de productgerichte documentatie op een standaard platform. Deze documentatie is het minimum:

• Een diagram op hoog niveau van het systeem.
• Details over iedere afhankelijkheid.
• Een uitwerking van iedere foutmelding.
• Details over elke configuratieoptie / schakelaar / vlag / sleutel.
• Aannames, standaardwaarden.

2. Regressietest-scripts

Een degelijke set regressietest-scripts kan aanvraag worden uitgevoerd om te controleren / verifiëren / valideren dat alles correct wordt uitgevoerd.

Geautomatiseerd testen is essentieel voor een automatiseringsstrategie. Je moet kunnen verifiëren of een toepassing correct is geïmplementeerd.

De ideale testsuite test alle belangrijke onderdelen van de applicatie uit en biedt nuttige diagnoses als iets niet correct werkt. Dit is te combineren met synthetische monitoring, Application Performance Management (APM) tools en infrastructuurbewaking. Het doel is om ervoor te zorgen dat we weten of er iets mis is voor de gebruiker.

3. Horizontale schaalbaarheid (voor alle niveaus)

Iedereen wil dat de applicatie een succes wordt, maar niemand wil geld verspillen door vooraf infrastructuur in te kopen. Afhankelijk van het gebruik willen je hoger of lager kunnen schalen.

Daarvoor moet de applicatie horizontale schaalbaarheid ondersteunen. Bij het ontwerp van de applicatie moet hier over worden nagedacht. Er zijn drie goede tips:

• Gebruikers / sessiestatussen niet aan een bepaalde web- / applicatieserver vastpinnen (gebruik een mechanisme voor gedeelde sessiestatus).
• Ondersteuning bieden voor alleen-lezen replica’s van de database.
• Ondersteuning bieden voor multi-master of peer-to-peer replicatie (om een ​​knelpunt op een enkele ‘master’-server te vermijden als de applicatie waarschijnlijk een serverspecificatie overschrijdt).

4. Vlaggen

Vlaggen geven je veel controle over hoe de applicatie werkt. Die kan je gebruiken om gemakkelijk iets terug te halen dat niet werkt zonder de volledige programmacode terug te draaien en de prestaties en schaalbaarheid te managen.

5. Configureerbaarheid

Vermijd waar mogelijk om waarden in de programmacode op te nemen, ze moeten in externe configuratiebestanden staan. Dit is vooral belangrijk omdat je de applicatie kan  verplaatsen tussen omgevingen (Dev, Test, Staging, enz.) en de applicatie voor iedere omgeving moet configureren.

Een overdreven configureerbaar systeem kan ook een nachtmerrie creëren, omdat het opsporen van welke van deze instellingen verkeerd is geconfigureerd uiterst moeizaam kan zijn.

6. Compatibiliteit met vorige versies

Bestaande programmacode met nieuw databaseschema of opgeslagen procedure? Nieuwe programmacode met bestaand databaseschema of opgeslagen procedures?

Vooruit of achteruit, het zou prima moeten werken, want als dat niet het geval is, introduceer je ‘kip en het ei’ afhankelijkheden. Wat dit betekent voor IT Operations is dat een deel van het systeem offline genomen moet kunnen worden om het andere deel te upgraden. Dat kan veel impact hebben op de gebruikers en kost waarschijnlijk heel wat papierwerk om het allemaal goedgekeurd te krijgen.

7. Houdt rekening met afhankelijkheden

Ga er niet vanuit dat de afhankelijkheden altijd beschikbaar zijn. Vooral als het gaat om netwerkbronnen zoals databases of webservices. In een Cloud-omgeving, zoals van Amazon, kunnen complete servers in een oogwenk verdwijnen.

Zorg ervoor dat het systeem goed reageert op het wegvallen van afhankelijkheden. Registreer de fout en reageer elegant als de situatie zich voordoet.

Moderne web-apps zijn afhankelijk van webservices. Houd de afhankelijkheden in de gaten en zorg ervoor dat ze duidelijk gedocumenteerd zijn.

8. Metrics

Door applicaties te structureren met statistieken en prestatie metrics, krijgt Operations de mogelijkheid om te weten wat er gebeurt met een applicatie. Standaardtellers bevatten zaken zoals transacties per seconde (nuttig voor capaciteit) en transactietijd (handig voor prestaties).

Discussieer mee op LinkedIn.