Anton Weiss, oprichter en directeur van Otomato Software, een van de initiatiefnemers en instructeurs van Israëls eerste DevOps-certificering, sprak vorig jaar op de over chaostheorie en de belangrijkste principes van chaos engineering, en legde ook uit hoe de ideale DevOps-organisatie van de toekomst werkt.
Wij hebben een tekstversie van het rapport opgesteld.
Goedemorgen!
DevOpsDays in Moskou voor het tweede jaar op rij, dit is de tweede keer dat ik op dit podium sta, velen van jullie zijn voor de tweede keer in deze zaal. Wat betekent het? Dit betekent dat de DevOps-beweging in Rusland groeit en zich vermenigvuldigt, en het belangrijkste is dat het tijd is om te praten over wat DevOps in 2018 is.
Handen opsteken die denken dat DevOps anno 2018 al een vak is? Er zijn zulke. Zijn er DevOps-ingenieurs in de ruimte waarvan de functiebeschrijving 'DevOps-ingenieur' luidt? Zijn er DevOps-managers in de ruimte? Er is niet zoiets als. DevOps-architecten? Ook nee. Niet genoeg. Is het echt waar dat niemand zegt dat hij een DevOps-ingenieur is?
Dus de meesten van jullie denken dat dit een anti-patroon is? Dat zo’n beroep niet zou mogen bestaan? We kunnen denken wat we willen, maar terwijl we nadenken, gaat de industrie plechtig vooruit op het geluid van de DevOps-trompet.
Wie heeft er gehoord over een nieuw onderwerp genaamd DevDevOps? Dit is een nieuwe techniek die effectieve samenwerking tussen ontwikkelaars en devops mogelijk maakt. En niet zo nieuw. Afgaande op Twitter begonnen ze hier 4 jaar geleden al over te praten. En tot nu toe groeit de belangstelling hiervoor steeds meer, dat wil zeggen dat er een probleem is. Het probleem moet worden opgelost.
Wij zijn creatieve mensen, we rusten niet alleen maar uit. Wij zeggen: DevOps is niet een voldoende omvattend woord; het mist nog steeds allerlei verschillende, interessante elementen. En we gaan naar onze geheime laboratoria en beginnen interessante mutaties te produceren: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
De logica is ijzersterk, toch? Ons leveringssysteem werkt niet, onze systemen zijn instabiel en onze gebruikers zijn ontevreden, we hebben geen tijd om software op tijd uit te rollen, we passen niet in het budget. Hoe gaan we dit allemaal oplossen? Wij bedenken een nieuw woord! Het eindigt met "Ops" en het probleem is opgelost.
Dus ik noem deze aanpak: “Ops, en het probleem is opgelost.”
Dit verdwijnt allemaal naar de achtergrond als we onszelf eraan herinneren waarom we dit allemaal hebben bedacht. We hebben dit hele DevOps-gedoe bedacht om de softwarelevering en ons eigen werk in dit proces zo ongehinderd, pijnloos, efficiënt en vooral plezierig mogelijk te maken.
DevOps is ontstaan uit pijn. En we zijn het lijden beu. En om dit allemaal te laten gebeuren, vertrouwen we op groenblijvende praktijken: effectieve samenwerking, flow-praktijken en, belangrijker nog, systeemdenken, want zonder dit werkt DevOps niet.
Wat is een systeem?
En als we het al hebben over systeemdenken, laten we onszelf er dan aan herinneren wat een systeem is.
Als je een revolutionaire hacker bent, dan is het systeem voor jou duidelijk slecht. Het is een wolk die boven je hangt en je dwingt dingen te doen die je niet wilt doen.
Vanuit het perspectief van het systeemdenken is een systeem een geheel dat uit delen bestaat. In die zin is ieder van ons een systeem. De organisaties waarin wij werken zijn systemen. En wat jij en ik bouwen, wordt een systeem genoemd.
Dit alles maakt deel uit van één groot sociaal-technologisch systeem. En alleen als we begrijpen hoe dit sociaal-technologische systeem samenwerkt, alleen dan kunnen we op dit gebied echt iets optimaliseren.
Vanuit systeemdenken heeft een systeem verschillende interessante eigenschappen. Ten eerste bestaat het uit onderdelen, wat betekent dat het gedrag ervan afhangt van het gedrag van de onderdelen. Bovendien zijn alle onderdelen ook onderling afhankelijk. Het blijkt dat hoe meer onderdelen een systeem heeft, hoe moeilijker het is om het gedrag ervan te begrijpen of te voorspellen.
Vanuit gedragsoogpunt is er nog een interessant feit. Het systeem kan iets dat geen van de afzonderlijke onderdelen ervan kan.
Zoals Dr. Russell Ackoff (een van de grondleggers van het systeemdenken) zei: dit is vrij eenvoudig te bewijzen met een gedachte-experiment. Wie in de zaal kan bijvoorbeeld code schrijven? Er zijn veel handen, en dit is normaal, omdat dit een van de belangrijkste vereisten is voor ons beroep. Weet jij hoe je moet schrijven, maar kunnen jouw handen afzonderlijk van jou code schrijven? Er zijn mensen die zullen zeggen: “Het zijn niet mijn handen die de code schrijven, het zijn mijn hersenen die de code schrijven.” Kunnen jouw hersenen afzonderlijk van jou code schrijven? Nou ja, waarschijnlijk niet.
De hersenen zijn een geweldige machine. We weten nog niet eens 10% hoe ze daar werken, maar ze kunnen niet los van het systeem dat ons lichaam is, functioneren. En dit is gemakkelijk te bewijzen: open je schedel, haal je hersenen eruit, plaats het voor de computer en laat hem proberen iets eenvoudigs te schrijven. "Hallo wereld" in Python bijvoorbeeld.
Als een systeem iets kan dat geen van zijn onderdelen afzonderlijk kan, betekent dit dat zijn gedrag niet wordt bepaald door het gedrag van zijn onderdelen. Waar wordt het dan door bepaald? Het wordt bepaald door de interactie tussen deze onderdelen. En dienovereenkomstig geldt: hoe meer onderdelen, hoe complexer de interacties, hoe moeilijker het is om het gedrag van het systeem te begrijpen en te voorspellen. En dit maakt zo’n systeem chaotisch, omdat elke, zelfs de meest onbeduidende, onzichtbare verandering in welk deel van het systeem dan ook tot volkomen onvoorspelbare resultaten kan leiden.
Deze gevoeligheid voor beginomstandigheden werd voor het eerst ontdekt en bestudeerd door de Amerikaanse meteoroloog Ed Lorenz. Vervolgens werd dit het ‘vlindereffect’ genoemd en leidde het tot de ontwikkeling van een beweging van wetenschappelijk denken die ‘chaostheorie’ werd genoemd. Deze theorie werd een van de belangrijkste paradigmaverschuivingen in de wetenschap van de 20e eeuw.
Chaos theorie
Mensen die chaos bestuderen noemen zichzelf chaosologen.
De reden voor dit rapport was eigenlijk dat ik, toen ik met complexe gedistribueerde systemen en grote internationale organisaties werkte, op een gegeven moment besefte dat dit is wie ik voel. Ik ben een chaosoloog. Dit is eigenlijk een slimme manier om te zeggen: “Ik begrijp niet wat hier aan de hand is en ik weet niet wat ik eraan moet doen.”
Ik denk dat velen van jullie zich ook vaak zo voelen, dus jullie zijn ook chaosologen. Ik nodig je uit voor het gilde van chaosologen. De systemen die jij en ik, beste collega-chaosologen, zullen bestuderen, worden ‘complexe adaptieve systemen’ genoemd.
Wat is aanpassingsvermogen? Aanpassingsvermogen betekent dat het individuele en collectieve gedrag van onderdelen in zo’n adaptief systeem verandert en zichzelf organiseert, en reageert op gebeurtenissen of ketens van micro-gebeurtenissen in het systeem. Dat wil zeggen dat het systeem zich aanpast aan veranderingen door middel van zelforganisatie. En dit vermogen tot zelforganisatie is gebaseerd op de vrijwillige, volledig gedecentraliseerde samenwerking van vrije, autonome agenten.
Een andere interessante eigenschap van dergelijke systemen is dat ze vrij schaalbaar zijn. Wat ons als chaosologen-ingenieurs ongetwijfeld zou moeten interesseren. Dus als we zeggen dat het gedrag van een complex systeem wordt bepaald door de interactie tussen de onderdelen ervan, waar zouden we dan in geïnteresseerd moeten zijn? Interactie.
Er zijn nog twee interessante bevindingen.
Ten eerste begrijpen we dat een complex systeem niet kan worden vereenvoudigd door de onderdelen ervan te vereenvoudigen. Ten tweede is de enige manier om een complex systeem te vereenvoudigen het vereenvoudigen van de interacties tussen de onderdelen ervan.
Hoe gaan we met elkaar om? Jij en ik maken allemaal deel uit van een groot informatiesysteem dat de menselijke samenleving wordt genoemd. We communiceren via een gemeenschappelijke taal, als we die hebben, als we die vinden.
Maar taal zelf is een complex adaptief systeem. Om efficiënter en eenvoudiger te kunnen communiceren, moeten we daarom een soort protocollen creëren. Dat wil zeggen, een reeks symbolen en acties die de uitwisseling van informatie tussen ons eenvoudiger, voorspelbaarder en begrijpelijker zullen maken.
Ik wil zeggen dat trends naar complexiteit, naar aanpassingsvermogen, naar decentralisatie, naar chaos in alles terug te vinden zijn. En in de systemen die jij en ik bouwen, en in de systemen waarvan wij deel uitmaken.
En laten we, om niet ongegrond te zijn, eens kijken naar hoe de systemen die we creëren veranderen.
Je zat op dit woord te wachten, dat begrijp ik. We zijn op een DevOps-conferentie, vandaag zal dit woord zo'n honderdduizend keer gehoord worden en dan zullen we er 's nachts over dromen.
Microservices zijn de eerste softwarearchitectuur die is ontstaan als reactie op DevOps-praktijken en die is ontworpen om onze systemen flexibeler en schaalbaarder te maken en een continue levering te garanderen. Hoe doet ze dit? Door het volume van de diensten te verkleinen, de omvang van de problemen die deze diensten verwerken te verkleinen, en de levertijd te verkorten. Dat wil zeggen, we verminderen en vereenvoudigen delen van het systeem, vergroten hun aantal, en dienovereenkomstig neemt de complexiteit van de interacties tussen deze delen steevast toe, dat wil zeggen dat er nieuwe problemen ontstaan die we moeten oplossen.
Microservices zijn niet het einde, microservices zijn over het algemeen al gisteren, want Serverless komt eraan. Alle servers zijn afgebrand, geen servers, geen besturingssystemen, alleen pure uitvoerbare code. Configuraties zijn gescheiden, toestanden zijn gescheiden, alles wordt bestuurd door gebeurtenissen. Schoonheid, netheid, stilte, geen gebeurtenissen, er gebeurt niets, volledige orde.
Waar zit de complexiteit? De moeilijkheid zit hem uiteraard in de interacties. Hoeveel kan één functie op zichzelf doen? Hoe werkt het samen met andere functies? Berichtenwachtrijen, databases, balancers. Hoe kan ik een gebeurtenis opnieuw creëren nadat er een fout is opgetreden? Veel vragen en weinig antwoorden.
Microservices en Serverless zijn wat wij nerd hipsters Cloud Native noemen. Het draait allemaal om de wolk. Maar de cloud is ook inherent beperkt in zijn schaalbaarheid. We zijn eraan gewend het als een gedistribueerd systeem te beschouwen. Waar bevinden de servers van cloudproviders zich eigenlijk? In datacenters. Dat wil zeggen, we hebben hier een soort gecentraliseerd, zeer beperkt, gedistribueerd model.
Tegenwoordig begrijpen we dat het internet der dingen niet langer alleen maar grote woorden zijn: zelfs volgens bescheiden voorspellingen staan ons de komende vijf tot tien jaar miljarden met internet verbonden apparaten op ons te wachten. Een enorme hoeveelheid nuttige en nutteloze gegevens die in de cloud worden samengevoegd en vanuit de cloud worden geüpload.
De cloud zal niet lang meegaan, dus we hebben het steeds vaker over iets dat edge computing wordt genoemd. Of ik hou ook van de prachtige definitie van ‘fog computing’. Het is gehuld in de mystiek van romantiek en mysterie.
Mist computergebruik. Het punt is dat wolken gecentraliseerde klonten water, stoom, ijs en stenen zijn. En mist zijn waterdruppels die om ons heen in de atmosfeer verspreid zijn.
In het mistparadigma wordt het meeste werk door deze druppels volledig autonoom of in samenwerking met andere druppels gedaan. En ze wenden zich pas tot de cloud als ze echt onder druk komen te staan.
Dat wil zeggen, opnieuw decentralisatie, autonomie, en natuurlijk begrijpen velen van jullie al waar dit allemaal naartoe gaat, omdat je niet over decentralisatie kunt praten zonder de blockchain te noemen.
Er zijn mensen die geloven, dit zijn degenen die in cryptocurrency hebben geïnvesteerd. Er zijn mensen die geloven maar bang zijn, zoals ik bijvoorbeeld. En er zijn mensen die niet geloven. Hier kun je anders behandelen. Er is technologie, een nieuwe onbekende kwestie, er zijn problemen. Zoals elke nieuwe technologie roept het meer vragen op dan het beantwoordt.
De hype rond blockchain is begrijpelijk. Afgezien van de goudkoorts houdt de technologie zelf opmerkelijke beloften in voor een betere toekomst: meer vrijheid, meer autonomie, verdeeld mondiaal vertrouwen. Wat wil je niet?
Dienovereenkomstig beginnen steeds meer ingenieurs over de hele wereld gedecentraliseerde applicaties te ontwikkelen. En dit is een macht die niet kan worden afgewezen door simpelweg te zeggen: “Ahh, blockchain is gewoon een slecht geïmplementeerde gedistribueerde database.” Of zoals sceptici graag zeggen: “Er zijn geen echte toepassingen voor blockchain.” Als je erover nadenkt: 150 jaar geleden zeiden ze hetzelfde over elektriciteit. En in sommige opzichten hadden ze zelfs gelijk, want wat elektriciteit vandaag mogelijk maakt, was in de 19e eeuw op geen enkele manier mogelijk.
Trouwens, wie weet wat voor logo er op het scherm staat? Dit is Hyperledger. Dit is een project dat wordt ontwikkeld onder auspiciën van The Linux Foundation en een reeks blockchain-technologieën omvat. Dit is echt de kracht van onze open source-gemeenschap.
Chaos-techniek
Het systeem dat we ontwikkelen wordt dus steeds complexer, steeds chaotischer en steeds adaptiever. Netflix is een pionier op het gebied van microservicesystemen. Zij behoorden tot de eersten die dit begrepen. Ze ontwikkelden een reeks gereedschappen die ze Simian Army noemden, waarvan de bekendste was . Hij definieerde wat bekend werd als .
Trouwens, tijdens het werken aan het rapport hebben we deze tekst zelfs in het Russisch vertaald, dus ga naar , lezen, commentaar geven, schelden.
In het kort zeggen de principes van chaos-engineering het volgende. Complexe gedistribueerde systemen zijn inherent onvoorspelbaar en inherent met fouten. Fouten zijn onvermijdelijk, wat betekent dat we deze fouten moeten accepteren en op een heel andere manier met deze systemen moeten werken.
Wij moeten zelf proberen deze fouten in onze productiesystemen te introduceren om onze systemen te testen op hetzelfde aanpassingsvermogen, dit vermogen tot zelforganisatie en overleving.
En dat verandert alles. Niet alleen hoe we systemen in productie brengen, maar ook hoe we ze ontwikkelen, hoe we ze testen. Er is geen proces van stabilisatie of bevriezing van de code; integendeel, er is een voortdurend proces van destabilisatie. Wij proberen het systeem te vernietigen en te zorgen dat het blijft overleven.
Gedistribueerde systeemintegratieprotocollen
Daarom vereist dit dat onze systemen op de een of andere manier veranderen. Om ze stabieler te maken, hebben ze een aantal nieuwe protocollen nodig voor de interactie tussen hun onderdelen. Zodat deze delen het eens kunnen worden en tot een soort zelforganisatie kunnen komen. En er ontstaan allerlei nieuwe tools en nieuwe protocollen, die ik ‘protocollen voor de interactie van gedistribueerde systemen’ noem.
Waar heb ik het over? Ten eerste het project . Sommigen proberen een algemeen gedistribueerd trackingprotocol te creëren, wat een absoluut onmisbaar hulpmiddel is voor het debuggen van complexe gedistribueerde systemen.
Verder - . We zeggen dat we niet kunnen voorspellen wat er met het systeem zal gebeuren, dat wil zeggen dat we de waarneembaarheid en waarneembaarheid ervan moeten vergroten. Opentracing behoort tot een familie van tools die onze systemen waarneembaar maken. Maar we hebben waarneembaarheid nodig om te bepalen of het systeem zich gedraagt zoals we verwachten of niet. Hoe definiëren we verwacht gedrag? Door een soort beleid te definiëren, een stel regels. Het Open Policy Agent-project werkt aan het definiëren van deze reeks regels over een spectrum variërend van toegang tot toewijzing van middelen.
Zoals we al zeiden, worden onze systemen steeds meer gebeurtenisgestuurd. Serverless is een goed voorbeeld van gebeurtenisgestuurde systemen. Om gebeurtenissen tussen systemen te kunnen overbrengen en ze te kunnen volgen, hebben we een gemeenschappelijke taal nodig, een gemeenschappelijk protocol voor de manier waarop we over gebeurtenissen praten en hoe we ze naar elkaar overbrengen. Zo heet een project .
De constante stroom van veranderingen die over onze systemen spoelt en ze voortdurend destabiliseert, is een continue stroom van softwareartefacten. Om deze constante stroom van veranderingen in stand te kunnen houden, hebben we een soort gemeenschappelijk protocol nodig waarmee we kunnen praten over wat een softwareartefact is, hoe het wordt getest en welke verificatie het heeft doorstaan. Zo heet een project . Dat wil zeggen, een gemeenschappelijk metadataprotocol voor softwareartefacten.
En ten slotte, als we willen dat onze systemen volledig onafhankelijk, adaptief en zelforganiserend zijn, moeten we ze het recht op zelfidentificatie geven. Project gebeld Dit is precies wat hij doet. Ook dit is een project onder auspiciën van de Cloud Native Computing Foundation.
Al deze projecten zijn jong, ze hebben allemaal onze liefde en onze validatie nodig. Dit is allemaal open source, onze tests, onze implementatie. Ze laten ons zien waar de technologie naartoe gaat.
Maar DevOps ging nooit primair over technologie, het ging altijd over samenwerking tussen mensen. En dienovereenkomstig, als we willen dat de systemen die we ontwikkelen veranderen, moeten we zelf ook veranderen. Sterker nog, we veranderen hoe dan ook; we hebben niet veel keuze.
Er is een prachtige De Britse schrijfster Rachel Botsman, waarin ze schrijft over de evolutie van vertrouwen door de menselijke geschiedenis heen. Ze zegt dat vertrouwen in primitieve samenlevingen aanvankelijk lokaal was, dat wil zeggen dat we alleen degenen vertrouwden die we persoonlijk kennen.
Toen was er een heel lange periode – een donkere tijd waarin vertrouwen werd gecentraliseerd, waarin we mensen begonnen te vertrouwen die we niet kennen op basis van het feit dat we tot dezelfde publieke of staatsinstelling behoren.
En dit is wat we zien in onze moderne wereld: vertrouwen wordt steeds meer gedistribueerd en gedecentraliseerd, en is gebaseerd op de vrijheid van informatiestromen, op de beschikbaarheid van informatie.
Als je erover nadenkt, is het juist deze toegankelijkheid, die dit vertrouwen mogelijk maakt, wat jij en ik implementeren. Dit betekent dat zowel de manier waarop we samenwerken als de manier waarop we dat doen, moet veranderen, omdat de gecentraliseerde, hiërarchische IT-organisaties van weleer niet meer werken. Ze beginnen af te sterven.
DevOps-organisatiefundamenten
De ideale DevOps-organisatie van de toekomst is een gedecentraliseerd, adaptief systeem dat bestaat uit autonome teams, elk bestaande uit autonome individuen. Deze teams zijn over de hele wereld verspreid en werken effectief met elkaar samen via asynchrone communicatie en zeer transparante communicatieprotocollen. Heel mooi, nietwaar? Een hele mooie toekomst.
Dit alles is uiteraard niet mogelijk zonder cultuurverandering. We hebben transformationeel leiderschap, persoonlijke verantwoordelijkheid en interne motivatie nodig.
Dit is de basis van DevOps-organisaties: informatietransparantie, asynchrone communicatie, transformationeel leiderschap, decentralisatie.
Burnout
De systemen waar we deel van uitmaken en de systemen die we bouwen worden steeds chaotischer, en het is voor ons mensen moeilijk om met deze gedachte om te gaan, het is moeilijk om de illusie van controle op te geven. We proberen ze onder controle te blijven houden, en dit leidt vaak tot burn-out. Ik zeg dit uit eigen ervaring, ik raakte ook verbrand, ik werd ook uitgeschakeld door onvoorziene mislukkingen in de productie.
Burn-out ontstaat wanneer we proberen controle te krijgen over iets dat inherent oncontroleerbaar is. Als we opbranden, verliest alles zijn betekenis omdat we het verlangen verliezen om iets nieuws te doen, we defensief worden en beginnen te verdedigen wat we hebben.
Het ingenieursberoep is, zoals ik mezelf vaak in herinnering breng, in de eerste plaats een creatief beroep. Als we het verlangen verliezen om iets te creëren, veranderen we in as, in as. Mensen raken opgebrand, hele organisaties branden op.
Naar mijn mening zal alleen het accepteren van de creatieve kracht van chaos, het alleen opbouwen van samenwerking volgens de principes ervan, ons helpen het goede in ons beroep niet te verliezen.
Dit is wat ik je wens: liefde voor je werk, liefde voor wat we doen. Deze wereld voedt zich met informatie, wij hebben de eer deze te voeden. Dus laten we de chaos bestuderen, laten we chaosologen zijn, laten we waarde brengen, iets nieuws creëren. Welnu, problemen zijn, zoals we al hebben ontdekt, onvermijdelijk, en als ze verschijnen, zullen we eenvoudigweg zeggen: "Ops!" En het probleem is opgelost.
Wat anders dan Chaos Monkey?
In feite zijn al deze instrumenten nog zo jong. Dezelfde Netflix heeft tools voor zichzelf gebouwd. Bouw je eigen gereedschap. Lees de principes van chaos-engineering en leef die principes na in plaats van te proberen andere tools te vinden die iemand anders al heeft gebouwd.
Probeer te begrijpen hoe uw systemen kapot gaan en begin ze af te breken en kijk hoe ze stand houden. Dit komt op de eerste plaats. En je kunt op zoek gaan naar hulpmiddelen. Er zijn allerlei projecten.
Ik begreep het moment niet helemaal waarop je zei dat het systeem niet vereenvoudigd kan worden door de componenten ervan te vereenvoudigen, en ging onmiddellijk over op microservices, die het systeem vereenvoudigen door de componenten zelf te vereenvoudigen en de interacties te compliceren. Dit zijn feitelijk twee delen die elkaar tegenspreken.
Dat klopt, microservices zijn over het algemeen een zeer controversieel onderwerp. Het vereenvoudigen van onderdelen vergroot zelfs de flexibiliteit. Wat bieden microservices? Ze geven ons flexibiliteit en snelheid, maar zeker geen eenvoud. Ze verhogen de moeilijkheidsgraad.
Dus in de DevOps-filosofie zijn microservices niet zo’n goede zaak?
Elk goed heeft een keerzijde. Het voordeel is dat het de flexibiliteit vergroot, waardoor we sneller veranderingen kunnen doorvoeren, maar het vergroot de complexiteit en daarmee de kwetsbaarheid van het hele systeem.
Maar waar ligt meer nadruk: op het vereenvoudigen van de interactie of op het vereenvoudigen van onderdelen?
De nadruk ligt uiteraard op het vereenvoudigen van interacties, want als we dit bekijken vanuit het perspectief van hoe we met u samenwerken, moeten we allereerst aandacht besteden aan het vereenvoudigen van interacties, en niet op het vereenvoudigen van het werk. van ieder van ons afzonderlijk. Want het vereenvoudigen van het werk betekent dat je in robots verandert. Hier bij McDonald's werkt het normaal als je instructies hebt: hier leg je de burger, hier giet je de saus erover. Dit werkt helemaal niet in ons creatieve werk.
Is het waar dat alles wat je zei leeft in een wereld zonder concurrentie, en dat de chaos daar zo vriendelijk is, en dat er geen tegenstrijdigheden zijn in deze chaos, niemand wil iemand opeten of doden? Hoe moeten de concurrentie en DevOps het doen?
Nou, het hangt ervan af over wat voor soort concurrentie we het hebben. Gaat het om concurrentie op de werkvloer of om concurrentie tussen bedrijven?
Over de concurrentie van diensten die bestaan omdat diensten niet door meerdere bedrijven bestaan. We creëren een nieuw type informatieomgeving, en elke omgeving kan niet leven zonder concurrentie. Er is overal concurrentie.
Dezelfde Netflix, we nemen ze als rolmodel. Waarom hebben ze dit bedacht? Omdat ze competitief moesten zijn. Deze flexibiliteit en snelheid van beweging is precies de zeer competitieve vereiste; het introduceert chaos in onze systemen. Dat wil zeggen: chaos is niet iets dat we bewust doen omdat we het willen, het is iets dat gebeurt omdat de wereld erom vraagt. We moeten ons gewoon aanpassen. En chaos, dat is juist het gevolg van concurrentie.
Betekent dit dat chaos als het ware de afwezigheid van doelen is? Of die doelen die we niet willen zien? We zijn in huis en begrijpen de doelen van anderen niet. Concurrentie is in feite te danken aan het feit dat we duidelijke doelen hebben en weten waar we elk volgend moment zullen eindigen. Dit is, vanuit mijn oogpunt, de essentie van DevOps.
Kijk ook eens naar de vraag. Ik denk dat we allemaal hetzelfde doel hebben: overleven en het meemaken
grootste plezier. En het concurrentiedoel van elke organisatie is hetzelfde. Overleven gebeurt vaak door competitie, daar kun je niets aan doen.
De conferentie van dit jaar vindt plaats op 7 december in Technopolis. We accepteren aanvragen voor rapporten tot 11 november. ons als u wilt spreken.
Registratie voor deelnemers is open, kaartjes kosten 7000 roebel. Doe met ons mee!
Bron: www.habr.com