Met de opkomst van DevOps, lijkt er sprake te zijn van een nieuwe stroming binnen de wereld van het ontwikkelen en het beheer van applicaties. Waar de behoefte om effectief en efficiënt te werken hoger is dan ooit tevoren, stelt DevOps organisaties in staat om zich snel en op een hoog niveau aan te passen aan de veranderde markt. Want in de huidige wereld, waarin de behoefte om Agile te werken hoogtij viert, zal DevOps de kers op de taart zijn.
De term DevOps bestaat uit de termen development en operations. DevOps-teams zijn zelf verantwoordelijk voor de ontwikkeling van applicaties of systemen en operationele gedeelte ervan. Waar dit voorheen geïsoleerde teams waren, zijn deze teams nu samengekomen en werken zij gezamenlijk richting een gemeenschappelijk doel. Hierdoor zijn deze teams van A tot Z verantwoordelijk voor het functioneren en bijwerken van deze applicaties. Omdat de focus op een applicatie het team een gemeenschappelijk doel geeft, krijgt het team een gevoel van eigenaarschap op het product.
DevOps en Agile werken
Waar DevOps een term is die pas sinds kort veel gebruikt wordt in het Agile werken, zijn organisaties al langer bezig om de principes van Agile werken toe te passen. Agile heeft als doel om wendbaar te zijn en hiermee zo snel mogelijk software of producten op te kunnen leveren. Organisaties proberen een korte time-to-market te creëren. Naast een verandering van de cultuur van de organisatie moeten bedrijven, om een korte time-to-market te creëren, ook een infrastructuur hebben die het opleveren van deze producten of software faciliteert. DevOps is een manier om de time-to-market van een organisatie te versnellen en daarmee ook het Agile-proces te verbeteren. Waar Agile zorgt voor een proces waarbij waarde gedefinieerd en gecreëerd wordt, zorgt DevOps ervoor dat de organisatie in staat is om deze waarde te verzilveren.
Evenals Agile werken, is het bij DevOps belangrijk dat de principes die DevOps nastreeft binnen de cultuur van de organisatie wordt opgenomen. Om deze principes door alle lagen van de organisatie door te laten werken, is het belangrijk dat er sprake is van vertical commitment. Om de kleine veranderingen, die bij DevOps horen door te kunnen voeren, is het noodzakelijk dat je meerdere keren per dag een software release doet. Dit kan alleen als beslissingen vanuit alle lagen van de onderneming genomen kunnen worden.
Meerwaarde van DevOps
DevOps gaat over het onderhoud van applicaties en deze zo snel mogelijk naar de markt brengen. Dit houdt in dat wanneer je een wijziging of een fout in je software tegenkomt, je deze ’s ochtends kan ontdekken en deze voor het begin van de middag in je systeem verwerkt kan hebben. Om dit te kunnen doen, creëren DevOps-teams een proces dat het mogelijk maakt om geheel geautomatiseerd deze wijzigingen over een aantal testen heen te krijgen, zodat deze in productie komen te staan. Dit wordt ook wel continuous integration genoemd. Dit houdt in dat wanneer codes worden in gecheckt bij een ‘centrale opslagplaats’, deze software wordt samengepakt tot een pakketje dat daadwerkelijk wijzigingen in de applicatie of het systeem teweeg kunnen brengen. Deze pakketjes worden dan tegen een aantal tests onderworpen en hieruit bepaalt men of het pakketje verder het proces in gaat.
Waar ontwikkelaars momenteel veel tijd stoppen in het ontwikkelen van nieuwe functionaliteiten, vergeten zij vervolgens vaak testen te maken om deze nieuwe functionaliteiten te controleren op fouten. Bij het opzetten van een DevOps-systeem, zullen minder vaak nieuwe functionaliteiten gelanceerd worden, Dit komt doordat de ontwikkelaars meer tijd zullen steken in het opzetten van het systeem en de bijbehorende tests, dan in het ontwikkelen van nieuwe functionaliteiten. Na de opzet, zal de kwaliteit van nieuwe functionaliteiten veel hoger komen te liggen en kunnen deze sneller worden doorgevoerd. Hierdoor zijn wij in staat om binnen een uur een probleem te signaleren, het probleem op te lossen, de oplossing te testen en deze in het systeem te plaatsen.
Toekomst van DevOps
Waar DevOps het dus voor organisaties makkelijker maakt om veranderingen binnen haar applicaties en systemen door te voeren, is hiervoor echter ook een ander soort ontwikkelaar nodig. Waar ontwikkelaars voorheen voornamelijk gewend waren om met codes te werken, komt er bij een ‘DevOps-ontwikkelaar’ veel meer kijken. Daarom is het noodzakelijk dat organisaties investeren in de kennis en middelen om DevOps mogelijk te maken. Een van de grootste misvattingen bij DevOps is dat men het DevOps wil noemen, maar niet de investering in kennis en middelen willen doen om de stap te maken.
Door middel van deze investering in het eigen personeel, bereiden organisaties zich voor op de toekomst. Tegenwoordig worden vele markten overgenomen door diensten en producten die de markt vanuit een andere invalshoek benaderen. Met behulp van DevOps stellen bedrijven zichzelf in staat, om snel aanpassingen door te kunnen voeren. Want in een wereld waarin technologische ontwikkelingen elkaar in zo’n rap tempo opvolgen, zijn de bedrijven die zich het beste aanpassen de bedrijven die overleven.
Danny Higler, Agile-trainer en -coach bij Wemanity
Wat wordt binnen deze context verstaan onder een “release”?
Het maakt volgens mij namelijk nogal wat verschil in wat voor domein je werkt in hoeverre je devops toe kunt passen.
– in het webdomein kun je zelf, vaak zonder tussenkomst van derden, rechtstreeks deployen naar de operationele omgeving. Webshops en webservices kunnen daarmee eenvoudig en veelvuldig aangepast worden
– in de wereld van de mobile apps ben je afhankelijk van de app stores waar je eerst een submissie moet doen alvorens je app in de appstore terechtkomt. Door deze afhankelijkheid is meerdere releases per dag niet realistisch (een submissie duurt al snel ½dag)
– ga je nu naar een omgeving waar de software onderdeel uitmaakt van een product, waar een zwaar verificatie- en validatie proces aan gekoppeld is (bijv. de medische industrie) dan zijn wijzigingen in software zeer duur. Het is dan goedkoper een set van wijzigingen in één keer te valideren, dan iedere wijziging afzonderlijk.
Het concept van devops is heel mooi, maar je moet het mijns inziens wel binnen de juiste context toepassen
Ik volg Pa Va Ke hier graag in. Nog steeds kan er zonder toevoeging van …. in dit geval DevOps of agile uitstekend worden ontwikkeld, geprogrammeerd en deployed. Ook de reeds bestaande methoden zijn prima schaalbaar en goed toegerust het werk te aaan te kunnen.
Ik mos hier overigens een zeer strategische discipline, die overigens in veel meer commerciele uitingen ontbreekt maar wel degelijk een noodzzaak heeft in de hele IT keten. Change en Release management. Mocht u zich nu de volgende keer afvragen hoe een debacle weer zo heeft kunnen uitmonden, dan komt dit doordat men vind dat Change en Release management in de keten ….. een achetrhaald idee zou zijn?!?
Het idee achter DevOps is prima – alles voor een snellere en betere samenwerking. Maar het abstractie nivo ligt in dit stuk wel erg hoog.
Hoe zit het bijvoorbeeld met zoiets als de workload van een computing platform waarop die dagelijkse updates moet kunnen landen? Ook een “serverless” omgeving heeft hier mee te maken!
Dit lijkt geen onderdeel van de vergelijking te zijn; laat staan een “integraal” onderdeel van de dagelijkse “continuous integration” testen?!
Idem voor de elementen “netwerk” en “end-user device”; ook die twee lijken me redelijk essentieel in het dagelijks gebruik van een of meer applicaties. Het beheer daarvan valt doorgaans in het mandje van een IT-Ops organisatie. Alleen lijkt ook dat stukje van de organisatie geen onderdeel te zijn van de vergelijking; anders dan dat ze vanuit een stukje “vertical commitment” meerdere keren per dag klaar moeten staan voor “iets” wat ze over de schutting geworpen krijgen.
Mij lijkt het beter om een paar releases per dag/week minder te doen en die capaciteit/tijd gebruiken om te valideren of de applicatie ook onder minder ideale omstandigheden (lees: een typische productie omgeving) goed blijft functioneren! Denk bijvoorbeeld eens aan de invloed van een web application firewall of een IPS. Je hebt tegenwoordig zelfs firewall-software die in dezelfde context en hetzelfde proces draait als de Java of .Net code van een applicatie.
Want zelfs als je als DevOps team je blikveld beperkt tot enkel functionele aspecten van een applicatie zijn er veel meer variabelen die meespelen bij een goede werking dan enkel de code. Als die geen onderdeel zijn van de vergelijking heb je in no-time spaghetti-code door de veelheid aan workarounds. Bijvoorbeeld omdat de verschillende tools op security gebied delen van de nieuwe code kwalificeren als niet-veilig en dus domweg tegenhouden.
Dan kan je nog zo een goed DevOps team zijn met een best-in-class manier van Agile werken – het gaat allemaal niet meer baten… als organisatie ga je vroeg-of-laat kopje-onder. Ofwel door de warboel aan applicatie code waardoor niemand er meer chocola van kan maken. Of door een datalek omdat de veiligheidsmaatregelen naar beneden bijgesteld zijn zodat het DevOps team zijn release schema niet hoeft aan te passen.
Nogmaals – ik kan de samenwerking tussen de verschillende X-Ops teams alleen maar toejuichen. Maar dan wel graag verder kijken dan de code van een web applicatie! Uiteindelijk ga je daar als bedrijf de vruchten van plukken – nu en in de toekomst!
🙂