Anton Weiss, Gründer und Direktor von „Otomato Software“ sowie einer der Initiatoren und Ausbilder der ersten DevOps-Zertifizierung in Israel, sprach im vergangenen Jahr über die Chaos-Theorie und die wichtigsten Prinzipien des Chaos Engineering und erklärte, wie die ideale DevOps-Organisation der Zukunft aussieht.
Wir haben eine Textversion des Vortrags vorbereitet.
Guten Morgen!
Die DevOpsDays finden in Moskau zum zweiten Mal statt, ich stehe zum zweiten Mal auf dieser Bühne, und viele von Ihnen sind zum zweiten Mal in diesem Saal. Was bedeutet das? Das bedeutet, dass die DevOps-Bewegung in Russland wächst und sich vermehrt. Vor allem bedeutet es, dass es an der Zeit ist, darüber zu sprechen, was DevOps im Jahr 2018 wirklich ist.
Heben Sie die Hände, wer denkt, dass DevOps im Jahr 2018 bereits ein Beruf ist? Es gibt solche. Gibt es im Saal DevOps-Ingenieure, die in ihrer Stellenbeschreibung „DevOps-Ingenieur“ stehen haben? Gibt es im Saal DevOps-Manager? Solche gibt es nicht. DevOps-Architekten? Auch nicht. Das ist recht selten. Gibt es wirklich niemanden, der als DevOps-Ingenieur eingestuft ist?
Denken die meisten von Ihnen, dass das ein Anti-Muster ist? Dass es so einen Beruf nicht geben sollte? Wir können denken, was wir wollen, während die Branche feierlich unter dem Klang der DevOps-Trompeten voranschreitet.
Wer hat schon von dem neuen Konzept namens DevDevOps gehört? Es handelt sich um eine neue Methode, die eine effektive Zusammenarbeit zwischen Entwicklern und DevOps-Teams ermöglichen soll. So neu ist es allerdings nicht. Wenn man Twitter glauben darf, wurde vor 4 Jahren bereits darüber gesprochen. Und das Interesse wächst nach wie vor, was darauf hindeutet, dass es ein Problem gibt. Dieses Problem muss angegangen werden.
Wir sind kreative Menschen, die sich nicht einfach beruhigen lassen. Wir sagen: DevOps ist nicht umfassend genug, es fehlen viele interessante Elemente. Daher ziehen wir uns in unsere geheimen Labore zurück und beginnen, kuriose Mutationen zu schaffen: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Die Logik ist klar, oder? Unser Liefersystem funktioniert nicht, unsere Systeme sind instabil und die Nutzer unzufrieden, wir schaffen es nicht, Software rechtzeitig zu veröffentlichen und bleiben im Budget zurück. Wie wollen wir all das lösen? Wir erfinden ein neues Wort! Es wird auf "Ops" enden, und das Problem ist gelöst.
So nenne ich diesen Ansatz — "Ops, und das Problem ist gelöst".
All das tritt in den Hintergrund, wenn wir uns daran erinnern, warum wir all dies überhaupt erfunden haben. Wir haben dieses DevOps konzipiert, um die Softwarelieferung und unsere Arbeit in diesem Prozess so reibungslos, schmerzfrei, effizient und vor allem angenehm wie möglich zu gestalten.
DevOps ist aus Schmerz gewachsen. Und wir haben genug gelitten. Damit das geschehen kann, stützen wir uns auf zeitlose Praktiken: effektive Zusammenarbeit, Fließpraktiken und vor allem systemisches Denken, denn ohne das funktioniert kein DevOps.
Was ist ein System?
Und da wir über systemisches Denken gesprochen haben, lassen Sie uns daran erinnern, was ein System ist.
Wenn Sie ein revolutionärer Hacker sind, betrachten Sie Systeme eindeutig als Übel. Sie sind eine Bedrohung, die über Ihnen schwebt und Sie zwingt, Dinge zu tun, die Sie nicht tun möchten.
Aus der Perspektive des systemischen Denkens 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. Das, was wir gemeinsam aufbauen, wird auch als System bezeichnet.
All dies ist Teil eines großen soziotechnologischen Systems. Nur wenn wir verstehen, wie dieses soziotechnologische System gemeinsam funktioniert, können wir in dieser Angelegenheit wirklich optimieren.
Aus der Perspektive 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. Dabei sind alle Teile auch wechselseitig abhängig. Das führt zu der Erkenntnis, dass je mehr Teile ein System hat, desto schwieriger wird es, sein Verhalten zu verstehen oder vorherzusagen.
Aus Sicht des Verhaltens gibt es noch eine interessante Tatsache. Ein System kann Dinge tun, die keine seiner einzelnen Teile allein tun kann.
Wie Dr. Russell Ackoff (einer der Begründer des systemischen Denkens) sagte, lässt sich dies relativ leicht durch ein Gedankenexperiment beweisen. Wer hier im Raum kann Programmcode schreiben? Viele Hände gehen hoch, und das ist normal, denn es ist eine der grundlegenden Anforderungen unseres Berufs. Eure Hände sind in der Lage, Code zu schreiben, aber können sie das unabhängig von euch? Es gibt Leute, die sagen würden: „Nicht meine Hände schreiben den Code, sondern mein Gehirn.“ Kann das Gehirn also unabhängig von euch Codes schreiben? Wahrscheinlich nicht.
Das Gehirn ist eine erstaunliche Maschine, von der wir nicht einmal 10% verstehen, wie sie funktioniert, aber es kann nicht unabhängig von dem System, dem unser Körper ist, agieren. Das lässt sich leicht beweisen: Öffnet euren Schädel, nehmt das Gehirn heraus, legt es vor den Computer und lasst es versuchen, etwas Einfaches zu schreiben. Zum Beispiel "Hello, world" in Python.
Wenn ein System etwas tun kann, was keine der einzelnen Komponenten allein tun kann, bedeutet das, dass sein Verhalten nicht durch das Verhalten seiner Teile bestimmt wird. Was bestimmt es dann? Es wird durch die Interaktionen zwischen diesen Teilen bestimmt. Je mehr Teile es gibt, desto komplexer sind die Interaktionen, desto schwieriger ist es, das Verhalten des Systems zu verstehen und vorherzusagen. Das macht ein solches System chaotisch, denn selbst die kleinste, für das Auge unsichtbare Veränderung in einem der Teile des Systems kann zu völlig unvorhersehbaren Ergebnissen führen.
Diese Sensibilität gegenüber den Anfangsbedingungen wurde erstmals vom amerikanischen Meteorologen Edward Lorenz entdeckt und untersucht. Später erhielt sie den Namen „Schmetterlingseffekt“ und führte zur Entwicklung einer Denkrichtung in der Wissenschaft, die als „Chaos-Theorie“ bekannt ist. Diese Theorie war eines der grundlegenden Paradigmenwechsel in der Wissenschaft des 20. Jahrhunderts.
Chaos-Theorie
Menschen, die sich mit dem Studium des Chaos beschäftigen, nennen sich Chaosologen.
Der Grund für diesen Bericht ist, dass ich beim Arbeiten mit komplexen verteilten Systemen und großen internationalen Organisationen irgendwann realisiert habe, dass ich mich als Chaosoperator fühle. Das ist eine raffinierte Art zu sagen: „Ich verstehe nicht, was hier vor sich geht, und ich weiß nicht, was ich damit anfangen soll.“
Ich denke, viele von Ihnen fühlen sich ebenso, also sind auch Sie Chaosoperatoren. Ich lade Sie ein, der Gilde der Chaosoperatoren beizutreten. Die Systeme, die wir, liebe Kollegen Chaosoperatoren, untersuchen werden, werden als „komplexe adaptive Systeme“ bezeichnet.
Was ist Adaptivität? Adaptivität bedeutet, dass das individuelle und kollektive Verhalten der Teile in einem solchen adaptiven System sich verändert und sich selbst organisiert, um auf Ereignisse oder Ketten von Mikroeignissen im System zu reagieren. Das heißt, das System passt sich durch Selbstorganisation an Veränderungen an. Diese Fähigkeit zur Selbstorganisation basiert auf freiwilliger, vollständig dezentraler Zusammenarbeit freier, autonomer Akteure.
Eine weitere interessante Eigenschaft solcher Systeme ist ihre uneingeschränkte Skalierbarkeit. Das sollte uns als Chaologen-Ingenieure sicherlich interessieren. Wenn wir also sagen, dass das Verhalten eines komplexen Systems durch das Zusammenspiel seiner Teile bestimmt wird, was sollten wir dann im Auge behalten? Das Zusammenspiel.
Es gibt noch zwei weitere interessante Erkenntnisse.
Erstens verstehen wir, dass man ein komplexes System nicht vereinfachen kann, indem man seine Teile vereinfacht. Zweitens ist der einzige Weg, ein komplexes System zu vereinfachen, die Vereinfachung der Interaktionen zwischen diesen Teilen.
Wie interagieren wir? Wir alle sind Teile eines großen Informationssystems, das menschliche Gesellschaft genannt wird. Wir interagieren durch eine gemeinsame Sprache, wenn wir eine haben, wenn wir sie finden.
Aber die Sprache selbst ist ein komplexes, adaptives System. Daher benötigen wir, um effektiver und einfacher zu interagieren, die Schaffung bestimmter Protokolle. Also eine Abfolge von Symbolen und Handlungen, die den Austausch von Informationen zwischen uns einfacher, vorhersehbarer und verständlicher machen.
Ich möchte sagen, dass die Tendenzen zu Komplexität, Adaptivität, Dezentralisierung und Chaos überall zu erkennen sind. Sowohl in den Systemen, die wir gemeinsam aufbauen, als auch in den Systemen, von denen wir Teil sind.
Um nicht nur zu behaupten, schauen wir uns an, wie sich die Systeme, die wir erschaffen, verändern.
Ich verstehe, dass Sie auf dieses Wort gewartet haben. Wir sind auf einer DevOps-Konferenz, heute wird dieses Wort etwa hunderttausend Mal gesagt werden und uns später nachts träumen.
Mikroservices sind die erste Softwarearchitektur, die als Reaktion auf DevOps-Praktiken entstanden ist. Sie soll unsere Systeme flexibler und skalierbarer machen und eine kontinuierliche Lieferung gewährleisten. Wie erreicht sie das? Durch die Reduzierung der Anzahl der Dienste, die Einschränkung der Problembereiche, die diese Dienste abdecken, und durch die Verkürzung der Lieferzeit. Das heißt, wir vereinfachen Teile des Systems, erhöhen deren Anzahl, was zwangsläufig die Komplexität der Interaktionen zwischen diesen Teilen erhöht – dabei entstehen neue Probleme, die wir lösen müssen.
Mikroservices sind noch nicht das Ende; sie gehören eigentlich schon der Vergangenheit an, denn Serverless steht vor der Tür. Alle Server sind in Flammen aufgegangen, es gibt keine Server mehr, keine Betriebssysteme, nur reiner ausführbarer Code. Konfigurationen sind separat, Zustände sind separat, alles wird durch Ereignisse gesteuert. Schönheit, Klarheit, Stille – keine Ereignisse, nichts passiert, alles in bester Ordnung.
Wo liegt die Herausforderung? Die Herausforderung liegt, das ist offensichtlich, in den Wechselwirkungen. Wie viel kann eine Funktion allein bewirken? Wie interagiert sie mit anderen Funktionen? Nachrichtenqueues, Datenbanken, Load Balancer. Wie kann man ein Ereignis rekonstruieren, wenn ein Fehler aufgetreten ist? Eine Menge Fragen und nur wenige Antworten.
Mikroservices und Serverless sind alles, was wir, die Computer-Hipster, Cloud Native nennen. Es dreht sich alles um die Cloud. Aber die Cloud ist in ihrer Natur ebenfalls in der Skalierbarkeit eingeschränkt. Wir gewöhnen uns daran, sie als verteiltes System zu betrachten. Aber wo leben die Server der Cloud-Anbieter? In Rechenzentren. Das heißt, wir haben hier eine zentralisierte, sehr begrenzte, verteilte Modell.
Heute verstehen wir, dass das Internet der Dinge nicht nur leere Worte sind. Selbst gemäß bescheidenen Prognosen werden uns in den nächsten fünf bis zehn Jahren Milliarden von Geräten erwarten, die mit dem Internet verbunden sind. Eine riesige Menge an nützlichen und unnützen Daten wird in die Cloud fließen und von dort abgerufen werden.
Die Cloud wird dem nicht standhalten, weshalb wir immer mehr über das sprechen, was als „Edge-Computing“ bezeichnet wird. Oder wie ich die wunderbare Definition „Fog-Computing“ nenne. Es hat etwas Mystisches, Romantisches und Geheimnisvolles.
Fog-Computing. Hierbei geht es darum, dass Clouds zentralisierte Ansammlungen von Wasser, Dampf, Eis und Steinen sind. Der Nebel sind die Wassertropfen, die in der Atmosphäre um uns herum verteilt sind.
In der Nebelpraxis wird der Großteil der Arbeit von diesen Tropfen völlig autonom oder in Zusammenarbeit mit anderen Tropfen erledigt. Sie wenden sich an die Cloud, nur wenn es wirklich notwendig ist.
Das bedeutet erneut Dezentralisierung, Autonomie, und viele von Ihnen verstehen wahrscheinlich bereits, worauf das alles hinausläuft, denn man kann nicht über Dezentralisierung sprechen, ohne auch Blockchain zu erwähnen.
Es gibt Menschen, die daran glauben, das sind die, die in Kryptowährungen investiert haben. Es gibt diejenigen, die daran glauben, aber Angst haben, so wie ich. Und dann gibt es die, die nicht glauben. Man kann dazu unterschiedliche Meinungen haben. Es gibt eine Technologie, ein neues, unverständliches Feld, und es gibt Probleme. Wie jede neue Technologie wirft sie mehr Fragen auf, als sie Antworten liefert.
Der Hype um die Blockchain ist nachvollziehbar. Selbst wenn man die Goldgräberstimmung beiseite lässt, bietet die Technologie großartige Versprechen für eine strahlende Zukunft: mehr Freiheit, mehr Autonomie, ein globales, verteiltes Vertrauen. Was könnte man daran nicht mögen?
Dementsprechend beginnen immer mehr Ingenieure auf der ganzen Welt, dezentrale Anwendungen zu entwickeln. Und das ist eine Kraft, die man nicht einfach ignorieren kann, indem man sagt: „Ach, die Blockchain ist lediglich eine schlecht implementierte verteilte Datenbank.“ Oder wie Skeptiker gerne sagen: „Für die Blockchain gibt es keine realen Anwendungen.“ Wenn man darüber nachdenkt, haben die Leute vor 150 Jahren das Gleiche über Elektrizität gesagt. Und in gewisser Weise hatten sie recht, denn das, was Elektrizität heute ermöglicht, war im 19. Jahrhundert absolut unerreichbar.
Übrigens, wer weiß, welches Logo auf dem Bildschirm zu sehen ist? Das ist Hyperledger. Ein Projekt, das unter der Ägide der Linux Foundation entwickelt wird und ein Set von Blockchain-Technologien umfasst. Das ist wirklich die Stärke unserer Open-Source-Community.
Chaos Engineering
Die Systeme, die wir entwickeln, werden immer komplexer, chaotischer und anpassungsfähiger. Netflix ist ein Pionier im Bereich der Mikrodienste. Sie gehörten zu den ersten, die das verstanden haben, und sie entwickelten eine Reihe von Werkzeugen, die sie Simian Army genannt haben, von denen das bekannteste ist. Er definierte das, was als .
Übrigens haben wir bei der Arbeit an der Präsentation diesen Text sogar ins Russische übersetzt, also schaut euch den an, lest ihn, kommentiert und kritisiert.
Kurz gesagt, die Prinzipien des Chaos Engineering besagen Folgendes: Komplexe verteilte Systeme sind von Natur aus unberechenbar und haben an ihrer Basis Fehler. Fehler sind unvermeidlich, und das bedeutet, dass wir diese Fehler akzeptieren und mit diesen Systemen ganz anders umgehen müssen.
Wir müssen selbst versuchen, diese Fehler in unsere Produktionssysteme einzubringen, um unsere Systeme auf deren Anpassungsfähigkeit, Selbstorganisation und Überlebensfähigkeit zu testen.
Und das ändert alles. Nicht nur, wie wir Systeme in die Produktion bringen, sondern auch, wie wir sie entwickeln und testen. Es gibt keinen Stabilisationsprozess, keine Code-Freigabe, sondern einen kontinuierlichen Prozess der Destabilisierung. Wir versuchen, das System zum Scheitern zu bringen und zu sehen, ob es dennoch überlebt.
Protokolle zur Integration verteilter Systeme
Das erfordert von unseren Systemen, dass sie sich ebenfalls ändern. Um robuster zu werden, benötigen sie neue Interaktionsprotokolle zwischen ihren Komponenten. Damit diese Teile kommunizieren und eine Form der Selbstorganisation erreichen können, entstehen zahlreiche neue Werkzeuge und Protokolle, die ich als „Interaktionsprotokolle verteilter Systeme“ bezeichne.
Wovon spreche ich? Zunächst einmal vom Projekt . Ein Versuch, ein gemeinsames Protokoll für verteiltes Tracking zu schaffen, ist ein unerlässliches Werkzeug zur Fehlersuche in komplexen verteilten Systemen.
Als Nächstes folgt . Wir können nicht vorhersagen, was mit dem System passieren wird, daher müssen wir seine Observability, also die Sichtbarkeit erhöhen. Opentracing gehört zur Familie von Werkzeugen, die die Observability unserer Systeme bieten. Aber Observability ist nötig, um festzustellen, ob das System sich so verhält, wie wir es erwarten oder nicht. Wie bestimmen wir das erwartete Verhalten? Durch die Definition einer Art von Richtlinie, eines Regelwerks. Das Projekt Open Policy Agent beschäftigt sich mit der Definition dieses Regelwerks in einem breiten Spektrum: von Zugriffsrechten bis hin zur Ressourcenzuteilung.
Wie bereits erwähnt, werden unsere Systeme zunehmend ereignisgesteuert. Serverless ist ein hervorragendes Beispiel für ereignisgesteuerte Systeme. Damit wir Ereignisse zwischen Systemen weiterleiten und deren Verlauf verfolgen können, benötigen wir eine gemeinsame Sprache, ein gemeinsames Protokoll, um über Ereignisse zu kommunizieren und sie zu übermitteln. Dies wird durch ein Projekt namens .
Ein kontinuierlicher Fluss von Veränderungen, der unsere Systeme umhüllt und sie ständig destabilisiert, ist ein ständiger Strom von Software-Artefakten. Damit wir diesen kontinuierlichen Fluss von Veränderungen aufrechterhalten können, benötigen wir einen gemeinsamen Protokoll, um darüber zu sprechen, was ein Software-Artefakt ist, wie es geprüft wird und welche Validierung es durchlaufen hat. Damit beschäftigt sich ein Projekt namens . Das ist also ein gemeinsames Protokoll für Metadaten von Software-Artefakten.
Und schließlich, wenn wir möchten, dass unsere Systeme vollständig autark, anpassungsfähig und selbstorganisierend sind, müssen wir ihnen das Recht auf Selbstidentifikation geben. Ein Projekt namens kümmert sich genau darum. Dies ist ebenfalls ein Projekt unter dem Dach der Cloud Native Computing Foundation.
All diese Projekte sind jung und benötigen unsere Unterstützung und Überprüfung. Es handelt sich um Open-Source-Code, unser Test, unsere Implementierung. Sie zeigen uns, in welche Richtung sich die Technologie entwickelt.
DevOps war jedoch nie in erster Linie Technologie; vielmehr ging es immer um die Zusammenarbeit zwischen Menschen. Und entsprechend, wenn wir möchten, dass die Systeme, die wir entwickeln, sich ändern, müssen auch wir uns ändern. Tatsächlich verändert sich bereits, wir haben nicht wirklich eine Wahl.
Es gibt ein wunderbares der britischen Autorin Rachel Botsman, in dem sie über die Evolution des Vertrauens im Laufe der Menschheitsgeschichte schreibt. Sie erklärt, dass Vertrauen ursprünglich in primitiven Gesellschaften lokal war, das heißt, wir vertrauten nur denjenigen, die wir persönlich kannten.
Dann gab es eine sehr lange Zeit — eine dunkle Epoche, in der Vertrauen zentralisiert war, als wir anfingen, Menschen, die wir nicht kannten, aufgrund der Tatsache zu vertrauen, dass wir zu demselben sozialen oder staatlichen Institut gehörten.
Und das sehen wir in unserer modernen Welt: Vertrauen wird zunehmend verteilt und dezentralisiert, und es basiert auf der Freiheit der Informationsströme und der Zugänglichkeit von Informationen.
Wenn man darüber nachdenkt, ist es genau diese Verfügbarkeit, die Vertrauen schafft, und die setzen wir um. Das bedeutet, dass sich auch unsere Zusammenarbeit und die Art und Weise, wie wir arbeiten, ändern müssen, denn die zentralisierten, hierarchischen IT-Organisationen der alten Schule funktionieren nicht mehr. Sie beginnen, auszusterben.
Grundlagen der DevOps-Organisation
Die ideale DevOps-Organisation der Zukunft ist ein dezentrales, anpassungsfähiges System, das aus autonomen Teams besteht, die jeweils aus selbständigen Individuen bestehen. Diese Teams sind weltweit verteilt und arbeiten effizient miteinander durch asynchrone Kommunikation und hochtransparente Informationsaustauschprotokolle. Sehr schön, oder? Eine wunderschöne Zukunft.
Natürlich ist all dies ohne kulturelle Veränderungen unmöglich. Wir benötigen transformationales Leadership, persönliche Verantwortung und innere Motivation.
Das ist die Grundlage von DevOps-Organisationen: Transparenz der Informationen, asynchrone Kommunikation, transformationales Leadership, Dezentralisierung.
Burnout
Die Systeme, zu denen wir gehören und die wir aufbauen, werden zunehmend chaotisch, und es fällt uns, den Menschen, schwer, mit diesem Gedanken umzugehen. Wir versuchen weiterhin, sie zu kontrollieren, was oft zu Erschöpfung führt. Ich spreche aus eigener Erfahrung – ich habe auch Fehler gemacht und wurde durch unerwartete Ausfälle im Produktionsumfeld beeinträchtigt.
Erschöpfung tritt auf, wenn wir versuchen, das zu kontrollieren, was von Natur aus nicht kontrollierbar ist. Wenn wir erschöpft sind, verliert alles seinen Sinn, weil wir das Verlangen verlieren, etwas Neues zu schaffen. Wir nehmen eine defensive Haltung ein und beginnen, das zu verteidigen, was wir haben.
Der Ingenieurberuf, wie ich mir oft gerne ins Gedächtnis rufe, ist in erster Linie ein kreativer Beruf. Wenn wir das Verlangen verlieren, etwas zu schaffen, verwandeln wir uns in Asche, werden zu Staub. Menschen werden erschöpft, ganze Organisationen brennen aus.
Meiner Meinung nach ist nur die Akzeptanz der schöpferischen Kraft des Chaos und der Aufbau von Zusammenarbeit nach seinen Prinzipien der Weg, wie wir das Gute, das in unserem Beruf steckt, bewahren können.
Was ich Ihnen wünsche: Lieben Sie Ihre Arbeit, lieben Sie, was wir tun. Diese Welt nährt sich von Informationen, und wir haben die Ehre, sie zu versorgen. Lassen Sie uns also das Chaos studieren, Chaosologen werden, Wert schaffen, etwas Neues kreieren. Die Probleme, das haben wir bereits festgestellt, sind unvermeidlich, und wenn sie auftreten, sagen wir einfach „Ops!“, und das Problem ist gelöst.
Was gibt es außer Chaos Monkey?
Tatsächlich sind all diese Werkzeuge noch jung. Netflix baute ihre Werkzeuge selbst. Bauen Sie Werkzeuge für sich selbst. Lesen Sie die Prinzipien der Chaos-Engineering und halten Sie sich an diese Prinzipien, anstatt nach anderen Tools zu suchen, die jemand anders bereits erstellt hat.
Versuchen Sie zu verstehen, wie Ihre Systeme ausfallen, und beginnen Sie, sie absichtlich zu beschädigen, um zu sehen, wie sie mit den Schlägen umgehen. Das hat oberste Priorität. Werkzeuge können Sie später suchen. Es gibt viele Projekte.
Ich habe nicht ganz verstanden, als Sie sagten, dass man ein System nicht vereinfachen kann, indem man seine Komponenten vereinfacht, und sofort auf Mikroservices übergingen, die genau das System durch die Vereinfachung der Komponenten vereinfachen und die Interaktionen komplizierter machen. Das sind im Grunde zwei Teile, die sich gegenseitig widersprechen.
Ganz genau, Microservices sind ein äußerst umstrittenes Thema. Tatsächlich erhöht die Aufsplitterung in kleinere Teile die Flexibilität. Was bringen uns Microservices? Sie bieten uns Flexibilität und Geschwindigkeit, jedoch keinen Zugewinn an Einfachheit. Sie erhöhen die Komplexität.
Bedeutet das, dass Microservices in der DevOps-Philosophie nicht wirklich vorteilhaft sind?
Jedes Gute hat seine Schattenseiten. Es gibt Vorteile: Es erhöht die Flexibilität und ermöglicht uns schnellere Anpassungen, aber es steigert auch die Komplexität und damit die Fragilität des gesamten Systems.
Worauf sollte der Fokus mehr liegen: auf der Vereinfachung der Interaktionen oder auf der Vereinfachung der einzelnen Teile?
Der Fokus liegt zweifellos auf der Vereinfachung der Interaktionen, denn wenn wir betrachten, wie wir zusammenarbeiten, sollte die Hauptaufmerksamkeit auf der Vereinfachung der Interaktionen liegen, nicht auf der Vereinfachung der Arbeit jedes Einzelnen. Denn Arbeit zu vereinfachen wäre, uns zu Robotern zu machen. Bei McDonald's funktioniert das gut, wenn man genau vorgegeben bekommt: Hier den Burger hinlegen, hier die Soße draufgeben. Das funktioniert in unserer kreativen Arbeit überhaupt nicht.
Ist es wirklich so, dass alles, was Sie beschrieben haben, in einer Welt ohne Konkurrenz existiert, in der das Chaos so freundlich ist und keine Widersprüche innerhalb dieses Chaos vorhanden sind, niemand will jemanden essen oder töten? Wie sollten Konkurrenz und DevOps zusammen existieren?
Nun, das hängt davon ab, von welcher Konkurrenz wir sprechen. Geht es um Konkurrenz am Arbeitsplatz oder um Konkurrenz zwischen Unternehmen?
Es geht um die Konkurrenz von Diensten, die existieren, denn Dienste sind nicht nur mehrere Unternehmen. Wir schaffen eine neue Art von Informationsumgebung, und jede Umgebung kann nicht ohne Konkurrenz existieren. Überall gibt es Konkurrenz.
Nehmen wir Netflix als Beispiel. Warum haben sie das entwickelt? Weil sie wettbewerbsfähig sein mussten. Diese Flexibilität und Geschwindigkeit sind genau das, was das Wettbewerbsumfeld erfordert, und sie bringen Unordnung in unsere Systeme. Chaos ist also nicht etwas, das wir absichtlich schaffen, weil wir es wollen; es geschieht aufgrund der Anforderungen der Welt. Wir müssen uns einfach anpassen. Und Chaos ist genau das Ergebnis von Konkurrenz.
Das bedeutet, dass Chaos das Fehlen von Zielen ist? Oder sind es die Ziele, die wir nicht sehen wollen? Wir sind in unserem eigenen Raum und verstehen die Ziele anderer nicht. Der Wettbewerb ergibt sich tatsächlich daraus, dass wir klare Ziele haben und wissen, wo wir im nächsten Moment sein werden. Darin liegt aus meiner Sicht das Wesen von DevOps.
Das ist auch eine Sichtweise. Ich denke, unser gemeinsames Ziel ist es, zu überleben und das mit
maximalem Genuss zu tun. Und das konkurrierende Ziel jeder Organisation ist dasselbe. Das Überleben erfolgt oft im Wettbewerb, da lässt sich nichts machen.
In diesem Jahr findet die Konferenz am 7. Dezember im „Technopolis“ statt. Wir nehmen bis zum 11. November Vorschläge für Vorträge an. uns, wenn Sie einen Vortrag halten möchten.
Die Registrierung für Teilnehmer ist eröffnet, das Ticket kostet 7000 Rubel. Kommen Sie dazu!
Quelle: habr.com
