Nyligen, med ökande automatisering och självständighet av databaser, servrar, nätverk, och allt annat, det har varit tal om en ny form av leverans av programvara: “NoOps.” Det är nya koden är kanalens — från utvecklarnas frontal-loben-för-front-office-snabbt och automatiskt, med minimalt behov av mänsklig inblandning.
Foto: Joe McKendrick
Folket på TechTarget ge en definition av NoOps som “begreppet som en IT-miljö kan bli så automatiserat och som tas ut från den underliggande infrastrukturen som att det inte finns behov för en särskild grupp för att hantera programvara i egen regi.”
Jag frågade Greg Nist, chef för utbildning på MarkLogic, för att förklara fördelarna av en NoOps strategi. Han pekar på NoOps som nästa steg i utvecklingen av den modell för utveckling från DevOps. “Företag som har infört DevOps modell har sett stora fördelar jämfört med skarpt avgränsade, vattenfallsmodellen”, påpekar han. “DevOps förenar rollen som utvecklare och operatör för att öka ansvarstagandet och hastighet tid för utbyggnad av innovativa produkter, som ger verkligt mervärde till företaget och kunden.”
Allt bra, naturligtvis. Men då Nist finns nästa fas: “tänk om du kunde övergången från något bra till något ännu större-något som ytterligare kunde den tid som ägnas åt utveckling?” frågar han. “Det är där NoOps kommer in. Genom att utnyttja molntjänster, organisationer kan krympa ytterligare administration, konfigurering och installation av arbete i syfte att maximera tiden.”
Vad sägs om att organisationer med svag eller obefintlig DevOps initiativ-kan de ta steget till en NoOps modell? Eftersom det är också troligt att DevOps eftersläntrarna är också fortfarande fast i lokaler äldre infrastrukturer, en flytt till molnet kan hjälpa till att bereda vägen, Nist staterna.
Fortfarande, andra till försiktighet med NoOps-det är inte ett universalmedel, och det är alldeles för tidigt att tänka på att lämna över implementering nycklar till robotar. “Du kommer åtminstone behöva DET ops personal för att övervaka resultaten och hantera undantag villkor”, konstaterar Jim Kobielus, analytiker med Wikibon nyligen i en tweet. “Automatiska system kan inte helt lita på att deras egen vård och utfodring.”
Medan vi har kommit en lång väg med verktyg, “tanken att du kan ta bort folk från denna ekvation helt är ganska absurt, åtminstone under de närmaste fem åren, säger David Linthicum i en InfoWorld kolumn. Han konstaterar äldre system gör NoOps en nonstarter för många organisationer, men, vad viktigare är, att den undergräver människor fokuserad förutsättningen för DevOps. “DevOps är inte bara om automatisering av ops, det handlar om människor som arbetar tillsammans för att kontinuerligt förbättra program och åtgärder för utveckling”, säger han.
Fortfarande på väg mot NoOps erbjuder en produktiviteten öka som kan stärka innovationsprocessen, Nist säger. “Jag tror att det är mest användbara för att jämföra NoOps med den typiska DevOps arbetsflöde, vilket är egentligen bara iterera mellan att bygga, testa och släppa. Bygga-och-test bitar är det som ger mervärde till verksamheten, och DevOps-modellen gör ett bra jobb med att krympa vad som inte ger värde: släpp fasen”, förklarar han. “Men, samtidigt släppa fönstret med DevOps är mindre, det är fortfarande det. Och DevOps har skapat denna typ av gråzon där utvecklare och driftpersonal överlappning vid release steg.”
Det grå området överlappar varandra kan skapa problem i produktionen som kommer att skapa flaskhalsar. “Låt oss säga, som utvecklare, utbyggnaden av din kluster var inte gjort för dig, och att du gör saker i en manuell eller ens ett manus sätt”, Nist fortsätter. “Om du inte få det helt rätt, och du går för att validera din miljö när din release är gjort, kommer du att vara fast i en cirkel av felsökning och försöka lista ut var det gick fel. Det kommer att sakta ner dig, och det kan vara på grund av ett rent misstag-som du glömde att klicka på ett av alternativen för en hög tillgänglighet som du behövs, och allt går sönder.”
Den NoOps modellen, å andra sidan, “höjer graden av abstraktion kring genomförandet av utsläpp, vilket gör det möjligt för utvecklare att spendera mer tid på att bygga och testa. I själva verket, med managed cloud-tjänster, är det möjligt med bara ett par klick för att konfigurera hela din miljö, med alla verktyg och regelverk som krävs för att driva ett projekt. På 15 minuter kan du få en fullt fungerande, high-availability-kluster med alla de program och komponenter som du behöver.”
Hur kommer roller i verksamheten människor förändras om företaget flyttar till NoOps? I det scenario som beskrivs ovan, “behovet av insatser så långt som konfiguration och driftsättning roller berörs är betydligt färre, så mycket så att utvecklare kan göra den till en del av sitt arbetsflöde,” Nist säger. “Och om du tillåter det faktiska administration och övervakning av server, via managed cloud services, det skulle föreslå att ingen verksamhet lag.”
Detta kan innebära fler möjligheter för verksamheten människor att höja sina roller i sina organisationer, “en omarbetning av högutbildade verksamheten proffs i roller där de kan ägna sin kompetens till mer av förädlingsvärde,” Nist säger. Du kan övergången sin energi från något som en gång var helt enkelt en nödvändighet för att något som verkligen tillför värde till kunden. Som ett exempel, tänk på all tid som går till Kubernetes, som har en massiv konfiguration efterfrågan. Ta bort det från axlarna av driftpersonal, och de har tid och resurser för mer kritiska uppgifter som kontinuerliga utbyggnaden, granulat användningsspårning, bättre tester och mer.”
Utvecklare kan dra nytta samt, naturligtvis. “NoOps frigör bit av tid och energi som de för närvarande ägnar åt att det sista objektet i sin pipeline — release,” Nist säger. “Du är bokstavligen ta uppgifter av utvecklare plattor, vilket bara kan betyda att de får göra vad de behöver och vill göra: utveckla nya coola produkter och tjänster.”
Relaterade Ämnen:
Datacenter
CXO
Trodde Ledarskap
Innovation
Tech och Arbete