Applikationsdrift har i mange år været en øvelse baseret på samme formel. Det er en formel, der virker og er så gennemprøvet, at det kan undre, at man overhovedet kan overveje at ændre den.
Alligevel er der en række ting, der taler for, at applikationsdrift som vi kender det står overfor store omvæltninger.
Først og fremmest er der udviklingen. Ny teknologi er kommet til, og det kan efterhånden ikke komme som en overraskelse for mange at fremtiden for de fleste applikationer vil stå på applikationer pakket i containere.
Der er dog også andre ting, der taler for, at et skifte i tilgangen til driften er ved at være over os. Selv om driften af applikationer kører godt, som den gør, er der ét problem som det ikke helt er lykkedes at løse: Siloer – altså adskillelsen mellem udvikling og drift.
Manglende alignment mellem udvikling og drift kan føre til problemer, der, selvom de kan løses, koster tid og ressourcer.
- Udviklingsafdelingen har typisk ikke de samme mål som driftsteamet. Derfor er afdelingerne kun interesseret i deres egen succes
- Manglende kommunikation mellem udvikling og drift kan betyde at udviklerne ikke kender produktionsmiljøet godt nok – og driftsteamet har måske ikke kendskab til udviklernes release-cycle
- Måske er udviklingsmiljøet og driftsmiljøet ikke konfigureret ens
Disse problemer – og flere fra samme skuffe – har alle sammen potentialet til at koste både tid og penge for virksomheden – og dette er måske i virkeligheden den største driver for en anderledes tilgang.
DevOps med containerized applikationsdrift
Hvordan løser vi så det problem? Ja, som det viser sig, har vi allerede løst det. Vi løste det for nogle år siden med containere. Med containere og en god orkestreringsengine, som eksempelvis Kubernetes, er det nemlig muligt at implementere DevOps-tilgangen i sin applikationsdrift.
Hvad er så det? Ja helt ned på sit mest basale niveau er DevOps egentligt blot et tættere samarbejde mellem driftsteamet og udviklingsafdelingen. Det smarte er dog, at grænserne mellem hvad der hører hjemme hvor bliver bedre defineret og arbejdet går så at sige op i en højere enhed.
I containerized applikationsdrift er det driftsteamet, der har ansvaret for infrastrukturen og udviklingsafdelingen, der har ansvaret for applikationen. Så let kan det faktisk siges.
Det medfører til gengæld en række fordele, som gør mange ting lettere for både drifts- og udviklingsafdelingen:
- Stømlinet applikationsdeployment
- Bedre skalering af applikationen
- Nemmere management
- Bedre fælles indsigt i hele stacken
Desuden fungerer det uanset hvor du ønsker at workloads skal eksistere. On-premise, hybrid eller public cloud, med skalering både ind og ud.
I tilfældet Kubernetes er orkestreringsenginen endda gratis og baseret på Open Source kode.
Skridtet videre – Rancher
Men introduktionen af containerized applikationsdrift – eksempelvis med Docker og Kubernetes, opstår der dog et par udfordringer:
- Kubernetes er som sagt Open Source og gratis. Derfor er der ingen support på produktet
- Manglende integration til code commit – eksempelvis GitHub. Uden den integration kan turnaround time fra code commit til færdig container være lang.
- Containere kan være bygget på et andet base OS end det, Kubernetes kører på
Løsningen på de udfordringer findes i form af Ranchers suite af open-source, der erstatter den del af stacken, der ligger oven på infrastrukturen. Eller sagt på en anden måde: Rancher kan bygge container images fra din source code, deploye dem, og manage hele containerens lifecycle.
Vi ved jo godt hvad du tænker nu. Vi der er i IT-branchen har en vane med at anprise produkter, uden tanke på om produktet nu også er det rigtige i netop din situation. Vi vil gerne love at vi nok skal prøve at blive meget bedre til at undgå det.
Men i dette tilfælde, gør vi det nu alligevel. Og til dels fordi de muligheder som Rancher giver i forhold til containerized applikationsdrift med eksempelvis Docker og Kubernetes er så omfattende.
Lad os først fremdrage det vigtigste: Det eneste som Rancher ikke kan varetage for dig, er din fysiske og virtuelle infrastruktur. Den vil dit driftsteam stadig have ansvaret for at overvåge. Resten kan for det første udføres af udviklingsafdelingen, og for det andet vil udviklingsafdelingen kunne udføre alle opgaver via single-pane-of-glass.
Desuden er opgaverne meget nemmere, da Rancher i sit servicekatalog har en lang række prækonfigurerede valgmuligheder, som blot skal klikkes af, når man eksempelvis skal bygge en ny container. (Men bare rolig – der er fuld CLI-support også).
Er Rancher det rette valg for os?
Hos Netic er vi mere end moderat begejstrede for Rancher – det skal ikke være nogen hemmelighed. Omvendt skal vi være de første til at gøre opmærksom på, at containerized applikationsdrift – og DevOps – faktisk er muligt uden Rancher. Det er dog et valg man træffer, der bærer nogle potentielle omkostninger med sig:
- Først og fremmest den manglende support. I en Open Source-verden kan forskellen på et supporteret produkt og et ikke supporteret produkt hurtigt ende med at skulle opgøres i mange kroner.
- Manglende automatiseret pipeline – og dermed længere turnaround fra code commit til færdig container
- Mere omstændelig administration og management
- Potentielle fejlkilder (*)
(*): Et eksempel på en fejlkilde kan være en uoverensstemmelse i de glibc libraries, som man compiler sin kode op imod, som følge af forskelle imellem base OS for containeren, og det OS som Kubernetes kører på. En sådan uoverensstemmelse kan medføre at containeren crasher.
Er teknologien så moden? Det er den nu. Børnesygdommene er luget ud af Rancher og det har været i drift så længe – hos så mange kunder – at den vigtigste kundefeedback er blevet implementeret i løsningen.
Desuden bliver DevOps helt sikkert fremtiden for driften af især komplicerede applikationer. Fordelene er så store, at de på sigt vil overvinde de ændringer, som det vil medføre i IT-organisationer. Derfor er det Netics anbefaling at begynde nu. På den måde kan teknologier og metoder indfases over tid, og når organisationen på sigt har taget ændringerne til sig, kan DevOps rulles ud i større stil.