{"id":39219,"date":"2019-10-31T22:28:31","date_gmt":"2019-10-31T19:28:31","guid":{"rendered":"https:\/\/prohoster.info\/blog\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire\/"},"modified":"2019-10-31T22:28:31","modified_gmt":"2019-10-31T19:28:31","slug":"devops-i-haos-dostavka-po-v-detsentralizovannom-mire","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","title":{"rendered":"DevOps en Chaos: softwarelevering in een gedecentraliseerde wereld","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Oprichter en directeur van 'Otomato Software', een van de initiators en instructeurs van de eerste DevOps-certificering in Isra\u00ebl, Anton Weiss, sprak vorig jaar over DevOpsDays Moskou<\/a><\/noindex> de chaos-theorie en de belangrijkste principes van chaos engineering, en legde uit hoe de ideale DevOps-organisatie van de toekomst eruit ziet.<\/p>\n

We hebben een tekstversie van de presentatie voorbereid. <\/p>\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center>
\n<\/a><\/noindex>
\nGoedemorgen! <\/p>\n

DevOpsDays in Moskou voor het tweede jaar op rij, ik ben voor de tweede keer op dit podium, velen van jullie zijn voor de tweede keer in deze zaal. Wat betekent dat? Dat betekent dat de DevOps-beweging in Rusland groeit, zich vermenigvuldigt, en vooral, dat het tijd is om te praten over wat DevOps in 2018 eigenlijk is. <\/p>\n

Steek je hand op als je denkt dat DevOps in 2018 al een beroep is? Zijn er zo'n mensen? Zijn er DevOps-engineers in de zaal met 'DevOps-engineer' in hun functiebeschrijving? Zijn er DevOps-managers in de zaal? Geen van beide. DevOps-architecten? Ook niet. Weinig hoor. Is er echt niemand die 'DevOps-engineer' in zijn omschrijving heeft staan?<\/p>\n

Betekent dit dat de meesten van jullie denken dat dit een antipatroon is? Dat zo'n beroep niet zou moeten bestaan? We kunnen denken wat we willen, maar terwijl wij denken, gaat de industrie plechtig verder onder het geluid van de DevOps-trompet.<\/p>\n

Wie heeft gehoord van het nieuwe onderwerp dat DevDevOps heet? Dit is een nieuwe methode die effectief samenwerken tussen ontwikkelaars en DevOps mogelijk maakt. En niet zo nieuw. Als je Twitter gelooft, zijn ze er vier jaar geleden al over begonnen te praten. En de interesse groeit nog steeds, dat betekent dat er een probleem is. Het probleem moet worden opgelost.<\/p>\n

\"DevOps
\n
\nWij zijn creatieve mensen, we geven het eenvoudigweg niet op. We zeggen: DevOps is niet een allesomvattend woord, er ontbreken nog tal van interessante elementen. En we gaan naar onze geheime laboratoria en beginnen nieuwsgierige mutaties te cre\u00ebren: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.<\/p>\n

\"DevOps
\n
\nDe logica is simpel, toch? Ons leveringssysteem is niet functioneel, onze systemen zijn instabiel en gebruikers zijn ontevreden, we slagen er niet in om software op tijd uit te rollen en blijven niet binnen het budget. Hoe gaan we dit allemaal oplossen? We verzinnen een nieuw woord! Het eindigt op 'Ops' en het probleem is opgelost.<\/p>\n

Zo noem ik deze benadering - 'Ops, en het probleem is opgelost'.<\/p>\n

Alles komt op de achtergrond, als we ons herinneren waarom we dit allemaal bedacht hebben. We hebben al deze DevOps bedacht om de levering van software en ons eigen werk in dit proces zo soepel, pijnloos, effici\u00ebnt en vooral plezierig mogelijk te maken. <\/p>\n

DevOps is ontstaan uit pijn. En we zijn moe van het lijden. En om dit alles te realiseren, baseren we ons op duurzame praktijken: effectieve samenwerking, flow-praktijken en vooral systeemdenken, want zonder dat werkt geen enkele DevOps.<\/p>\n

Wat is een systeem?<\/b><\/h3>\n

\nEn als we het hebben over systeemdenken, laten we ons herinneren wat een systeem is.<\/p>\n

\"DevOps
\n
\nAls je een hacker-revolutionair bent, dan is een systeem ondubbelzinnig kwaad. Het is een wolk die boven je hangt en je dwingt dingen te doen die je niet wilt doen. <\/p>\n

\"DevOps
\n
\nVanuit het perspectief van systeemdenken is een systeem een geheel dat uit delen bestaat. In die zin is ieder van ons een systeem. Organisaties waarbij we werken zijn systemen. En wat we samen bouwen, wordt zo genoemd - een systeem.<\/p>\n

Dit is allemaal een onderdeel van \u00e9\u00e9n grote sociotechnologische systeem. En alleen als we begrijpen hoe dit sociotechnologische systeem samenwerkt, kunnen we echt iets optimaliseren. <\/p>\n

Vanuit het perspectief van systeemdenken heeft een systeem verschillende interessante eigenschappen. Ten eerste bestaat het uit delen, wat betekent dat het gedrag ervan afhangt van het gedrag van de delen. Tegelijkertijd zijn alle delen onderling afhankelijk. Het resultaat is dat hoe meer delen een systeem heeft, des te moeilijker het is om het gedrag ervan te begrijpen of te voorspellen. <\/p>\n

Vanuit het perspectief van gedrag is er nog een interessant feit. Een systeem kan iets doen wat geen van de afzonderlijke delen kan doen. <\/p>\n

Zoals Dr. Russell Ackoff (een van de grondleggers van systeemdenken) zei, is dit vrij eenvoudig te bewijzen met behulp van een gedachte-experiment. Bijvoorbeeld, wie in de zaal kan code schrijven? Veel handen, en dat is normaal, want dat is een van de belangrijkste vereisten van onze professie. Je kunt schrijven, maar kunnen je handen apart van jou code schrijven? Er zijn mensen die zeggen: 'Het zijn niet mijn handen die code schrijven, het is mijn hersenen die code schrijven.' Maar kunnen de hersenen apart van jou code schrijven? Waarschijnlijk niet. <\/p>\n

De hersenen zijn een verbazingwekkende machine. We weten zelfs niet voor 10% hoe ze werken, maar ze kunnen niet los functioneren van het systeem dat ons lichaam is. Dit is gemakkelijk te bewijzen: open je schedel, haal de hersenen eruit, leg ze voor een computer en laat ze iets eenvoudigs proberen te schrijven. \"Hallo, wereld\" in Python, bijvoorbeeld.<\/p>\n

Als een systeem iets kan doen dat geen van zijn afzonderlijke delen kan, betekent dit dat het gedrag niet wordt bepaald door de gedragingen van die delen. Maar wat bepaalt het dan? Het wordt bepaald door de interactie tussen deze delen. En hoe meer delen, hoe ingewikkelder de interacties, hoe moeilijker het is om het gedrag van het systeem te begrijpen en te voorspellen. Dit maakt het systeem chaotisch, omdat zelfs de kleinste, onzichtbare verandering in een van de delen tot volledig onvoorspelbare resultaten kan leiden. <\/p>\n

Deze gevoeligheid voor beginvoorwaarden werd voor het eerst ontdekt en bestudeerd door de Amerikaanse meteoroloog Ed Lorenz. Later kreeg het de naam \"vlindereffect\" en leidde het tot de ontwikkeling van een denkrichting die \"chaostheorie\" wordt genoemd. Deze theorie is een van de belangrijkste paradigma verschuivingen in de wetenschap van de 20e eeuw.<\/p>\n

Chaostheorie<\/b><\/h3>\n

\nMensen die chaos bestuderen, noemen zichzelf chaosologen.<\/p>\n

\"DevOps
\n
\nDe eigenlijke reden voor dit verslag is dat ik, terwijl ik werkte met complexe gedistribueerde systemen en grote internationale organisaties, op een gegeven moment besefte dat ik een chaosoloog ben. Dit is eigenlijk een slimmigheidje om te zeggen: \"Ik begrijp niet wat hier aan de hand is en ik weet niet wat ik ermee moet doen.\" <\/p>\n

Ik denk dat velen van jullie je ook vaak zo voelen, dus jullie zijn ook chaosologen. Ik nodig jullie uit in de gilde van chaosologen. De systemen die wij, beste collega chaosologen, gaan bestuderen, worden \"complexe adaptieve systemen\" genoemd. <\/p>\n

Wat is aanpassingsvermogen? Aanpassingsvermogen betekent dat het individuele en collectieve gedrag van delen in een dergelijk aanpassingsysteem verandert en zelforganiseert in reactie op gebeurtenissen of ketens van microgebeurtenissen in het systeem. Met andere woorden, het systeem past zich aan veranderingen aan door middel van zelforganisatie. En deze capaciteit voor zelforganisatie is gebaseerd op vrijwillige, volledig gedecentraliseerde samenwerking van vrije autonome agenten.<\/p>\n

Een andere interessante eigenschap van dergelijke systemen is dat ze vrij schaalbaar zijn. Wat ons, als chaosologen-ing engineers, zeker zou moeten interesseren. Dus, als we zeggen dat het gedrag van een complex systeem wordt bepaald door de interactie van zijn delen, wat moeten we dan interessant vinden? Interactie. <\/p>\n

Er zijn nog twee interessante conclusies.
\n \"DevOps
\n
\nTen eerste begrijpen we dat een complex systeem niet kan worden vereenvoudigd door de delen te vereenvoudigen. Ten tweede is de enige manier om een complex systeem te vereenvoudigen door de interacties tussen de delen te vereenvoudigen. <\/p>\n

Hoe communiceren we? Wij zijn allemaal delen van een groot informatiesysteem dat de menselijke samenleving wordt genoemd. We communiceren via een gemeenschappelijke taal, als we die hebben, als we die vinden.<\/p>\n

\"DevOps
\n
\nMaar taal op zich is een complex adaptief systeem. Daarom is het noodzakelijk om bepaalde protocollen te cre\u00ebren om effectiever en eenvoudiger te kunnen interageren. Dus een bepaalde volgorde van symbolen en acties die de informatie-uitwisseling tussen ons eenvoudiger, voorspelbaarder en begrijpelijker maken.<\/p>\n

Ik wil zeggen dat de tendensen naar complicatie, aanpassingsvermogen, decentralisatie en chaos overal zichtbaar zijn. Zowel in de systemen die we bouwen als in de systemen waarvan we deel uitmaken.<\/p>\n

En om niet zomaar te beweren, laten we kijken naar hoe de systemen die we cre\u00ebren veranderen.<\/p>\n

\"DevOps
\n
\nJe hebt op dit woord gewacht, dat begrijp ik. We zijn op de DevOps-conferentie, vandaag zal dit woord ergens honderdduizend keer worden genoemd en dan zal het ons 's nachts achtervolgen.<\/p>\n

Microservices zijn de eerste softwarearchitectuur die is ontstaan als reactie op DevOps-praktijken, bedoeld om onze systemen flexibeler en schaalbaarder te maken en continue levering mogelijk te maken. Hoe doet het dit? Door de omvang van de services te verkleinen, de grenzen van de problemen die deze services behandelen te beperken en de leveringstijd te verkorten. Dat wil zeggen, we verminderen en vereenvoudigen delen van het systeem, vergroten hun aantal, en daarmee neemt onvermijdelijk de complexiteit van de interacties tussen deze delen toe, wat nieuwe problemen met zich meebrengt die we moeten oplossen.<\/p>\n

\"DevOps
\n
\nMicroservices zijn nog niet het einde; microservices zijn in feite al gisteren, want Serverless komt eraan. Alle servers zijn verbrand, er zijn geen servers meer, geen besturingssystemen, alleen schone uitvoerende code. Configuraties apart, toestanden apart, alles wordt beheerd door gebeurtenissen. Prachtig, schoon, stil \u2014 er gebeurt niets, alles is in perfecte orde. <\/p>\n

Waar ligt de complexiteit? De complexiteit ligt, zoals je kunt verwachten, in de interacties. Hoeveel kan \u00e9\u00e9n functie zelf doen? Hoe interageert ze met andere functies? Wachtrijen, databases, load balancers. Hoe kun je een gebeurtenis recre\u00ebren wanneer er een storing optreedt? Een heleboel vragen en een paar antwoorden.<\/p>\n

Microservices en Serverless zijn alles wat wij, computerhipster, Cloud Native noemen. Het gaat allemaal om de cloud. Maar de cloud is in wezen ook beperkt in schaalbaarheid. We hebben de neiging om het te zien als een gedistribueerd systeem. Maar waar bevinden de servers van cloudaanbieders zich eigenlijk? In datacentra. We hebben hier dus een soort gecentraliseerd, zeer beperkt, gedistribueerd model.<\/p>\n

Tegenwoordig begrijpen we dat het internet der dingen niet alleen maar mooie woorden zijn; zelfs volgens bescheiden voorspellingen staan ons de komende vijf tot tien jaar miljarden apparaten te wachten die met het internet zijn verbonden. Een enorme hoeveelheid nuttige en nutteloze gegevens die naar de cloud zullen stromen en uit de cloud zullen komen. <\/p>\n

De cloud kan het niet aan, daarom spreken we steeds vaker over wat \"edge computing\" wordt genoemd. Of ik vind ook de prachtige term \"fog computing\" leuk. Het is doordrenkt met de mystiek van romantiek en mysterie.<\/p>\n

\"DevOps
\n
\nWazige Computation. Het gaat erom dat de clouds centrale ophopingen zijn van water, damp, ijs en stenen. En mist zijn de waterdruppels die zich verspreid om ons heen in de atmosfeer bevinden. <\/p>\n

In de wazige paradigma voert een groot deel van het werk deze druppels volledig autonoom of in samenwerking met andere druppels uit. Ze wenden zich alleen tot de cloud als ze echt in de problemen zitten. <\/p>\n

Dus opnieuw decentralisatie, autonomie, en natuurlijk begrijpen velen van jullie al waar dit naartoe gaat, want je kunt niet over decentralisatie praten zonder blockchain te noemen. <\/p>\n

\"DevOps
\n
\nEr zijn mensen die geloven, dat zijn degenen die in cryptocurrency hebben ge\u00efnvesteerd. Er zijn mensen die geloven maar bang zijn, zoals ik bijvoorbeeld. En er zijn mensen die niet geloven. Je kunt er verschillende manieren op aansteken. Er is technologie, iets nieuw en onbekend, er zijn problemen. Zoals elke nieuwe technologie roept het meer vragen op dan het antwoorden biedt. <\/p>\n

De hype rondom blockchain is begrijpelijk. Zelfs als we de goudkoorts terzijde schuiven, biedt de technologie zelf schitterende beloftes voor een heldere toekomst: meer vrijheid, meer autonomie, verspreid globaal vertrouwen. Wat is daar niet leuk aan? <\/p>\n

Bijgevolg beginnen steeds meer ingenieurs over de hele wereld gedecentraliseerde applicaties te ontwikkelen. En dit is een kracht waarmee je niet kunt afschuiven door simpelweg te zeggen: 'Ah, blockchain is gewoon slecht ge\u00efmplementeerde distributed database'. Of zoals sceptici graag zeggen: 'Voor blockchain zijn er geen echte toepassingen'. Als je erover nadenkt, zeiden ze 150 jaar geleden hetzelfde over elektriciteit. En in zekere zin hadden ze gelijk, omdat wat elektriciteit vandaag mogelijk maakt, in de 19e eeuw totaal ondenkbaar was.<\/p>\n

Trouwens, wie weet wat het logo op het scherm is? Dat is Hyperledger. Dit is een project dat wordt ontwikkeld onder de vlag van The Linux Foundation, en het omvat een reeks blockchain-technologie\u00ebn. Dit is echt de kracht van onze open source gemeenschap.<\/p>\n

Chaotische engineering<\/b><\/h3>\n

\n\"DevOps
\n
\nDus, het systeem dat we ontwikkelen wordt steeds complexer, chaotischer en adaptiever. Netflix is een pionier in microservicesystemen. Zij waren een van de eersten die dit begrepen en ontwikkelden een set tools die ze Simian Army noemden, waarvan de meest bekende Chaos Monkey<\/a><\/noindex>is. \u00abprincipes van chaotische engineering\u00bb<\/a><\/noindex>.<\/p>\n

Overigens hebben we tijdens het werken aan de presentatie deze tekst zelfs in het Russisch vertaald, dus kom gerust langs via de link<\/a><\/noindex>, lees, commentaar, en bekritiseer.<\/p>\n

Kort gezegd gaan de principes van chaotische engineering over het volgende. Complexe gedistribueerde systemen zijn in wezen onvoorspelbaar en bevatten in wezen fouten. Fouten zijn onontkoombaar, wat betekent dat we deze fouten moeten accepteren en met deze systemen op een heel andere manier moeten omgaan. <\/p>\n

We moeten proberen deze fouten in onze productiesystemen te introduceren, zodat we onze systemen kunnen testen op deze aanpassingsvermogen, deze zelforganiserende capaciteit, deze overlevingskracht. <\/p>\n

En dat verandert alles. Niet alleen hoe we systemen in productie brengen, maar ook hoe we ze ontwikkelen en testen. Er is geen proces van stabilisatie, code bevriezen; integendeel, er is een voortdurend proces van destabilisatie. We proberen het systeem te vernietigen en te zien of het blijft overleven.<\/p>\n

Distributed System Integration Protocols<\/b><\/h3>\n

\n\"DevOps
\n
\nDaarom vereist dit dat onze systemen ook op een bepaalde manier veranderen. Om veerkrachtiger te worden, hebben ze nieuwe protocollen voor interactie tussen hun onderdelen nodig. Zodat deze onderdelen afspraken kunnen maken en tot een soort van zelforganisatie kunnen komen. Er ontstaan allerlei nieuwe tools, nieuwe protocollen, die ik \u2018protocollen voor de interactie van gedistribueerde systemen\u2019 noem.<\/p>\n

\"DevOps
\n
\nWaar heb ik het over? Ten eerste over het project Opentracing<\/a><\/noindex>. Een poging om een gezamenlijk protocol voor gedistribueerd traceren te cre\u00ebren, dat een onmisbaar hulpmiddel is voor het debuggen van complexe gedistribueerde systemen.<\/p>\n

\"DevOps
\n
\nVerder \u2014 Open Policy Agent<\/a><\/noindex>. We zeggen dat we niet kunnen voorspellen wat er met het systeem zal gebeuren, dus we moeten de observability ervan verhogen. Opentracing behoort tot de familie van tools die de observability van onze systemen bieden. Maar observability is nodig om te bepalen of het systeem zich gedraagt zoals we verwachten, of niet. Hoe bepalen we het verwachte gedrag? Door een bepaald beleid, een set regels binnenin te defini\u00ebren. Het project Open Policy Agent houdt zich bezig met het defini\u00ebren van deze set regels over een breed scala: van toegang tot resourceplaatsing.<\/p>\n

\"DevOps
\n
\nZoals we al zeiden, worden onze systemen steeds meer op gebeurtenissen gestuurd. Serverless is een geweldig voorbeeld van op gebeurtenissen gebaseerde systemen. Om gebeurtenissen tussen systemen door te geven en te volgen, hebben we een gemeenschappelijk taal nodig, een gemeenschappelijk protocol voor hoe we over gebeurtenissen praten, hoe we ze aan elkaar doorgeven. Dit wordt behandeld door een project genaamd Cloudevents<\/a><\/noindex>.<\/p>\n

\"DevOps
\n
\nDe constante stroom van veranderingen die onze systemen overspoelt en ze voortdurend destabiliseert, is een onophoudelijke stroom van software-artefacten. Om deze constante stroom van veranderingen te kunnen ondersteunen, hebben we een gemeenschappelijk protocol nodig, waarmee we kunnen communiceren over wat een software-artefact is, hoe het is gecontroleerd en welke verificatie het heeft ondergaan. Dit wordt behandeld door een project genaamd Grafeas<\/a><\/noindex>. Dit is dus het gemeenschappelijke protocol voor metadata van software-artefacten.<\/p>\n

\"DevOps
\n
\nEn ten slotte, als we willen dat onze systemen volledig zelfstandig, adaptief en zelforganiserend zijn, moeten we ze het recht op zelfidentificatie geven. Het project genaamd spiffe<\/a><\/noindex> is precies hiermee bezig. Dit is ook een project onder de Cloud Native Computing Foundation.<\/p>\n

Al deze projecten zijn jong, ze hebben al onze liefde, onze controle nodig. Dit is alles open source, ons testen, onze implementatie. Ze laten ons zien in welke richting de technologie zich ontwikkelt. <\/p>\n

Maar DevOps ging nooit eerst om technologie, het ging altijd eerst om samenwerking tussen mensen. En dus, als we willen dat de systemen die we ontwikkelen veranderen, moeten wijzelf veranderen. Eigenlijk veranderen we al, we hebben niet echt een keuze. <\/p>\n

\"DevOps
\n
\nEr is een geweldig book<\/a><\/noindex> boek van de Britse schrijfster Rachel Botsman, waarin ze schrijft over de evolutie van vertrouwen in de loop van de menselijke geschiedenis. Ze zegt dat vertrouwen in het begin, in vroegere samenlevingen, lokaal was, dat wil zeggen dat we alleen vertrouwden op degenen die we persoonlijk kenden. <\/p>\n

Daarna was er een zeer lange periode \u2013 een donkere tijd \u2013 waarin vertrouwen gecentraliseerd was, waarin we mensen vertrouwden die we niet kenden op basis van het feit dat we tot hetzelfde sociale of staatsinstituut behoorden.<\/p>\n

En dit zien we in onze moderne wereld: vertrouwen wordt steeds meer gedistribueerd en gedecentraliseerd, gebaseerd op de vrijheid van informatiestromen en de toegankelijkheid van informatie. <\/p>\n

Als je erover nadenkt, dan realiseren wij samen deze toegankelijkheid, die dat vertrouwen mogelijk maakt. Dit betekent dat ook onze samenwerking en hoe we dit doen, moet veranderen, omdat gecentraliseerde, hi\u00ebrarchische IT-organisaties van de oude stempel niet langer effectief zijn. Ze beginnen te verdwijnen. <\/p>\n

De basis van DevOps-organisaties<\/b><\/h3>\n

\nDe ideale DevOps-organisatie van de toekomst is een gedecentraliseerd, adaptief systeem, bestaande uit autonome teams, elk bestaande uit autonome individuen. Deze teams zijn verspreid over de hele wereld en werken effectief samen via asynchrone communicatie, met behulp van zeer transparante protocollen voor informatie-uitwisseling. Erg mooi, toch? Een prachtige toekomst.<\/p>\n

Natuurlijk is dit allemaal niet mogelijk zonder culturele veranderingen. We moeten transformationeel leiderschap, persoonlijke verantwoordelijkheid en interne motivatie hebben.<\/p>\n

\"DevOps
\n
\nDit is de basis van DevOps-organisaties: transparantie van informatie, asynchrone communicatie, transformationeel leiderschap, decentralisatie. <\/p>\n

Burn-out<\/b><\/h3>\n

\nDe systemen waarvan we deel uitmaken, en die we bouwen, zijn steeds chaotischer, en het is voor ons mensen moeilijk om deze gedachte te verwerken, moeilijk om de illusie van controle op te geven. We proberen ze te blijven controleren, wat vaak leidt tot burn-out. Ik spreek uit ervaring; ik heb ook mijn brandwonden, ik ben ook slachtoffer van onvoorziene storingen in productie.<\/p>\n

\"DevOps
\n
\nBurn-out ontstaat wanneer we proberen controle te houden over wat in principe niet te controleren is. Wanneer we uitgeput raken, verliest alles zijn betekenis, omdat we de drang verliezen om iets nieuws te doen, we nemen een defensieve houding aan en beginnen te beschermen wat er is. <\/p>\n

Het ingenieursvak, zoals ik graag tegen mezelf zeg, is in de eerste plaats een creatief beroep. Als we de drang verliezen om iets te cre\u00ebren, worden we as en vergetelheid. Mensen branden op, hele organisaties branden op.<\/p>\n

Naar mijn mening is alleen de acceptatie van de scheppende kracht van chaos, alleen het opbouwen van samenwerking volgens zijn principes, hetgeen ons zal helpen om het goede dat in ons beroep is, niet te verliezen. <\/p>\n

Dat wens ik jullie ook: hou van je werk, hou van wat we doen. Deze wereld leeft van informatie, en het is onze eer om deze te voeden. Laten we dus chaos bestuderen, laten we chaotologen zijn, waarde cre\u00ebren, iets nieuws maken, en problemen, zoals we al hebben vastgesteld, zijn onvermijdelijk. Wanneer ze zich voordoen, zeggen we gewoon 'Ops!', en het probleem is opgelost. <\/p>\n

Wat is er naast Chaos Monkey?<\/b><\/p>\n

In feite zijn al deze tools nog zo jong. Netflix zelf heeft tools ontwikkeld die op hen zijn afgestemd. Bouw tools die bij jou passen. Lees de principes van chaos engineering en volg deze principes, in plaats van andere tools te zoeken die door iemand anders zijn gebouwd. <\/p>\n

Probeer te begrijpen hoe jouw systemen falen en begin ze te laten falen en te bekijken hoe ze de klappen opvangen. Dat is prioriteit nummer \u00e9\u00e9n. Tools kunnen later worden gezocht. Er zijn allerlei projecten. <\/p>\n

Ik begreep niet helemaal het punt dat je maakte over het feit dat je een systeem niet kunt vereenvoudigen door de componenten te vereenvoudigen, en toen onmiddellijk overstapte op microservices, die het systeem juist vereenvoudigen door de componenten te vereenvoudigen en de interacties te compliceren. Dit zijn in wezen twee delen die elkaar tegenspreken. <\/b><\/p>\n

Helemaal waar, microservices zijn over het algemeen een zeer controversieel onderwerp. In feite verhoogt het vereenvoudigen van delen de flexibiliteit. Wat geven microservices ons? Ze geven ons flexibiliteit en snelheid, maar ze geven ons zeker geen eenvoud. Ze verhogen de complexiteit.<\/p>\n

Dus in de DevOps-filosofie zijn microservices niet per se een zegen?<\/b><\/p>\n

Elke zegen heeft een schaduwkant. Er is een zegen: het verhoogt de flexibiliteit en geeft ons de mogelijkheid om sneller wijzigingen aan te brengen, maar verhoogt ook de complexiteit en daarmee de kwetsbaarheid van het hele systeem. <\/p>\n

Waar ligt de nadruk meer op: op het vereenvoudigen van interacties of op het vereenvoudigen van de delen?<\/b> <\/p>\n

De nadruk ligt ongetwijfeld op het vereenvoudigen van de interactie, want als we er vanuit het perspectief van onze samenwerking naar kijken, moeten we in de eerste plaats focussen op het vereenvoudigen van interacties en niet op het vereenvoudigen van ons individu. Want het vereenvoudigen van werk betekent dat we als robots functioneren. Bij McDonald's werkt dat goed wanneer je instructies hebt: hier leg je de hamburger, daar voeg je de saus toe. In ons creatieve werk werkt dat totaal niet.<\/p>\n

Is het waar dat alles wat u heeft verteld, zich in een wereld zonder concurrentie bevindt, waar de chaos vriendelijk is en er binnen die chaos geen tegenstrijdigheden zijn, niemand wil iemand anders opeten of doden? Hoe moeten concurrentie en DevOps samenleven?<\/b><\/p>\n

Nou, dat hangt ervan af over welke concurrentie we het hebben. Is het concurrentie op de werkplek of concurrentie tussen bedrijven? <\/p>\n

Over de concurrentie tussen diensten die er zijn, want diensten zijn niet slechts een paar bedrijven. We cre\u00ebren een nieuw type informatieomgeving, en elke omgeving kan niet zonder concurrentie bestaan. Overal is er concurrentie.<\/b><\/p>\n

Neem bijvoorbeeld Netflix als ons rolmodel. Waarom hebben ze dit bedacht? Omdat ze competitief moesten blijven. Deze flexibiliteit en snelheid van handelen is precies die competitieve eis, die chaotisch gedrag in onze systemen introduceert. Chaos is niet iets dat we bewust cre\u00ebren omdat we het willen, maar iets dat voortkomt uit de eisen van de wereld. We moeten gewoon ons aanpassen. Chaos is het resultaat van concurrentie.<\/p>\n

Betekent dit dat chaos het ontbreken van doelen is? Of zijn het doelen die we niet willen zien? We zitten in een huisje en begrijpen de doelen van anderen niet. Concurrentie draait eigenlijk om het hebben van duidelijke doelen en te weten waar we in elk volgend moment naartoe gaan. Dat is naar mijn mening de essentie van DevOps.<\/b><\/p>\n

Ook een kijk op de zaak. Ik denk dat we allemaal \u00e9\u00e9n doel hebben: overleven en dat doen met
\nde grootste vreugde. En het concurrentiele doel van elke organisatie is hetzelfde. Overleven gebeurt vaak in een competitieve strijd, daar valt niets aan te doen.<\/p>\n

Dit jaar vindt de conferentie DevOpsDays Moskou<\/a><\/noindex> plaats op 7 december in 'Technopolis'. Tot 11 november accepteren we voorstellen voor lezingen. Neem contact met ons op<\/a><\/noindex> als je wilt spreken.<\/p>\n

De registratie voor deelnemers is geopend, een ticket kost 7000 roebel. Sluit je aan! \n<\/p><\/blockquote>\n

Bron: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0438 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440 \u00abOtomato Software\u00bb, \u043e\u0434\u0438\u043d \u0438\u0437 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u043e\u0440\u043e\u0432 \u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0442\u043e\u0440\u043e\u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0418\u0437\u0440\u0430\u0438\u043b\u0435 DevOps-\u0441\u0435\u0440\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u0410\u043d\u0442\u043e\u043d \u0412\u0430\u0439\u0441 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b \u043d\u0430 \u043f\u0440\u043e\u0448\u043b\u043e\u0433\u043e\u0434\u043d\u0435\u043c DevOpsDays Moscow \u043f\u0440\u043e \u0442\u0435\u043e\u0440\u0438\u044e \u0445\u0430\u043e\u0441\u0430 \u0438 \u0433\u043b\u0430\u0432\u043d\u044b\u0435 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0445\u0430\u043e\u0441\u043d\u043e\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0438\u0438, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043e\u0431\u044a\u044f\u0441\u043d\u0438\u043b, \u043a\u0430\u043a \u0443\u0441\u0442\u0440\u043e\u0435\u043d\u0430 \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u0430\u044f DevOps-\u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u044f \u0431\u0443\u0434\u0443\u0449\u0435\u0433\u043e. \u041c\u044b \u043f\u0440\u0438\u0433\u043e\u0442\u043e\u0432\u0438\u043b\u0438 \u0442\u0435\u043a\u0441\u0442\u043e\u0432\u0443\u044e \u0432\u0435\u0440\u0441\u0438\u044e \u0434\u043e\u043a\u043b\u0430\u0434\u0430. \u0414\u043e\u0431\u0440\u043e\u0435 \u0443\u0442\u0440\u043e! DevOpsDays \u0432 \u041c\u043e\u0441\u043a\u0432\u0435 \u0432\u0442\u043e\u0440\u043e\u0439 \u0433\u043e\u0434 \u043f\u043e\u0434\u0440\u044f\u0434, \u044f \u0432\u0442\u043e\u0440\u043e\u0439 \u0440\u0430\u0437 \u043d\u0430 \u044d\u0442\u043e\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29435,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39219","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47DevOps en Chaos: softwarelevering in een gedecentraliseerde wereld | ProHoster","description":"Oprichter en directeur van 'Otomato Software', een van de initiators en instructeurs van de eerste DevOps-certificering in Isra\u00ebl, Anton Weiss, sprak vorig jaar over","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0414\u0435\u0432\u041e\u043f\u0441 \u0438 \u0425\u0430\u043e\u0441: \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0430 \u041f\u041e \u0432 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u043e\u043c \u043c\u0438\u0440\u0435 | ProHoster","og:description":"\u041e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0438 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440 \u00abOtomato Software\u00bb, \u043e\u0434\u0438\u043d \u0438\u0437 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u043e\u0440\u043e\u0432 \u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0442\u043e\u0440\u043e\u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0418\u0437\u0440\u0430\u0438\u043b\u0435 DevOps-\u0441\u0435\u0440\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u0410\u043d\u0442\u043e\u043d \u0412\u0430\u0439\u0441 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b \u043d\u0430 \u043f\u0440\u043e\u0448\u043b\u043e\u0433\u043e\u0434\u043d\u0435\u043c","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:28:31+00:00","article:modified_time":"2019-10-31T19:28:31+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39219","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 01:19:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:54:41","updated":"2026-01-24 01:19:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/39219","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=39219"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/39219\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/29435"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=39219"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=39219"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=39219"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}