Letztes Jahr sprach Anton Weiss, Gründer und Direktor von Otomato Software, einem der Initiatoren und Ausbilder der ersten DevOps-Zertifizierung in Israel über die Chaostheorie und die Hauptprinzipien des Chaos Engineering und erläuterte auch, wie die ideale DevOps-Organisation der Zukunft funktioniert.
Wir haben eine Textversion des Berichts erstellt.
Guten Morgen!
DevOpsDays in Moskau zum zweiten Mal in Folge, das ist mein zweites Mal auf dieser Bühne, viele von Ihnen sind zum zweiten Mal in diesem Raum. Was bedeutet das? Das bedeutet, dass die DevOps-Bewegung in Russland wächst und sich vervielfacht, und vor allem bedeutet es, dass es an der Zeit ist, darüber zu sprechen, was DevOps im Jahr 2018 ist.
Wer glaubt, dass DevOps im Jahr 2018 bereits ein Beruf ist? Es gibt solche. Sind DevOps-Ingenieure im Raum, deren Stellenbeschreibung „DevOps-Ingenieur“ lautet? Sind DevOps-Manager im Raum? So etwas gibt es nicht. DevOps-Architekten? Auch nicht. Nicht genug. Stimmt es wirklich, dass niemand sagt, dass er ein DevOps-Ingenieur ist?
Die meisten von Ihnen denken also, dass dies ein Anti-Muster ist? Dass es einen solchen Beruf nicht geben sollte? Wir können denken, was wir wollen, aber während wir nachdenken, schreitet die Branche feierlich zum Klang der DevOps-Posaune voran.
Wer hat schon einmal von einem neuen Thema namens DevDevOps gehört? Dies ist eine neue Technik, die eine effektive Zusammenarbeit zwischen Entwicklern und Entwicklern ermöglicht. Und nicht so neu. Laut Twitter haben sie bereits vor vier Jahren angefangen, darüber zu reden. Und bis jetzt wächst das Interesse daran immer weiter, das heißt, es gibt ein Problem. Das Problem muss gelöst werden.
Wir sind kreative Menschen, wir ruhen uns nicht einfach aus. Wir sagen: DevOps ist kein umfassend genuger Begriff, es fehlen noch allerlei unterschiedliche, interessante Elemente. Und wir gehen in unsere Geheimlabore und beginnen, interessante Mutationen zu produzieren: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Die Logik ist eisern, oder? Unser Liefersystem funktioniert nicht, unsere Systeme sind instabil und unsere Benutzer sind unzufrieden, wir haben keine Zeit, Software rechtzeitig auszurollen, wir passen nicht in das Budget. Wie werden wir das alles lösen? Wir lassen uns ein neues Wort einfallen! Es endet mit „Ops“ und das Problem ist gelöst.
Deshalb nenne ich diesen Ansatz „Ops, und das Problem ist gelöst.“
Das alles tritt in den Hintergrund, wenn wir uns daran erinnern, warum wir uns das alles ausgedacht haben. Wir haben uns diese ganze DevOps-Sache ausgedacht, um die Softwarebereitstellung und unsere eigene Arbeit in diesem Prozess so ungehindert, schmerzlos, effizient und vor allem angenehm wie möglich zu gestalten.
DevOps ist aus Schmerz entstanden. Und wir haben das Leiden satt. Und damit das alles gelingt, setzen wir auf immergrüne Praktiken: effektive Zusammenarbeit, Flow-Praktiken und vor allem Systemdenken, denn ohne es funktioniert kein DevOps.
Was ist ein System?
Und wenn wir bereits über Systemdenken sprechen, erinnern wir uns daran, was ein System ist.
Wenn Sie ein revolutionärer Hacker sind, dann ist das System für Sie eindeutig böse. Es ist eine Wolke, die über dir hängt und dich dazu zwingt, Dinge zu tun, die du nicht tun willst.
Aus Sicht des Systemdenkens ist ein System ein Ganzes, das aus Teilen besteht. In diesem Sinne ist jeder von uns ein System. Die Organisationen, in denen wir arbeiten, sind Systeme. Und was Sie und ich aufbauen, nennt man System.
All dies ist Teil eines großen soziotechnologischen Systems. Und nur wenn wir verstehen, wie dieses sozio-technologische System zusammenwirkt, können wir in dieser Angelegenheit wirklich etwas optimieren.
Aus systemischer Sicht hat ein System verschiedene interessante Eigenschaften. Erstens besteht es aus Teilen, was bedeutet, dass sein Verhalten vom Verhalten der Teile abhängt. Darüber hinaus sind alle seine Teile auch voneinander abhängig. Es stellt sich heraus, dass es umso schwieriger ist, sein Verhalten zu verstehen oder vorherzusagen, je mehr Teile ein System hat.
Aus verhaltenstechnischer Sicht gibt es noch eine weitere interessante Tatsache. Das System kann etwas, was keines seiner einzelnen Teile kann.
Wie Dr. Russell Ackoff (einer der Begründer des Systemdenkens) sagte, lässt sich dies ganz einfach mit einem Gedankenexperiment beweisen. Wer im Raum weiß zum Beispiel, wie man Code schreibt? Es gibt viele Hände, und das ist normal, denn das ist eine der Hauptvoraussetzungen für unseren Beruf. Können Sie schreiben, aber können Ihre Hände getrennt von Ihnen Code schreiben? Es gibt Leute, die sagen: „Es sind nicht meine Hände, die den Code schreiben, sondern mein Gehirn, das den Code schreibt.“ Kann Ihr Gehirn getrennt von Ihnen Code schreiben? Nun ja, wahrscheinlich nicht.
Das Gehirn ist eine erstaunliche Maschine, wir wissen nicht einmal 10 %, wie es dort funktioniert, aber es kann nicht getrennt von dem System, das unser Körper ist, funktionieren. Und das lässt sich leicht beweisen: Öffnen Sie Ihren Schädel, nehmen Sie Ihr Gehirn heraus, legen Sie es vor den Computer und lassen Sie ihn versuchen, etwas Einfaches zu schreiben. „Hallo Welt“ in Python zum Beispiel.
Wenn ein System etwas tun kann, was keiner seiner Teile einzeln kann, dann bedeutet dies, dass sein Verhalten nicht durch das Verhalten seiner Teile bestimmt wird. Wodurch wird es dann bestimmt? Sie wird durch das Zusammenspiel dieser Teile bestimmt. Und je mehr Teile, je komplexer die Wechselwirkungen, desto schwieriger ist es, das Verhalten des Systems zu verstehen und vorherzusagen. Und das macht ein solches System chaotisch, denn jede noch so unbedeutende, unsichtbare Veränderung in irgendeinem Teil des Systems kann zu völlig unvorhersehbaren Ergebnissen führen.
Diese Empfindlichkeit gegenüber Anfangsbedingungen wurde erstmals vom amerikanischen Meteorologen Ed Lorenz entdeckt und untersucht. Später wurde er „Schmetterlingseffekt“ genannt und führte zur Entwicklung einer wissenschaftlichen Denkrichtung namens „Chaostheorie“. Diese Theorie wurde zu einem der größten Paradigmenwechsel in der Wissenschaft des 20. Jahrhunderts.
Chaostheorie
Menschen, die sich mit Chaos befassen, nennen sich selbst Chaosologen.
Eigentlich liegt der Grund für diesen Bericht darin, dass mir durch die Arbeit mit komplexen verteilten Systemen und großen internationalen Organisationen irgendwann klar wurde, dass ich mich so fühle. Ich bin Chaosologe. Das ist im Grunde eine kluge Art zu sagen: „Ich verstehe nicht, was hier vor sich geht, und ich weiß nicht, was ich dagegen tun soll.“
Ich denke, dass es vielen von Ihnen auch oft so geht, Sie sind also auch Chaosologen. Ich lade Sie in die Gilde der Chaosologen ein. Die Systeme, die Sie und ich, liebe Chaosologenkollegen, untersuchen werden, werden „komplexe adaptive Systeme“ genannt.
Was ist Anpassungsfähigkeit? Anpassungsfähigkeit bedeutet, dass sich das individuelle und kollektive Verhalten von Teilen in einem solchen adaptiven System verändert und selbstorganisiert und auf Ereignisse oder Ketten von Mikroereignissen im System reagiert. Das heißt, das System passt sich durch Selbstorganisation an Veränderungen an. Und diese Fähigkeit zur Selbstorganisation basiert auf der freiwilligen, völlig dezentralen Zusammenarbeit freier autonomer Akteure.
Eine weitere interessante Eigenschaft solcher Systeme ist, dass sie frei skalierbar sind. Was uns als Chaosologen-Ingenieure zweifellos interessieren sollte. Wenn wir also sagen würden, dass das Verhalten eines komplexen Systems durch die Interaktion seiner Teile bestimmt wird, was sollte uns dann interessieren? Interaktion.
Es gibt zwei weitere interessante Erkenntnisse.
Erstens verstehen wir, dass ein komplexes System nicht durch Vereinfachung seiner Teile vereinfacht werden kann. Zweitens besteht die einzige Möglichkeit, ein komplexes System zu vereinfachen, darin, die Interaktionen zwischen seinen Teilen zu vereinfachen.
Wie interagieren wir? Sie und ich sind alle Teile eines großen Informationssystems namens menschliche Gesellschaft. Wir interagieren über eine gemeinsame Sprache, wenn wir sie haben, wenn wir sie finden.
Aber die Sprache selbst ist ein komplexes adaptives System. Um effizienter und einfacher zu interagieren, müssen wir daher Protokolle erstellen. Das heißt, eine Abfolge von Symbolen und Aktionen, die den Informationsaustausch zwischen uns einfacher, vorhersehbarer und verständlicher macht.
Ich möchte sagen, dass Trends zur Komplexität, zur Anpassungsfähigkeit, zur Dezentralisierung, zum Chaos in allem erkennbar sind. Und in den Systemen, die Sie und ich aufbauen, und in den Systemen, von denen wir ein Teil sind.
Und um nicht unbegründet zu sein: Schauen wir uns an, wie sich die Systeme, die wir schaffen, verändern.
Du hast auf dieses Wort gewartet, das verstehe ich. Wir sind auf einer DevOps-Konferenz, heute wird dieses Wort etwa hunderttausend Mal gehört und dann werden wir nachts davon träumen.
Microservices sind die erste Softwarearchitektur, die als Reaktion auf DevOps-Praktiken entstanden ist und darauf abzielt, unsere Systeme flexibler und skalierbarer zu machen und eine kontinuierliche Bereitstellung sicherzustellen. Wie macht sie das? Durch die Reduzierung des Servicevolumens, die Reduzierung des Umfangs der von diesen Services bearbeiteten Probleme und die Verkürzung der Lieferzeiten. Das heißt, wir verkleinern und vereinfachen Teile des Systems, erhöhen ihre Zahl und dementsprechend nimmt die Komplexität der Wechselwirkungen zwischen diesen Teilen unweigerlich zu, d. h. es entstehen neue Probleme, die wir lösen müssen.
Microservices sind nicht das Ende, Microservices sind im Allgemeinen schon gestern, denn Serverless kommt. Alle Server sind abgebrannt, keine Server, keine Betriebssysteme, nur reiner ausführbarer Code. Konfigurationen sind getrennt, Zustände sind getrennt, alles wird durch Ereignisse gesteuert. Schönheit, Sauberkeit, Stille, keine Ereignisse, nichts passiert, völlige Ordnung.
Wo ist die Komplexität? Die Schwierigkeit liegt natürlich in den Interaktionen. Wie viel kann eine Funktion allein leisten? Wie interagiert es mit anderen Funktionen? Nachrichtenwarteschlangen, Datenbanken, Balancer. Wie kann ein Ereignis neu erstellt werden, wenn ein Fehler aufgetreten ist? Viele Fragen und wenige Antworten.
Microservices und Serverless nennen wir Geek-Hipster Cloud Native. Es dreht sich alles um die Cloud. Allerdings ist die Skalierbarkeit der Cloud naturgemäß auch begrenzt. Wir sind es gewohnt, es als verteiltes System zu betrachten. Wo befinden sich eigentlich die Server der Cloud-Anbieter? In Rechenzentren. Das heißt, wir haben hier eine Art zentralisiertes, sehr begrenztes, verteiltes Modell.
Heute verstehen wir, dass das Internet der Dinge nicht mehr nur aus großen Worten besteht, sondern dass uns selbst nach bescheidenen Prognosen in den nächsten fünf bis zehn Jahren Milliarden von Geräten erwarten, die mit dem Internet verbunden sind. Eine riesige Menge nützlicher und nutzloser Daten, die in der Cloud zusammengeführt und aus der Cloud hochgeladen werden.
Die Cloud wird nicht von Dauer sein, daher sprechen wir zunehmend über etwas, das Edge Computing genannt wird. Oder ich mag auch die wunderbare Definition von „Fog Computing“. Es ist eingehüllt in die Mystik der Romantik und des Mysteriums.
Nebelrechnen. Der Punkt ist, dass Wolken zentralisierte Ansammlungen aus Wasser, Dampf, Eis und Steinen sind. Und Nebel sind Wassertröpfchen, die in der Atmosphäre um uns herum verstreut sind.
Im Nebelparadigma wird die meiste Arbeit von diesen Tröpfchen völlig autonom oder in Zusammenarbeit mit anderen Tröpfchen erledigt. Und sie wenden sich nur dann der Cloud zu, wenn sie wirklich unter Druck stehen.
Das heißt wiederum Dezentralisierung, Autonomie, und natürlich verstehen viele von Ihnen bereits, wohin das alles führt, denn man kann nicht über Dezentralisierung sprechen, ohne die Blockchain zu erwähnen.
Es gibt diejenigen, die glauben, dass dies diejenigen sind, die in Kryptowährungen investiert haben. Es gibt diejenigen, die glauben, aber Angst haben, wie ich zum Beispiel. Und es gibt diejenigen, die nicht glauben. Hier kann man anders behandeln. Es gibt Technologie, eine neue unbekannte Materie, es gibt Probleme. Wie jede neue Technologie wirft sie mehr Fragen auf, als sie beantwortet.
Der Hype um Blockchain ist verständlich. Abgesehen vom Goldrausch verspricht die Technologie selbst bemerkenswerte Aussichten auf eine bessere Zukunft: mehr Freiheit, mehr Autonomie, verteiltes globales Vertrauen. Was gibt es nicht zu wollen?
Dementsprechend beginnen weltweit immer mehr Ingenieure mit der Entwicklung dezentraler Anwendungen. Und das ist eine Macht, die man nicht abtun kann, indem man einfach sagt: „Ahh, Blockchain ist nur eine schlecht implementierte verteilte Datenbank.“ Oder wie Skeptiker gerne sagen: „Es gibt keine echten Anwendungen für Blockchain.“ Wenn Sie darüber nachdenken, sagte man vor 150 Jahren dasselbe über Elektrizität. Und in mancher Hinsicht hatten sie sogar Recht, denn was Elektrizität heute ermöglicht, war im 19. Jahrhundert noch gar nicht möglich.
Wer weiß übrigens, was für ein Logo auf dem Bildschirm zu sehen ist? Das ist Hyperledger. Dabei handelt es sich um ein Projekt, das unter der Schirmherrschaft der Linux Foundation entwickelt wird und eine Reihe von Blockchain-Technologien umfasst. Das ist wirklich die Stärke unserer Open-Source-Community.
Chaos-Engineering
Das System, das wir entwickeln, wird also immer komplexer, immer chaotischer und immer anpassungsfähiger. Netflix ist Pionier von Microservice-Systemen. Sie gehörten zu den ersten, die dies verstanden, und entwickelten eine Reihe von Werkzeugen, die sie Simian Army nannten. Das berühmteste davon war . Er definierte, was als bekannt wurde .
Übrigens haben wir diesen Text während der Arbeit an dem Bericht sogar ins Russische übersetzt, also gehen Sie zu , lesen, kommentieren, schimpfen.
Kurz gesagt sagen die Prinzipien des Chaos Engineering Folgendes aus. Komplexe verteilte Systeme sind von Natur aus unvorhersehbar und von Natur aus fehlerhaft. Fehler sind unvermeidlich, das heißt, wir müssen diese Fehler akzeptieren und ganz anders mit diesen Systemen arbeiten.
Wir selbst müssen versuchen, diese Fehler in unsere Produktionssysteme einzuführen, um unsere Systeme auf dieselbe Anpassungsfähigkeit, genau diese Fähigkeit zur Selbstorganisation, zum Überleben zu testen.
Und das verändert alles. Nicht nur, wie wir Systeme in die Produktion bringen, sondern auch, wie wir sie entwickeln und wie wir sie testen. Es gibt keinen Prozess der Stabilisierung oder des Einfrierens des Codes; im Gegenteil, es findet ein ständiger Prozess der Destabilisierung statt. Wir versuchen, das System zu töten und dafür zu sorgen, dass es weiterhin überlebt.
Verteilte Systemintegrationsprotokolle
Dementsprechend erfordert dies, dass sich unsere Systeme irgendwie ändern. Damit sie stabiler werden, benötigen sie einige neue Protokolle für die Interaktion zwischen ihren Teilen. Damit sich diese Teile einigen können und zu einer Art Selbstorganisation kommen. Und es entstehen allerlei neue Werkzeuge, neue Protokolle, die ich „Protokolle für die Interaktion verteilter Systeme“ nenne.
Worüber rede ich? Zuerst das Projekt . Einige versuchen, ein allgemeines verteiltes Tracking-Protokoll zu erstellen, das ein absolut unverzichtbares Werkzeug zum Debuggen komplexer verteilter Systeme ist.
Des Weiteren - . Wir sagen, dass wir nicht vorhersagen können, was mit dem System passieren wird, das heißt, wir müssen seine Beobachtbarkeit und Beobachtbarkeit erhöhen. Opentracing gehört zu einer Familie von Tools, die unseren Systemen Beobachtbarkeit verleihen. Aber wir brauchen Beobachtbarkeit, um festzustellen, ob sich das System so verhält, wie wir es erwarten oder nicht. Wie definieren wir erwartetes Verhalten? Durch die Definition einer Art Richtlinie, eines Regelwerks. Das Open Policy Agent-Projekt arbeitet daran, diesen Regelsatz in einem Spektrum zu definieren, das vom Zugriff bis zur Ressourcenzuteilung reicht.
Wie gesagt, unsere Systeme sind zunehmend ereignisgesteuert. Serverlos ist ein großartiges Beispiel für ereignisgesteuerte Systeme. Damit wir Ereignisse zwischen Systemen übertragen und verfolgen können, benötigen wir eine gemeinsame Sprache, ein gemeinsames Protokoll dafür, wie wir über Ereignisse sprechen und wie wir sie einander übermitteln. So hieß ein Projekt .
Der ständige Strom von Änderungen, der unsere Systeme erfasst und sie ständig destabilisiert, ist ein kontinuierlicher Strom von Software-Artefakten. Damit wir diesen ständigen Änderungsfluss aufrechterhalten können, benötigen wir eine Art gemeinsames Protokoll, über das wir darüber sprechen können, was ein Software-Artefakt ist, wie es getestet wird und welche Überprüfung es bestanden hat. So hieß ein Projekt . Das ist ein gemeinsames Metadatenprotokoll für Softwareartefakte.
Und wenn wir schließlich wollen, dass unsere Systeme völlig unabhängig, anpassungsfähig und selbstorganisiert sind, müssen wir ihnen das Recht auf Selbstidentifikation einräumen. Projekt aufgerufen Genau das tut er. Dies ist auch ein Projekt unter der Schirmherrschaft der Cloud Native Computing Foundation.
Alle diese Projekte sind jung, sie alle brauchen unsere Liebe, unsere Bestätigung. Das ist alles Open Source, unsere Tests, unsere Implementierung. Sie zeigen uns, wohin die Technologie geht.
Aber bei DevOps ging es nie in erster Linie um Technologie, sondern immer um die Zusammenarbeit zwischen Menschen. Und wenn wir wollen, dass sich die Systeme, die wir entwickeln, ändern, müssen wir uns dementsprechend auch selbst ändern. Tatsächlich verändern wir uns sowieso; wir haben keine große Wahl.
Es gibt ein wunderbares Die britische Autorin Rachel Botsman schreibt über die Entwicklung des Vertrauens im Laufe der Menschheitsgeschichte. Sie sagt, dass Vertrauen in primitiven Gesellschaften ursprünglich lokal war, das heißt, wir vertrauten nur denen, die wir persönlich kannten.
Dann gab es eine sehr lange Zeit – eine dunkle Zeit, in der das Vertrauen zentralisiert wurde, in der wir begannen, Menschen zu vertrauen, die wir nicht kennen, auf der Grundlage der Tatsache, dass wir derselben öffentlichen oder staatlichen Institution angehören.
Und das sehen wir in unserer modernen Welt: Vertrauen wird immer verteilter und dezentralisierter und basiert auf der Freiheit des Informationsflusses, auf der Verfügbarkeit von Informationen.
Wenn Sie darüber nachdenken, ist genau diese Zugänglichkeit, die dieses Vertrauen ermöglicht, das, was Sie und ich umsetzen. Das bedeutet, dass sich sowohl die Art und Weise, wie wir zusammenarbeiten, als auch die Art und Weise, wie wir es tun, ändern muss, da die zentralisierten, hierarchischen IT-Organisationen von früher nicht mehr funktionieren. Sie beginnen abzusterben.
Grundlagen der DevOps-Organisation
Die ideale DevOps-Organisation der Zukunft ist ein dezentrales, adaptives System bestehend aus autonomen Teams, die jeweils aus autonomen Einzelpersonen bestehen. Diese Teams sind über die ganze Welt verstreut und arbeiten mithilfe asynchroner Kommunikation und hochtransparenter Kommunikationsprotokolle effektiv zusammen. Sehr schön, nicht wahr? Eine sehr schöne Zukunft.
Ohne Kulturwandel ist das alles natürlich nicht möglich. Wir brauchen transformative Führung, persönliche Verantwortung und interne Motivation.
Dies ist die Grundlage von DevOps-Organisationen: Informationstransparenz, asynchrone Kommunikation, transformationale Führung, Dezentralisierung.
Burnout
Die Systeme, denen wir angehören und die wir aufbauen, werden zunehmend chaotischer, und es fällt uns Menschen schwer, mit diesem Gedanken klarzukommen, es ist schwierig, die Illusion der Kontrolle aufzugeben. Wir versuchen, sie weiterhin zu kontrollieren, was oft zum Burnout führt. Ich sage das aus eigener Erfahrung, ich habe mich auch verbrannt, ich wurde auch durch unvorhergesehene Ausfälle in der Produktion behindert.
Burnout tritt auf, wenn wir versuchen, etwas zu kontrollieren, das von Natur aus unkontrollierbar ist. Wenn wir ausbrennen, verliert alles seinen Sinn, weil wir den Wunsch verlieren, etwas Neues zu tun, wir werden defensiv und beginnen, das zu verteidigen, was wir haben.
Der Ingenieursberuf ist, das erinnere ich mich oft gerne, in erster Linie ein kreativer Beruf. Wenn wir die Lust verlieren, etwas zu erschaffen, dann werden wir zu Asche, zu Asche. Menschen brennen aus, ganze Organisationen brennen aus.
Meiner Meinung nach hilft uns nur die Annahme der schöpferischen Kraft des Chaos, nur der Aufbau einer Zusammenarbeit nach seinen Grundsätzen, das Gute in unserem Beruf nicht zu verlieren.
Das wünsche ich Ihnen: Lieben Sie Ihren Job, lieben Sie, was wir tun. Diese Welt ernährt sich von Informationen, wir haben die Ehre, sie zu ernähren. Also lasst uns das Chaos studieren, lasst uns Chaosologen sein, lasst uns Wert schaffen, etwas Neues schaffen, nun ja, Probleme sind, wie wir bereits herausgefunden haben, unvermeidlich, und wenn sie auftauchen, sagen wir einfach „Ops!“ und das Problem ist gelöst.
Was anderes als Chaos Monkey?
Tatsächlich sind alle diese Instrumente so jung. Dieselben Tools hat Netflix für sich selbst entwickelt. Bauen Sie Ihre eigenen Werkzeuge. Lesen Sie die Prinzipien des Chaos Engineering und leben Sie nach diesen Prinzipien, anstatt zu versuchen, andere Werkzeuge zu finden, die jemand anderes bereits gebaut hat.
Versuchen Sie zu verstehen, wie Ihre Systeme zusammenbrechen, beginnen Sie mit dem Zusammenbruch und sehen Sie, wie sie sich halten. Das kommt zuerst. Und Sie können nach Werkzeugen suchen. Es gibt alle Arten von Projekten.
Ich habe den Moment nicht ganz verstanden, als Sie sagten, dass das System nicht durch die Vereinfachung seiner Komponenten vereinfacht werden kann, und bin sofort zu Microservices übergegangen, die das System vereinfachen, indem sie die Komponenten selbst vereinfachen und die Interaktionen komplizieren. Dabei handelt es sich im Wesentlichen um zwei Teile, die einander widersprechen.
Stimmt, Microservices sind generell ein sehr kontroverses Thema. Tatsächlich erhöht die Vereinfachung von Teilen die Flexibilität. Was bieten Microservices? Sie geben uns Flexibilität und Schnelligkeit, aber keineswegs Einfachheit. Sie erhöhen den Schwierigkeitsgrad.
In der DevOps-Philosophie sind Microservices also keine so gute Sache?
Jedes Gut hat eine Rückseite. Der Vorteil besteht darin, dass es die Flexibilität erhöht und es uns ermöglicht, Änderungen schneller vorzunehmen, aber es erhöht die Komplexität und damit die Fragilität des gesamten Systems.
Doch worauf liegt mehr Wert: auf die Vereinfachung der Interaktion oder auf die Vereinfachung von Teilen?
Der Schwerpunkt liegt natürlich auf der Vereinfachung der Interaktionen, denn wenn wir dies aus der Sicht der Zusammenarbeit mit Ihnen betrachten, müssen wir zunächst auf die Vereinfachung der Interaktionen achten und nicht auf die Vereinfachung der Arbeit von jedem von uns einzeln. Denn die Arbeit zu vereinfachen bedeutet, sich in Roboter zu verwandeln. Hier bei McDonald's funktioniert es ganz normal, wenn man eine Anleitung hat: Hier legt man den Burger hin, hier gießt man die Soße darüber. Das funktioniert in unserer kreativen Arbeit überhaupt nicht.
Stimmt es, dass alles, was Sie gesagt haben, in einer Welt ohne Konkurrenz lebt und dass das Chaos dort so freundlich ist und dass es in diesem Chaos keine Widersprüche gibt, dass niemand jemanden essen oder töten möchte? Wie sollen sich Wettbewerb und DevOps schlagen?
Nun, es kommt darauf an, um welche Art von Wettbewerb es sich handelt. Geht es um Konkurrenz am Arbeitsplatz oder um Konkurrenz zwischen Unternehmen?
Über den Wettbewerb von Dienstleistungen, der existiert, weil Dienstleistungen nicht aus mehreren Unternehmen bestehen. Wir schaffen eine neue Art von Informationsumgebung, und jede Umgebung kann ohne Konkurrenz nicht leben. Überall herrscht Konkurrenz.
Das gleiche Netflix, wir nehmen sie als Vorbild. Warum sind sie darauf gekommen? Weil sie wettbewerbsfähig sein mussten. Diese Flexibilität und Bewegungsgeschwindigkeit ist genau die Wettbewerbsanforderung; sie führt zu Chaos in unseren Systemen. Das heißt, Chaos ist nicht etwas, was wir bewusst tun, weil wir es wollen, sondern etwas, das geschieht, weil die Welt es verlangt. Wir müssen uns einfach anpassen. Und Chaos ist genau das Ergebnis des Wettbewerbs.
Bedeutet das, dass Chaos sozusagen das Fehlen von Zielen ist? Oder jene Ziele, die wir nicht sehen wollen? Wir sind im Haus und verstehen die Ziele anderer nicht. Tatsächlich entsteht Wettbewerb dadurch, dass wir klare Ziele haben und wissen, wo wir im nächsten Moment landen werden. Das ist aus meiner Sicht die Essenz von DevOps.
Schauen Sie sich auch die Frage an. Ich denke, wir haben alle das gleiche Ziel: zu überleben und es zu schaffen
größtes Vergnügen. Und das Wettbewerbsziel jeder Organisation ist dasselbe. Überleben gelingt oft durch Konkurrenz, man kann nichts dagegen tun.
Die diesjährige Konferenz findet am 7. Dezember im Technopolis statt. Bewerbungen für Gutachten nehmen wir bis zum 11. November entgegen. uns, wenn Sie sprechen möchten.
Die Anmeldung für Teilnehmer ist offen, Tickets kosten 7000 Rubel. Begleiten Sie uns!
Source: habr.com