Nul
Iedereen wil DevOps deze dagen, maar wat is een goed zoemen DevOps omgeving echt uitzien? Wat is de visie na te streven?
Foto: HubSpot
Tot op heden, DevOps heeft zijn opduiken als een mengelmoes van activiteiten en initiatieven van bedrijven, wellicht in de naam van het doen, want het is het ding om te doen. Als een resultaat, bedrijven echt zien niet het volledige potentieel van DevOps. De consistentie in de DevOps benaderingen is een zeldzame ding inderdaad, vertelt Kurt Marko, verwijzend naar een recente enquête van de Computer Economie. Het onderzoek komt tot de conclusie “dat hoewel ongeveer een derde van de organisaties dabble in DevOps, bijna geen doen zo formeel en consequent in de hele organisatie te tonen of om het even welke schijn van het beheersen van DevOps praktijken.”
Dat komt omdat DevOps is meer dan eisen dat iedereen bij elkaar te krijgen en het gooien van een aantal nieuwe instrumenten in de mix. Als Marko zegt: “DevOps is als het op dieet zijn: het vereist veranderingen in waarden, attitudes, processen en gewoonten. Dergelijke veranderingen zijn moeilijk en moeten beoefend worden, niet gekocht. Ze vereisen onderwijs en discipline, niet van een bestelling.”
De mensen bij Google/Alfabet, zijnde de baanbrekers ze altijd zijn, delen hun visie en ervaring met wat ze noemen “site reliability engineering” (SRE), het verstrekken van een aantal voorbeelden van hoe goed afgestemde teams van ontwikkelaars en ops mensen samen kunnen werken om dingen te laten gebeuren. Wees gerust, het is gebakken diep in de Google-cultuur.
Om te verduidelijken, SRE is enigszins verschillend van DevOps, maar kwam op de heup. “Het is interessant dat de SRE beweging kwam los van de DevOps beweging–hoewel er weinig twijfel over bestaan dat ze onderdeel zijn van hetzelfde spectrum met een vergelijkbare waarde voor de klant-gedreven doelen,” Jayne Groll merkt in DevOps.com. “DevOps richt zich op de engineering continue levering aan de punt van de implementatie; SRE richt zich op de engineering of in doorlopende operaties op het punt van de klant consumptie. Beide domeinen rekenen op delen, cultuur, statistieken en automatisering. Beide vereisen menselijke en geautomatiseerde middelen om te zorgen voor een naadloze value stream en bijzondere ervaring voor de klant.”
Een goede illustratie is bepaald door Patrick Heuvel, de site reliability engineer met Atlassian:
“Dev teams willen loslaten geweldige nieuwe functies aan de massa’ s, en zien ze af in een grote weg. Ops teams willen ervoor zorgen dat deze functies niet breken de dingen. Historisch gezien, dat veroorzaakt een grote strijd om de macht, met Ops probeert om de rem te zetten op zoveel releases mogelijk, en Dev op zoek naar slimme nieuwe manieren om te sluipen rond de processen die ze terug. SRE verwijdert de vermoedens en debat over wat kan gestart worden en wanneer. Het introduceert een wiskundige formule voor de groen – of rood-verlichting lanceert, en wijdt een team van mensen met Ops vaardigheden (toepasselijk genaamd Betrouwbaarheid van de Service Engineers, of SRE ‘ s) voortdurend toezicht houden op de betrouwbaarheid van het product.”
In hun nieuwste boek en video ‘ s over het onderwerp, Betsy Beyer, Chris Jones, Jennifer Petoff en Niall Murphy, alle met Google, onthullen wat ze hebben gedaan en voorzien van lessen waarin elke niet-Google enterprise kunt leren. “Voor de maten tussen een startup en een multinational, is er waarschijnlijk al is iemand in uw organisatie die doet het SRE werken, zonder dat het per se genoemd die naam, of als zodanig herkend,” ze wijzen.
SRE “vertegenwoordigt een aanzienlijke onderbreking van bestaande best practices voor het beheren van grote, complexe diensten,” Beyer en haar collega ‘ s schrijven, noteren dit is de beste manier om een software engineer om tijd te investeren voor het bereiken van een set van repetitieve taken. Op hetzelfde moment, “is het veel meer geworden: een set van principes, een set van praktijken, een set van prikkels, en een veld van zich inspannen, binnen de grotere software engineering discipline.”
Het Google-team legt uit dat ze “de toepassing van de principes van computer science and engineering, het ontwerp en de ontwikkeling van computersystemen: over het algemeen, grote gedistribueerd.” Hun taken variëren van “het schrijven van de software voor deze systemen samen met onze product ontwikkeling tegenhangers;” om het bouwen van stukken zoals “back-ups of load balancing” of gewoon “aan het uitzoeken hoe het toepassen van bestaande oplossingen voor nieuwe problemen.”
SREs hebben drie missies: de betrouwbaarheid, de functies en de operationele diensten.
Betrouwbaarheid: Betrouwbaarheid de hoogste prioriteit voor SREs. Het Google-team citeert de woorden van Google ‘ s Ben Treynor Sloss, bedenker van de term SRE: “Betrouwbaarheid is de belangrijkste eigenschap van een product: een systeem is niet erg handig als niemand het kan gebruiken.” Functies: Eenmaal het juiste niveau van betrouwbaarheid worden bereikt, SREs belast zijn met de functies en producten. Operationele diensten: “Eindelijk, SREs zijn gericht op operationele diensten gebouwd bovenop onze distributed computing, ongeacht of deze diensten zijn planeet-schaal-opslag, e-mail voor honderden miljoenen gebruikers, of waar begon Google, zoeken op het web.”
Verwante Onderwerpen:
Datacenters
CXO
Thought Leadership
Innovatie
Tech en Werk
0