DevOps und Chaos: Softwarebereitstellung in einer dezentralen Welt

Der Gründer und Direktor von Otomato Software, einer der Initiatoren und Ausbilder von Israels erster DevOps-Zertifizierung, Anton Weiss, sprach letztes Jahr bei DevOpsDays Moskau über Chaostheorie und die Hauptprinzipien des chaotischen Engineerings und erklärte auch, wie die ideale DevOps-Organisation der Zukunft funktioniert.

Wir haben eine Textversion des Berichts vorbereitet.



Guten Morgen!

DevOpsDays in Moskau zum zweiten Mal in Folge, ich bin das zweite Mal auf dieser Bühne, viele von Ihnen sind das zweite Mal in diesem Raum. Was bedeutet das? Dies bedeutet, dass die DevOps-Bewegung in Russland wächst, sich vervielfacht und vor allem, dass es Zeit ist, darüber zu sprechen, was DevOps im Jahr 2018 ist.

Heben Sie Ihre Hände diejenigen, die denken, dass DevOps im Jahr 2018 bereits ein Beruf ist? Es gibt einige. Befinden sich DevOps-Ingenieure im Raum, in deren Stellenbeschreibung „DevOps-Ingenieur“ steht? Befinden sich DevOps-Manager im Raum? Es gibt keine. DevOps Architekten? Auch nicht. Nicht genug. Was hat eigentlich niemand geschrieben, dass er ein DevOps-Ingenieur ist?

Die meisten von Ihnen denken also, dass dies ein Antimuster ist? Was sollte ein solcher Beruf nicht sein? Wir können alles denken, aber im Moment denken wir, dass sich die Branche feierlich den Klängen der DevOps-Pipe nähert.

Wer hat von einem neuen Thema namens DevDevOps gehört? Dies ist eine solche neue Technik, die eine effektive Zusammenarbeit zwischen Entwicklern und Entwicklern ermöglicht. Und nicht so neu. Nach Twitter zu urteilen, haben sie vor 4 Jahren angefangen, darüber zu reden. Und das Interesse daran wächst und wächst, das heißt, es gibt ein Problem. Das Problem muss gelöst werden.



Wir sind kreative Menschen, also beruhigen Sie sich einfach nicht. Wir sagen: DevOps ist kein umfassendes Wort, es gibt immer noch nicht genug verschiedene, interessante Elemente. Und wir gehen in unsere geheimen Labors und beginnen interessante Mutationen zu produzieren: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.



Die Logik ist Eisen, richtig? Unser Liefersystem funktioniert nicht, unsere Systeme sind instabil und die Benutzer sind unzufrieden. Wir haben keine Zeit, die Software rechtzeitig einzuführen. Wir passen nicht zum Budget. Wie werden wir das alles lösen? Wir werden uns ein neues Wort einfallen lassen! Es endet in Ops und das Problem ist behoben.

Ich nenne diesen Ansatz "Ops, und das Problem ist gelöst."

Dies alles tritt in den Hintergrund, wenn wir uns daran erinnern, warum wir uns das alles ausgedacht haben. Wir haben uns all diese DevOps ausgedacht, um die Softwarebereitstellung und unsere eigene Arbeit in diesem Prozess ungehindert, schmerzlos, effektiv und vor allem unterhaltsam zu gestalten.

DevOps ist aus Schmerzen gewachsen. Und wir haben es satt zu leiden. Um dies zu erreichen, verlassen wir uns auf immergrüne Praktiken: effektive Zusammenarbeit, Flusspraktiken und vor allem systemisches Denken, denn ohne sie funktioniert kein DevOps.

Was ist ein System?

Und wenn wir bereits über systemisches Denken sprechen, erinnern wir uns daran, was ein System ist.



Wenn Sie ein revolutionärer Hacker sind, dann ist das System für Sie ein klares Übel. Dies ist eine Wolke, die über Ihnen hängt und Sie dazu bringt, das zu tun, was Sie nicht wollen.



Aus Sicht des systemischen Denkens ist ein System ein Ganzes, das aus Teilen besteht. In diesem Sinne ist jeder von uns ein System. Die Organisationen, für die wir arbeiten, sind Systeme. Und was wir bauen, heißt es - das System.

All dies ist Teil eines großen soziotechnologischen Systems. Und nur wenn wir verstehen, wie dieses soziotechnologische System zusammenarbeitet, können wir in dieser Angelegenheit wirklich etwas optimieren.

Aus Sicht des systemischen Denkens 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 auch alle seine Teile voneinander abhängig. Es stellt sich heraus, dass es umso schwieriger ist, sein Verhalten zu verstehen oder vorherzusagen, je mehr Teile das System hat.

In Bezug auf das Verhalten gibt es eine weitere interessante Tatsache. Das System kann etwas tun, was keiner seiner Einzelteile kann.

Wie Dr. Russell Akoff (einer der Begründer des systemischen Denkens) sagte, ist dies leicht genug, um mit Hilfe eines Gedankenexperiments zu beweisen. Wer im Publikum kann zum Beispiel Code schreiben? Viele Hände, und das ist normal, denn dies ist eine der Grundvoraussetzungen für unseren Beruf. Können Sie schreiben und Ihre Hände können Code getrennt von Ihnen schreiben? Es gibt Leute, die sagen: "Meine Hände schreiben keinen Code, mein Gehirn schreibt Code." Kann das Gehirn Code getrennt von Ihnen schreiben? Nun, höchstwahrscheinlich nicht.

Das Gehirn ist eine erstaunliche Maschine, 10% von uns wissen nicht, wie es dort funktioniert, aber es kann nicht getrennt von dem System funktionieren, das unser Körper ist. Und das ist leicht zu beweisen: Öffnen Sie Ihre Schädelbox, holen Sie Ihr Gehirn heraus, stellen Sie sie vor den Computer und lassen Sie sie versuchen, etwas Einfaches zu schreiben. "Hallo Welt" zum Beispiel in Python.

Wenn ein System etwas kann, was keiner seiner Teile einzeln kann, bedeutet dies, dass sein Verhalten nicht durch das Verhalten seiner Teile bestimmt wird. Und womit wird es dann bestimmt? Es wird durch die Wechselwirkung zwischen diesen Teilen bestimmt. Und je mehr Teile, desto schwieriger die Interaktion, desto schwieriger ist es, das Verhalten des Systems zu verstehen und vorherzusagen. Und dies macht ein solches System chaotisch, weil jede kleinste, für das Auge unsichtbare Veränderung in einem Teil des Systems zu völlig unvorhersehbaren Ergebnissen führen kann.

Diese Empfindlichkeit gegenüber Anfangsbedingungen wurde zuerst vom amerikanischen Meteorologen Ed Lorenz entdeckt und untersucht. In der Folge wurde es als "Schmetterlingseffekt" bezeichnet und führte zur Entwicklung einer solchen Bewegung des wissenschaftlichen Denkens, der "Chaostheorie". Diese Theorie ist zu einem der wichtigsten Paradigmenwechsel in der Wissenschaft des 20. Jahrhunderts geworden.

Chaostheorie

Menschen, die Chaos studieren, nennen sich Chaosologen.



Der Grund für diesen Bericht war, dass ich bei der Arbeit mit komplexen verteilten Systemen und großen internationalen Organisationen irgendwann merkte, dass ich mich so fühle. Ich bin ein Chaosologe. Dies ist im Allgemeinen eine so geniale Art zu sagen: "Ich verstehe nicht, was hier passiert, und ich weiß nicht, was ich damit anfangen soll."

Ich denke, dass viele von Ihnen sich auch so oft fühlen, also sind Sie auch Chaosologen. Ich lade Sie in die Gilde der Chaosologen ein. Die Systeme, die wir, liebe Kollegen von Chaosologen, 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 ändert und selbst organisiert 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, vollständig dezentralen Zusammenarbeit freier autonomer Akteure.

Eine weitere interessante Eigenschaft solcher Systeme ist, dass sie frei skalierbar sind. Dass wir als Chaosologen-Ingenieure zweifellos von Interesse sein sollten. Wenn wir also sagen, dass das Verhalten eines komplexen Systems durch das Zusammenspiel seiner Teile bestimmt wird, was sollte uns dann interessieren? Interaktion.

Es gibt zwei weitere interessante Schlussfolgerungen.


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 Wechselwirkungen zwischen seinen Teilen zu vereinfachen.

Wie interagieren wir? Wir sind alle Teil eines großen Informationssystems, das als menschliche Gesellschaft bezeichnet wird. Wir interagieren durch eine gemeinsame Sprache, wenn wir sie haben, wenn wir sie finden.



Die Sprache selbst ist jedoch ein komplexes adaptives System. Dementsprechend müssen wir eine Art Protokoll erstellen, um effizienter und einfacher zu interagieren. Das heißt, eine Folge von Symbolen und Aktionen, die den Informationsaustausch zwischen uns einfacher, vorhersehbarer und verständlicher machen.

Ich möchte sagen, dass die Tendenzen zur Komplikation, zur Anpassungsfähigkeit, zur Dezentralisierung, zur Zufälligkeit in allem verfolgt werden. Und in jenen Systemen, die wir bauen, und in jenen Systemen, zu denen wir gehören.

Und um nicht unbegründet zu sein, schauen wir uns an, wie sich die von uns erstellten Systeme ändern.



Sie haben auf dieses Wort gewartet, ich verstehe. Wir sind auf der DevOps-Konferenz, heute wird dieses Wort irgendwo hunderttausend Mal klingen und dann werden wir nachts träumen.

Microservices ist die erste Softwarearchitektur, die als Reaktion auf DevOps-Praktiken entstanden ist. Sie soll unsere Systeme flexibler und skalierbarer machen und eine kontinuierliche Bereitstellung gewährleisten. Wie macht sie das? Durch Reduzierung des Servicevolumens, Reduzierung der Grenzen der Probleme, die diese Services verarbeiten, Reduzierung der Lieferzeit. Das heißt, wir reduzieren, vereinfachen Teile des Systems, erhöhen ihre Anzahl und dementsprechend nimmt die Komplexität der Interaktionen zwischen diesen Teilen ständig zu, dh es entstehen neue Probleme, die Sie und ich lösen müssen.



Microservices sind nicht das Ende, Microservices sind im Allgemeinen bereits gestern, weil Serverless kommt. Alle Server sind ausgebrannt, keine Server, keine Betriebssysteme, nur sauberer ausführbarer Code. Die Konfiguration ist getrennt, der Status ist getrennt, alles ist ereignisgesteuert. Schönheit, Reinheit, Stille, keine Ereignisse, nichts passiert, vollständige Ordnung.

Wo ist die Schwierigkeit? Komplexität natürlich in Interaktionen. Wie viel kann eine Funktion alleine tun? Wie interagiert es mit anderen Funktionen? Nachrichtenwarteschlangen, Datenbanken, Balancer. Wie erstelle ich ein Ereignis neu, wenn ein Fehler auftritt? Ein paar Fragen und ein paar Antworten.

Microservices und Serverless sind alles, was wir Computer-Hipster Cloud Native nennen. Es dreht sich alles um die Cloud. Die Cloud ist aber auch im Wesentlichen skalierbar. Wir sind es gewohnt, es als verteiltes System zu betrachten. Wo leben die Cloud-Provider-Server? In Rechenzentren. Das heißt, hier haben wir ein bestimmtes zentrales, sehr begrenztes, verteiltes Modell.

Heute verstehen wir, dass das Internet der Dinge nicht mehr nur große Worte sind, die nach bescheidenen Vorhersagen in den nächsten fünf bis zehn Jahren Milliarden von mit dem Internet verbundenen Geräten auf uns warten. Eine riesige Menge nützlicher und nutzloser Daten, die in die Cloud verschmelzen und aus der Cloud fluten.

Die Cloud wird nicht stehen, daher sprechen wir zunehmend über das, was als "Peripherie-Computing" bezeichnet wird. Oder ich mag auch die wunderbare Definition von Fog Computing. Es ist zerfetzt von der Mystik der Romantik und des Mysteriums.



Misty Computing. Der Punkt ist, dass Wolken solche zentralisierten Klumpen von Wasser, Dampf, Eis, Steinen sind. Und Nebel sind Wassertropfen, die in der Atmosphäre um uns herum verstreut sind.

In einem nebligen Paradigma wird der größte Teil der Arbeit von diesen Tröpfchen völlig autonom oder in Zusammenarbeit mit anderen Tröpfchen ausgeführt. Und sie wenden sich nur dann der Wolke zu, wenn sie es wirklich tun.

Das ist wiederum Dezentralisierung, Autonomie, und natürlich verstehen viele von Ihnen bereits, worum es geht, weil Sie nicht über Dezentralisierung sprechen und die Blockchain nicht erwähnen können.



Es gibt diejenigen, die glauben, dies sind diejenigen, die in Kryptowährung investiert haben. Es gibt diejenigen, die glauben, aber Angst haben, wie ich zum Beispiel. Und es gibt diejenigen, die nicht glauben. Hier kann man sich anders beziehen. Es gibt Technologie, ein neues unverständliches Geschäft, es gibt Probleme. Wie jede neue Technologie wirft sie mehr Fragen als Antworten auf.

Der Hype um die Blockchain ist verständlich. Selbst wenn Sie den Goldrausch beiseite lassen, verspricht die Technologie selbst eine bessere Zukunft: mehr Freiheit, mehr Autonomie, verteiltes globales Vertrauen. Was gibt es nicht zu wollen?

Dementsprechend beginnen immer mehr Ingenieure auf der ganzen Welt, dezentrale Anwendungen zu entwickeln. Und dies ist eine Kraft, die nicht einfach mit den Worten abgetan werden kann: "Ahh, die Blockchain ist nur eine schlecht implementierte verteilte Datenbank." Oder wie Skeptiker gerne sagen: "Es gibt keine wirkliche Verwendung für die Blockchain." Wenn Sie darüber nachdenken, dann haben sie vor 150 Jahren dasselbe über Elektrizität gesagt. Und selbst in mancher Hinsicht hatten sie Recht, denn was Elektrizität heute im 19. Jahrhundert ermöglicht, war in keiner Weise unrealistisch.

Wer weiß übrigens, welche Art von Logo auf dem Bildschirm angezeigt wird? Das ist Hyperledger. Dies ist ein Projekt, das unter der Schirmherrschaft der Linux Foundation entwickelt wird. Es enthält eine Reihe von Blockchain-Technologien. Dies ist wirklich die Kraft unserer Open Source Community.

Chaos Engineering

Das System, das wir entwickeln, wird also komplexer, chaotischer und anpassungsfähiger. Netflix - Pioniere von Microservice-Systemen. Sie waren eine der ersten, die dies verstanden haben. Sie entwickelten ein Toolkit namens Simian Army, von dem der berühmteste Chaos Monkey war . Er definierte das, was als "Prinzipien der Chaos-Technik" bekannt wurde.

Übrigens haben wir bei der Arbeit an dem Bericht diesen Text sogar ins Russische übersetzt. Gehen Sie also zum Link , lesen Sie, kommentieren Sie, schimpfen Sie.

Kurz gesagt, die Prinzipien der Chaos-Technik weisen auf Folgendes hin. Komplexe verteilte Systeme sind von Natur aus unvorhersehbar und weisen von Natur aus Fehler auf. Fehler sind unvermeidlich, was bedeutet, dass wir diese Fehler akzeptieren und auf völlig andere Weise mit diesen Systemen arbeiten müssen.

Wir müssen selbst versuchen, diese Fehler in unsere Produktionssysteme einzuführen, um unsere Systeme auf diese Anpassungsfähigkeit, auf diese Fähigkeit zur Selbstorganisation und zum Überleben zu testen.

Und das ändert alles. Nicht nur, wie wir das System in der Produktion betreiben, sondern auch, wie wir sie entwickeln, wie wir sie testen. Es gibt keinen Stabilisierungsprozess, kein Einfrieren des Codes, im Gegenteil, es gibt einen ständigen Destabilisierungsprozess. Wir versuchen das System zu töten und sehen, dass es weiterhin überlebt.

Verteilte Systemintegrationsprotokolle

Dementsprechend müssen sich auch unsere Systeme irgendwie ändern. Um stabiler zu werden, benötigen sie einige neue Interaktionsprotokolle zwischen ihren Teilen. Damit diese Teile verhandeln und zu einer Art Selbstorganisation kommen können. Und es gibt alle möglichen neuen Tools, neue Protokolle, die ich "Protokolle für die Interaktion verteilter Systeme" nenne.



Worüber rede ich? Erstens das Opentracing- Projekt. Einige versuchen, ein gemeinsames Protokoll für die verteilte Nachverfolgung zu erstellen, das ein absolut unverzichtbares Werkzeug für das Debuggen komplexer verteilter Systeme ist.



Als nächstes kommt der Open Policy Agent . Wir sagen, dass wir nicht vorhersagen können, was mit dem System passieren wird, das heißt, wir müssen seine Beobachtbarkeit und Beobachtbarkeit verbessern. Opentracing ist eine Familie von Werkzeugen, die unseren Systemen Beobachtbarkeit verleihen. Wir brauchen jedoch Beobachtbarkeit, um festzustellen, ob sich das System so verhält, wie wir es erwarten oder nicht. Wie bestimmen wir das erwartete Verhalten? Indem Sie darin eine Art Richtlinie definieren, eine Art Regelwerk. Das Open Policy Agent-Projekt definiert diese Regeln in einem weiten Bereich: vom Zugriff bis zur Ressourcenzuweisung.



Wie gesagt, unsere Systeme sind zunehmend ereignisgesteuert. Serverless 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 darüber, wie wir über Ereignisse sprechen und wie wir sie untereinander übertragen. Dies ist ein Projekt namens Cloudevents .



Der kontinuierliche Strom von Änderungen, der unsere Systeme wäscht und sie ständig destabilisiert, ist ein kontinuierlicher Strom von Software-Artefakten. Damit wir diesen konstanten Änderungsfluss aufrechterhalten können, benötigen wir ein allgemeines Protokoll, mit dem wir darüber sprechen können, was ein Software-Artefakt ist, wie es verifiziert wird, welche Verifizierung es bestanden hat. Dies ist ein Projekt namens Grafeas . Das heißt, ein gängiges Software-Artefakt-Metadatenprotokoll.



Und wenn wir wollen, dass unsere Systeme völlig unabhängig, anpassungsfähig und selbstorganisierend sind, müssen wir ihnen das Recht auf Selbstidentifikation einräumen. Ein Projekt namens spiffe macht genau das. Dies ist auch ein Projekt, das von der Cloud Native Computing Foundation gesponsert wird.

Alle diese Projekte sind jung, sie alle brauchen unsere Liebe, unseren Test. Dies ist alles Open Source, unser Testen, unsere Implementierung. Sie zeigen uns, in welche Richtung sich die Technologie bewegt.

Bei DevOps ging es jedoch nie in erster Linie um Technologie, sondern in erster Linie um die Zusammenarbeit zwischen Menschen. Und wenn wir dementsprechend wollen, dass sich die Systeme, die wir entwickeln, ändern, müssen wir uns selbst ändern. Tatsächlich ändern wir uns bereits, wir haben keine besondere Wahl.



Es gibt ein wundervolles Buch der britischen Schriftstellerin Rachel Botsman, in dem sie über die Entwicklung des Vertrauens in der Geschichte der Menschheit schreibt. Sie sagt, dass anfangs in primitiven Gesellschaften das Vertrauen lokal war, das heißt, wir vertrauten nur denen, die wir persönlich kennen.

Dann gab es eine sehr lange Zeit - eine dunkle Zeit, in der das Vertrauen zentralisiert wurde, als wir anfingen, Menschen zu vertrauen, die wir nicht kennen, weil wir derselben öffentlichen oder staatlichen Institution angehören.

Und das sehen wir in unserer modernen Welt: Vertrauen wird immer mehr verteilt und dezentralisiert und basiert auf der Freiheit des Informationsflusses und der Verfügbarkeit von Informationen.

Wenn Sie darüber nachdenken, implementieren wir genau diese Zugänglichkeit, die dieses Vertrauen ermöglicht.Dies bedeutet, dass sich sowohl unsere Arbeitsweise als auch unsere Arbeitsweise ändern müssen, da die zentralisierten hierarchischen IT-Organisationen der alten Art nicht mehr funktionieren. Sie beginnen zu sterben.

Grundlagen der DevOps-Organisation

Die ideale DevOps-Organisation der Zukunft ist ein dezentrales, adaptives System, das aus autonomen Teams besteht, von denen jedes aus autonomen Personen besteht. Diese Teams sind auf der ganzen Welt verstreut und arbeiten mithilfe asynchroner Kommunikation und hochtransparenter Kommunikationsprotokolle effektiv zusammen. Sehr schön, oder? Eine sehr schöne Zukunft.

Natürlich ist dies alles ohne kulturellen Wandel nicht möglich. Wir müssen transformative Führung, persönliche Verantwortung und interne Motivation haben.



Dies ist die Basis von DevOps-Organisationen: Informationstransparenz, asynchrone Kommunikation, Transformationsführung, Dezentralisierung.

Burnout

Die Systeme, zu denen wir gehören, und die, die wir bauen, werden zunehmend chaotisch, und es fällt uns Menschen schwer, mit dieser Idee umzugehen und die Illusion der Kontrolle aufzugeben. Wir versuchen, sie weiterhin zu kontrollieren, was häufig zu Burnout führt. Ich sage dies aus eigener Erfahrung, ich wurde auch verbrannt, auch bei unvorhergesehenen Produktionsausfällen deaktiviert.



Burnout tritt auf, wenn wir versuchen, etwas zu kontrollieren, das im Wesentlichen nicht kontrolliert werden kann. Wenn wir ausbrennen, verliert alles seine Bedeutung, weil wir den Wunsch verlieren, etwas Neues zu tun. Wir nehmen eine Verteidigungsposition ein und beginnen zu verteidigen, was ist.

Der Ingenieurberuf ist, wie ich mich oft erinnere, in erster Linie ein kreativer Beruf. Wenn wir den Wunsch verlieren, etwas zu erschaffen, verwandeln wir uns in Asche, verwandeln uns in Asche. Menschen brennen aus, ganze Organisationen brennen aus.

Meiner Meinung nach hilft es uns, nur das Gute in unserem Beruf zu verlieren, wenn wir nur die schöpferische Kraft des Chaos akzeptieren und nur die Zusammenarbeit auf ihren Prinzipien aufbauen.

Was ich für dich will: meine Arbeit lieben, lieben, was wir tun. Diese Welt ernährt sich von Informationen, wir haben die Ehre, sie zu ernähren. Also lasst uns das Chaos studieren, wir werden Chaosologen sein, wir werden Wert schaffen, etwas Neues schaffen, gut, und die Probleme, wie wir bereits herausgefunden haben, sind unvermeidlich, und wenn sie auftreten, werden wir einfach „Ops!“ Sagen, und das Problem ist gelöst.

Was außer Chaos Monkey?

In der Tat sind all diese Werkzeuge so jung. Diese Netflix haben Tools für sich selbst erstellt. Erstellen Sie Tools für sich. Lesen Sie die Prinzipien des Chaos Engineering und halten Sie sich an diese Prinzipien. Versuchen Sie nicht, nach anderen Tools zu suchen, die bereits von anderen erstellt wurden.

Versuchen Sie zu verstehen, wie Ihre Systeme kaputt gehen, und beginnen Sie, sie kaputt zu machen, und beobachten Sie, wie sie Stößen standhalten. Dies ist in erster Linie. 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 Vereinfachung seiner Komponenten vereinfacht werden kann, und sofort zu Microservices gewechselt sind, die das System nur vereinfachen, indem sie die Komponenten selbst vereinfachen und Interaktionen komplizieren. Dies sind im Wesentlichen zwei Teile, die sich widersprechen.

Das ist richtig, Microservices sind im Allgemeinen ein sehr kontroverses Thema. In der Tat erhöht die Vereinfachung von Teilen die Flexibilität. Was geben Microservices? Sie geben uns Flexibilität und Geschwindigkeit, aber sie geben uns in keiner Weise Einfachheit. Sie erhöhen die Komplexität.

Das heißt, in der DevOps-Philosophie sind Microservices kein solcher Segen?

Jedes Gute hat eine falsche Seite. Es gibt einen Vorteil: Es erhöht die Flexibilität, gibt uns die Möglichkeit, Änderungen schneller vorzunehmen, erhöht jedoch die Komplexität und dementsprechend die Fragilität des gesamten Systems.

Worauf wird jedoch mehr Wert gelegt: Vereinfachung der Interaktion oder Vereinfachung von Teilen?

Der Schwerpunkt liegt zweifellos auf der Vereinfachung der Interaktion, denn wenn wir sie unter dem Gesichtspunkt betrachten, wie wir mit Ihnen zusammenarbeiten, müssen wir zunächst auf die Vereinfachung der Interaktion achten und nicht die Arbeit jedes Einzelnen von uns vereinfachen. Weil die Vereinfachung der Arbeit zu Robotern wird. Aber bei McDonald's funktioniert es gut, wenn es Ihnen verschrieben wird: Hier legen Sie den Burger, hier gießen Sie Sauce darauf. Dies funktioniert in unserer kreativen Arbeit überhaupt nicht.

Stimmt es, dass alles, was Sie gesagt haben, in einer Welt ohne Konkurrenz lebt und das Chaos dort so freundlich ist und es keine Widersprüche in diesem Chaos gibt, niemand essen, jemanden töten will? Wie sollen Wettbewerb und DevOps leben?

Nun, es hängt davon ab, um welche Art von Wettbewerb es sich handelt. Arbeitsplatzwettbewerb oder Wettbewerb zwischen Unternehmen?

Über den Wettbewerb der bestehenden Dienstleistungen, denn Dienstleistungen sind nicht wenige Unternehmen. Wir schaffen eine neue Art von Informationsumgebung, und jede Umgebung kann nicht ohne Konkurrenz leben. Überall herrscht Wettbewerb.

Das gleiche Netflix nehmen wir als Vorbild. Warum haben sie sich das ausgedacht? Weil sie wettbewerbsfähig sein mussten. Diese Flexibilität und Bewegungsgeschwindigkeit, genau diese sehr wettbewerbsfähige Anforderung, führt Zufälligkeit in unsere Systeme ein. Das heißt, Chaos ist nicht das, was wir bewusst tun, weil wir es wollen, es ist das, was passiert, weil die Welt es benötigt. Wir müssen uns nur anpassen. Und Chaos, es ist nur das Ergebnis des Wettbewerbs.

Bedeutet das, dass Chaos ein Mangel an Zielen ist? Oder jene Ziele, die wir nicht sehen wollen? Wir sind im Haus und verstehen die Ziele anderer nicht. Wettbewerb ist in der Tat darauf zurückzuführen, dass wir klare Ziele haben und wissen, wohin wir in jedem nächsten Moment kommen werden. Darin ist aus meiner Sicht die Essenz von DevOps.

Auch ein Blick auf die Frage. Ich denke, dass wir alle ein Ziel haben: zu überleben und es mit
größter Freude zu tun . Und das Wettbewerbsziel jeder Organisation ist das gleiche. Überleben ist oft im Wettbewerb, es gibt nichts zu tun.

Dieses Jahr findet die DevOpsDays- Konferenz in Moskau am 7. Dezember in Technopolis statt. Bis zum 11. November akzeptieren wir Bewerbungen für Berichte. Mailen Sie uns, wenn Sie sprechen möchten.

Die Registrierung für die Teilnehmer ist offen, ein Ticket kostet 7.000 Rubel. Jetzt mitmachen!