Naarmate er nieuwe technologische mogelijkheden ontstaan, blijven de verwachtingen van klanten stijgen. Tegenwoordig eisen organisaties dat producten en applicatiefuncties worden geleverd en geïmplementeerd waar en wanneer dat nodig is. De uitvoering loopt echter het risico achterop te raken door ontwerp en zakelijke vereisten. Tenzij devops een strategische en filosofische invloed begint uit te oefenen.
Devops (het samenbrengen van software-ontwikkeling – dev – en software-operaties – ops) is nu natuurlijk al geruime tijd een van de populairste trends in het it-bedrijfsleven. Het is een cruciaal concept om bedrijven te helpen aan de eisen van klanten te voldoen door teams bij elkaar te brengen voor een betere samenwerking en innovatie. Volgens Deloitte zien organisaties die devops adopteren hun time-to-market dalen met 18 tot 21 procent.
Door de ballast die de ontwikkeling van software belemmert te verwijderen, worden de activiteiten gestroomlijnd en kunnen bedrijven sneller reageren op eisen van de markt. Tegelijkertijd stelt automatisering bedrijven in staat om bedrijfsdoelstellingen en processen op elkaar af te stemmen en zo sneller te herstellen van it-uitval. Deloitte meldt ook dat de snelle, door devops beïnvloede, klantvriendelijke release van nieuwe producten en diensten leidde tot een omzetstijging van 20 procent.
Allemaal goed en wel, de voordelen kennen we, maar devops is nog steeds een relatief nieuw onderwerp. Grootschalige acceptatie is over het algemeen traag. Het is belangrijk om op te merken dat devops meer is dan alleen de implementatie van nieuwe tools. Het draait allemaal om de verandering van diepgewortelde culturele gewoonten, de transformatie van bestaande processen en ervoor zorgen dat alle wijzigingen om de juiste redenen worden aangebracht. Omarm devops niet slechts omdat het een trend is. Doe het alleen als er duidelijkheid en een doel is.
Doorbreken van culturele gewoonten
Devops is geen team. Het is een cultuur van samenwerking, die een reeks best practices en operationele culturen oplevert. Soms worden bedrijven die een devops-aanpak willen hanteren, geconfronteerd met weerstand van werknemers die zich niet op hun gemak voelen bij verandering. Leiderschap moet van de top komen. Leidinggevenden moeten werknemers ondersteunen bij het beëindigen van de status quo en het afbreken van silo’s die een succesvolle implementatie belemmeren.
De motivatie voor devops stijgt wanneer de resultaten positief, concreet en waarneembaar zijn. Er is geen magische formule, maar met het juiste leiderschap en de juiste cultuur is de kans groot dat devops slaagt. Gartner schrijft dat 88 procent van de bedrijven van mening is dat de teamcultuur de grootste impact heeft op het vermogen van een organisatie om devops te laten slagen.
Veranderen nait efficiëntere processen
De beste manier om inefficiënties te identificeren, is door processen in kaart te brengen en te herkennen wat wel en niet werkt. Begin met het zoeken naar verspilling – gebieden waar middelen worden uitgeput zonder echte waarde te leveren. Een door silo’s beïnvloed gebrek aan communicatie kan bedrijven aanzienlijk vertragen en het risico bestaat dat elke afdeling denkt dat devops niet hun verantwoordelijkheid is. Sommige medewerkers kunnen huiverig zijn tegen het doorvoeren van veranderingen, wat onnodige vertragingen binnen het bedrijf zal veroorzaken.
Het is van vitaal belang om te begrijpen dat het niet alleen de verantwoordelijkheid van softwareontwikkelaars is om ervoor te zorgen dat de processen voor hen werken. Devops is een proces dat ontwikkelteams en andere it-stakeholders samenbrengt om één gemeenschappelijk doel te bereiken: sneller, kwalitatief beter werk leveren aan de markt.
Pas op
Met devops kunnen bedrijven elke taak stroomlijnen en automatiseren. Dat betekent echter niet dat devops geschikt is voor élk onderdeel van élk bedrijf.
Vaak kiezen bedrijven een aantal afdelingen om een devops-aanpak te testen met – meestal – het ontwikkelteam. De verleiding is dan om door te schalen in de hele organisatie zodra er positieve resultaten zichtbaar zijn. Het probleem daarmee is dat verschillende afdelingen allemaal verschillende behoeften en uitdagingen hebben en, zoals gezegd, een effectieve uitrol van devops vereist een verandering van processen en werkwijzen.
Organisaties moeten oppassen dat ze eerst nadenken over de specifieke zakelijke behoeften en niet slechts blindelings trends volgen. Vraag je dus af wat de doelstellingen zijn, voordat er ingrijpende reorganisaties doorgevoerd worden. Blijf leren en blijf vooral afstemmen op de behoeften van de klant.
Al lezende vroeg ik me af, wat is nu devops?
DevOps is het snijpunt in een aantal disciplines, naast genoemde development & operations is quality assurance het derde aandachtsgebied dat ingevuld wordt met nieuwe paradigma. Noodzaak van DevOps wordt daarmee duidelijker als het gaat om een snellere time-to-market met behoud van kwaliteit. Want de overtreffende trap van goed was niet beter maar goedkoper, de synergie van meerdere disciplines in één team laat zich dan ook raden.
Eerst had je geen ITIL, de beheerders werkten samen met de developers, zonder strikte procedures en beiden kenden elkaars vakgebied. Soort T-profielen met DevOps.
Dat was helemaal fout. daarom kreeg je ITIL, KPIs, outsourcing enzo.
Dat was ook fout, daarom weer DevOps.
Best practices is namelijk eigenlijk altijd op basis van ervaring en gezond verstand van verschillende disciplines professioneel maar wat aanklooien wat je het beste lijkt.
Business wil altijd goed, snel en goedkoop en afhankelijk van de periode geeft men dat verschillende namen.
Louis, in mijn ogen hanteren wij intern een DevOps strategie. Hier zijn de concrete dingen zoals wij het doen.
Wij hebben een generiek platform gemaakt waarop leer-content / interactieve video / serious games / on-boarding tools landen en voor verschillende toepassingen als dienst aangeboden worden aan klanten.
Iedere DEVeloper heeft een eigen omgeving waarin de software staat en waarin aanpassingen van de code gedaan worden. Aan welke onderdelen gewerkt wordt staat in de sprint. Dat zijn zeg maar alle opgedeelde taken die als ze zijn afgerond een stukje functionaliteit opleveren. Als zo’n taakje af is wordt deze op resolved gezet en als ik er klaar voor ben om te testen (naast alle geautomatiseerde testen) wordt de nieuwe code samengevoegd (GIT) en via de tool (Jenkins/Saltstack) gebouwd en deployed naar de test omgeving. Als het testen geslaagd is wordt de code samengevoegd met de productie “branche” en deployed naar één productie omgeving. Dit gebeurd meestal gewoon onder werktijd omdat er in de basis geen downtime zit in het updaten. Meestal kies ik een omgeving waarin de functie het hardst nodig is zodat de acceptatie testen gedaan kunnen worden. Als deze ook goed verlopen worden alle andere productie omgevingen geautomatiseerd gebracht naar de nieuwste code base.
Dit proces gebeurd meerdere keren per week en soms meerdere keren per dag. De release notes worden bijgewerkt en relevante belanghebbende bij klanten worden ingelicht.
In de basis kunnen ontwikkelaars en beheerders rollbacks uitvoeren. Dus de DEVS doen in feite ook de OPS en samen praten we over hoe het proces nog beter kan, of als er iets mis gaat waarom het is mis gegaan.Uiteraard hebben we monitoring tools die ook met ons meekijken. Bijvoorbeeld als de snelheid ineens verandert of iets een 500 geeft. En het meet uptime en rapporteert hier ook automatisch naar klanten toe.
Nu zijn wij een klein bedrijf en is de complexiteit weliswaar hoog, maar veel lager dan bij grote organisaties die ook te maken hebben met effecten over platformen heen. De kunst is echter om te denken in “microservices” die onafhankelijk van elkaar ge-update kunnen worden.
In feite is dit hoe cloud providers zoals Microsoft / Google en Amazon opereren. Iedere service van deze platformen wordt wekelijks aangepast met een nek-brekend tempo. Het voordeel is dat je sneller klanten helpt met hun uitdagingen en daarom relevant blijft. Dit was de reden waarom Amazon enorm uitliep op de rest omdat ze dit principe tot kunst verheven hadden. Het is een manier om concurrentie voor te blijven.
Maar er zitten ook nadelen aan. Het is voor gebruikers heel vervelend als dingen verdwijnen, verplaatsen, anders werken, etc. Of dat iets wat hij fantastisch vind en tijd in steekt ineens verdwijnt omdat het niet in het grotere plaatje past. Ook als de stront de ventilator raakt kan DevOps heel intimiderend zijn. Als dingen misgaan gaan ze soms ook episch mis.
Voor ons was het relatief simpel te implementeren omdat we niets anders hadden. Het is gewoon een dingetje wat werkt en wat overigens ook goed schaalbaar te maken is. Onze “Operations” of beheer kosten zijn laag omdat het allemaal zo geautomatiseerd is.Maar je hebt wel weer kundige mensen nodig om dit zo te doen.
Ik vind het heerlijk werken en soms meldt een gebruiker via de chatbot een bug die voor het einde van de dag opgelost is.
Dus wat is DevOps? Een sterk geautomatiseerde manier van werken waardoor je heel snel nieuwe functionaliteit in handen van gebruikers kan krijgen.
@Henri:
Je spreekt ook over de inzet van monitoring tools; naar ik aanneem zoiets als JMeter met Selenium?
Nog anderen? Bijvoorbeeld rondom security?
Op een paar plekken noem je productnamen; bijvoorbeeld GIT en Jenkins.
Voor zover ik weet zijn dit allemaal tools die initieel een behoorlijke inspanning vragen om e.e.a. ingeregeld te krijgen. Is dat bij jullie ook het geval geweest?
Kan/wil je iets zeggen wat je ongeveer aan uren kwijt bent geweest? En met welk resultaat?
Hi Will,
We gebruiken o.a. PRTG, AWS Cloudtrail, Jira, etc.
Hoeveel uur het kost is wat lastiger na te gaan. Eerst is er discussie en research en als we een selectie hebben gemaakt dan proberen we het uit en van daaruit itereren we, of nemen we afscheid. Door de tijd heen gaan daar inderdaad uren in zitten, maar vaak weet je vooraf nog niet wat je wilt.
Al met al gebruiken we tientallen services en frameworks en soms bouwen we ze zelf. Ook bouwen we technische schuld op en soms nemen we dan ook echt afscheid van tools. Maar in de regel leveren ze tijd op. Ik heb een voorkeur om eerder uren te verspijkeren aan iets, dan dat we betalen voor een dienst. Juist omdat vaste lasten ten koste gaan van de marge op onze dienst zelf.
Onze stack ziet er ongeveer zo uit: Linux, Postgres, Python / Django, GraphQL, React.
Als je meer wilt weten moet je maar een mailtje sturen.
“Ik heb een voorkeur om eerder uren te verspijkeren aan iets, dan dat we betalen voor een dienst. Juist omdat vaste lasten ten koste gaan van de marge op onze dienst zelf.”
Zo zie je maar Louis, uiteindelijk is het net als vroeger gewoon alles uitzoeken en doorbuffelen.
Git is een repository tool, als vroeger sccs, cvs en svn. Professionele developers werken daar al 30 jaar mee.
Automatiseer je iets meer testen zodat je eenvoudiger vaker kan releasen dan heet het ineens DevOps.
Uiteraard noemen gaan we niet op de vraag wat we automatiseren. De OPS mbv ansible, saltstack, puppet, AWS cloudformation of DEV mbv Jenkins. DevOps is ICT en de ICT bestaat niet.
Van waterval naar kabbelend beekje van hele kleine watervalletjes en ineens heet het agile ?
Is modulair werken en testen niet genoeg of moet het perse microservices ? Wie zegt dat alles schaalbaar moet ?
We doen het omdat anderen het ook doen en omdat we elkaar wijs maken dat het moet.
Ik ga nou ff wat weer een facebook iteratie doen. Ff wat waarde toevoegen op facebook en vanwege de fear of missing out en omdat ik anders weer in een verjaardagscrum kan uitleggen waarom ik iets niet geliket heb. Moet ook..
DevOps is oude wijn in nieuwe zakken. Komt idd op neer dat je een stel mensen hun gezond verstand laat gebruiken zonder als ‘spreadsheet manager’ je er teveel mee bemoeien. Als alle neuzen dezelfde kant op staan en er niet teveel druk op de ketel staat kun je hele mooie resultaten behalen.
Let wel dat dit in een westerse cultuur anders werkt dan in bijv. een Aziatische.
Had natuurlijk kunnen googelen, wat is dat nou dat devops. Had wel gehoord van belg die hier wat achterzat en in oorsprong vond ik er wel iets in zitten. Was herkenbaar, een grote organisatie met al zijn afdelingen. en zijn procedures (tickets!). Wat technisch gerelateerd aan je werk is lastig te bereiken en nodige samenwerking daardoor moeizaam. Dat kan makkelijker. Daar dacht ik altijd aan bij devops. Al zou je maar gewoon de telefoon op kunnen pakken of op elkaar kunnen afstappen. Meer niet. Inmiddels heeft devops een hele eigen dynamiek gekregen. Voor ieder wat wils.
@Ewout Dat multidisciplinaire team dat is ook een strekking van devops, net zoals in dat artikel. Alles en iedereen die ermee te maken bij elkaar. Wie is de baas? Vooral, sneller en beter en u vraagt wij draaien. Dat is opjaag ict.
@Henri Hele mooie reactie en leuk om te lezen wat jullie doen en wat er gebruikt wordt. De stack, leuk. Een aspect van de devops is het automatiseren van het testen, integreren en uitrollen. Dat klinkt natuurlijk niet gek. En heel vaak, dat hoort er ook bij. Daar twijfel ik wel eens, ook vanwege de onrust voor de gebruiker. Bugs dat moet maar nieuwe functionaliteit lijkt me linker. Schreef jij ook al. Vind dat wel iets onrustigs hebben, dat steeds maar moeten releasse of met nieuwe release te maken te hebben.
@Dino Er verandert ook niet zo heel veel in computerland, toen ik ik het verhaal van Henri las, dacht klinkt wat ouderwets, maar dan in de goede zin. Maar vooral dat snel en beter, met zijn allen in de softwarefabriek net zoals toyota, zoals in het artikel. Dat is ook een kant. In adem te noemen met multidisciplair, zelfsturend, lean scrummen in sprintjes. Continu verbeteren. Dat werk. Brrr.
https://devops.com/the-origins-of-devops-whats-in-a-name/