Der Gründer und Direktor von «Otomato Software», einer der Initiatoren und Trainer der ersten DevOps-Zertifizierung in Israel, Anton Weiss, sprach im letzten Jahr über die Chaos-Theorie und die wichtigsten Prinzipien der Chaos-Engineering sowie darüber, wie eine ideale DevOps-Organisation der Zukunft aussieht.
Wir haben eine schriftliche Version des Vortrags vorbereitet.
Guten Morgen!
DevOpsDays in Moskau zum zweiten Mal in Folge, ich bin zum zweiten Mal auf dieser Bühne, viele von Ihnen sind zum zweiten Mal in diesem Raum. Und was bedeutet das? Das bedeutet, dass die DevOps-Bewegung in Russland wächst, sich verbreitet und vor allem, dass es an der Zeit ist zu besprechen, was DevOps im Jahr 2018 ist.
Wer denkt, dass DevOps im Jahr 2018 bereits ein Beruf ist? Gibt es solche? Gibt es im Raum DevOps-Ingenieure, die in ihrer Stellenbeschreibung „DevOps-Ingenieur“ stehen haben? Gibt es im Raum DevOps-Manager? solche haben wir nicht. DevOps-Architekten? Auch nicht. Zu wenig. Wirklich hat niemand die Bezeichnung DevOps-Ingenieur?
Das bedeutet, dass die meisten von Ihnen denken, dass dies ein Antipattern ist? Dass es diesen Beruf nicht geben sollte? Wir können alles Mögliche denken, während die Branche feierlich vorankommt unter den Klängen der DevOps-Trompete.
Wer hat von dem neuen Thema gehört, das DevDevOps heißt? Das ist eine neue Methode, die eine effektive Zusammenarbeit zwischen Entwicklern und DevOps ermöglicht. Und zwar nicht ganz neu. Wenn man Twitter glauben kann, wurde vor 4 Jahren bereits darüber gesprochen. Und bis heute wächst das Interesse daran, das heißt, es gibt ein Problem. Dieses Problem muss gelöst werden.
Wir sind kreative Menschen, wir beruhigen uns nicht einfach. Wir sagen: DevOps ist nicht umfassend genug, da fehlen viele interessante Elemente. Und wir gehen in unsere geheimen Labore und beginnen, neugierige Mutationen zu schaffen: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Die Logik ist unbestreitbar, oder? Unser Liefersystem ist nicht funktional, wir haben instabile Systeme und unzufriedene Benutzer, wir schaffen es nicht, Software rechtzeitig auszurollen und bleiben nicht im Budget. Wie werden wir das alles 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“.
Das tritt alles in den Hintergrund, wenn wir uns daran erinnern, warum wir das alles erdacht haben. Wir haben all dieses DevOps erdacht, um die Softwarebereitstellung und unsere eigene Arbeit in diesem Prozess so reibungslos, schmerzlos, effizient und vor allem angenehm wie möglich zu gestalten.
DevOps ist aus Schmerz gewachsen. Und wir haben genug gelitten. Damit das alles geschieht, basieren wir auf zeitlosen Praktiken: effektive Zusammenarbeit, Flusspraktiken und vor allem systemisches Denken, denn ohne das funktioniert kein DevOps.
Was ist ein System?
Und da wir über systemisches Denken sprechen, lassen Sie uns daran erinnern, was ein System ist.
Wenn Sie ein revolutionärer Hacker sind, dann ist für Sie das System das reine Übel. Es ist eine Wolke, die über Ihnen schwebt und Sie zwingt, Dinge zu tun, die Sie nicht tun wollen.
Aus der Sicht 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. Und das, was wir zusammen aufbauen, wird ebenfalls als System bezeichnet.
All dies ist Teil eines großen soziotechnischen Systems. Und nur wenn wir verstehen, wie dieses soziotechnische System zusammenarbeitet, können wir in diesem Bereich wirklich etwas optimieren.
Aus der Sicht des systemischen Denkens hat ein System verschiedene interessante Eigenschaften. Erstens besteht es aus Teilen, was bedeutet, dass sein Verhalten von dem Verhalten der Teile abhängt. Dabei sind alle seine Teile auch voneinander abhängig. Das bedeutet, je mehr Teile ein System hat, desto schwerer ist es, sein Verhalten zu verstehen oder vorherzusagen.
Aus der Sicht des Verhaltens gibt es noch eine interessante Tatsache. Ein System kann etwas tun, was keine seiner einzelnen Teile tun kann.
Wie Dr. Russell Ackoff (einer der Begründer des systemischen Denkens) sagte, lässt sich dies leicht durch ein Gedankenexperiment beweisen. Zum Beispiel, wer im Raum kann Code schreiben? Viele Hände, und das ist normal, denn das ist eine der grundlegenden Anforderungen an unseren Beruf. Sie können schreiben, aber Ihre Hände können getrennt von Ihnen Code schreiben? Es gibt Leute, die sagen: „Es sind nicht meine Hände, die Code schreiben, es ist mein Gehirn, das Code schreibt.“ Und kann das Gehirn getrennt von Ihnen Code schreiben? Wohl eher nicht.
Das Gehirn ist eine erstaunliche Maschine. Wir wissen nicht einmal 10%, wie es funktioniert, aber es kann nicht unabhängig von dem System funktionieren, das unser Organismus ist. Das lässt sich leicht beweisen: Öffnen Sie Ihren Schädel, nehmen Sie das Gehirn heraus, legen Sie es vor einen Computer und lassen Sie ihn versuchen, etwas Einfaches zu schreiben. Zum Beispiel "Hello, world" in Python.
Wenn ein System etwas tun kann, was keine seiner Teile allein tun kann, dann bedeutet das, dass sein Verhalten nicht durch das Verhalten seiner Teile bestimmt wird. Aber wodurch wird es dann bestimmt? Es wird durch die Interaktion zwischen diesen Teilen bestimmt. Und entsprechend gilt: Je mehr Teile, desto komplizierter die Interaktionen, desto schwieriger ist es, das Verhalten des Systems zu verstehen und vorherzusagen. Und das macht ein solches System chaotisch, denn jede noch so unbedeutende, mit dem bloßen Auge unsichtbare Veränderung in einem der Teile des Systems kann zu völlig unvorhersehbaren Ergebnissen führen.
Diese Sensibilität gegenüber Anfangsbedingungen wurde erstmals von dem amerikanischen Meteorologen Edward Lorenz entdeckt und untersucht. Später erhielt sie den Namen „Schmetterlingseffekt“ und führte zur Entwicklung einer wissenschaftlichen Denkweise, die „Chaos-Theorie“ genannt wird. Diese Theorie wurde zu einem der grundlegenden Paradigmenwechsel in der Wissenschaft des 20. Jahrhunderts.
Chaos-Theorie
Menschen, die sich mit der Erforschung von Chaos befassen, nennen sich Chaosologen.
Der eigentliche Anlass für diesen Bericht war, dass ich, während ich mit komplexen verteilten Systemen und großen internationalen Organisationen arbeitete, irgendwann realisierte, dass dies das ist, was ich fühle. Ich bin ein Chaosologe. Das ist im Grunde eine raffinierte Art zu sagen: „Ich verstehe nicht, was hier passiert und weiß nicht, was ich damit anfangen soll.“
Ich denke, viele von Ihnen fühlen sich oft genauso, also sind Sie auch Chaosologen. Ich lade Sie in die Gilde der Chaosologen ein. Die Systeme, die wir, liebe Kollegen Chaosologen, untersuchen werden, heißen „komplexe adaptive Systeme“.
Was ist Adaptivität? Adaptivität bedeutet, dass sich das individuelle und kollektive Verhalten der Teile in einem solchen adaptiven System ändert und selbstorganisiert, um auf Ereignisse oder Folgen von Mikroereignissen im System zu reagieren. 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 dezentralisierten Zusammenarbeit freier autonomer Agenten.
Eine weitere interessante Eigenschaft solcher Systeme ist, dass sie sich frei skalieren lassen. Was uns als Chaosologen-Ingenieure zweifellos interessieren sollte. Wenn wir also sagen, dass das Verhalten eines komplexen Systems durch das Zusammenspiel seiner Teile bestimmt wird, was sollte uns dann interessieren? Das Zusammenspiel.
Es gibt noch zwei interessante Schlussfolgerungen.
Erstens verstehen wir, dass ein komplexes System nicht vereinfacht werden kann, indem man seine Teile vereinfacht. Zweitens ist der einzige Weg, ein komplexes System zu vereinfachen, die Vereinfachung der Interaktionen zwischen seinen 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, die wir finden.
Aber die Sprache selbst ist ein komplexes adaptives System. Um also effektiver und einfacher zu interagieren, müssen wir einige Protokolle erstellen. Das heißt, eine Abfolge von Symbolen und Handlungen, die den Informationsaustausch zwischen uns einfacher, vorhersehbarer und verständlicher machen.
Ich möchte sagen, dass die Tendenzen zur Komplexität, zur Adaptivität, zur Dezentralisierung und zur Chaotizität in allem zu erkennen sind. Sowohl in den Systemen, die wir aufbauen, als auch in den Systemen, zu denen wir gehören.
Und um nicht unbegründet zu sein, lassen Sie uns ansehen, wie sich die Systeme, die wir schaffen, verändern.
Sie haben auf dieses Wort gewartet, das verstehe ich. Wir sind auf der DevOps-Konferenz, heute wird dieses Wort wahrscheinlich hunderttausendmal fallen und uns dann nachts träumen.
Mikroservices sind die erste Softwarearchitektur, die als Reaktion auf DevOps-Praktiken entstanden ist, um unsere Systeme flexibler und skalierbarer zu machen und eine kontinuierliche Bereitstellung zu gewährleisten. Wie geschieht das? Durch die Reduzierung des Umfangs der Dienste, die Verkleinerung der Problembereiche, die diese Dienste behandeln, und die Verkürzung der Lieferzeiten. Das bedeutet, dass wir Teile des Systems reduzieren und vereinfachen, ihre Anzahl erhöhen und somit unweigerlich die Komplexität der Interaktionen zwischen diesen Teilen steigern, was wiederum neue Probleme mit sich bringt, die wir lösen müssen.
Mikroservices sind noch nicht das Ende, Mikroservices sind eigentlich schon von gestern, denn es kommt Serverless. Alle Server sind ausgebrannt, es gibt keine Server, keine Betriebssysteme mehr, nur noch reinen ausführbaren Code. Konfigurationen sind separat, Zustände sind separat, alles wird durch Events gesteuert. Schönheit, Reinheit, Stille, keine Events, nichts passiert, alles in bester Ordnung.
Wo liegt die Komplexität? Die Komplexität liegt offensichtlich in den Interaktionen. Was kann eine Funktion allein leisten? Wie interagiert sie mit anderen Funktionen? Warteschlangen, Datenbanken, Lastverteiler. Wie rekonstruiert man ein Ereignis, wenn ein Fehler aufgetreten ist? Eine Menge Fragen und wenig Antworten.
Mikroservices und Serverless sind all das, was wir, Computer-Hipster, Cloud Native nennen. Es geht also um die Cloud. Aber die Cloud ist im Grunde auch in der Skalierung begrenzt. Wir gewöhnen uns daran, sie als verteiltes System zu betrachten. Wo wohnen eigentlich die Server der Cloud-Anbieter? In Rechenzentren. Das heißt, wir haben hier ein gewisses zentralisiertes, sehr begrenztes, verteiltes Modell.
Heute verstehen wir, dass das Internet der Dinge nicht nur leere Worte sind; selbst nach bescheidenen Prognosen erwarten uns in den nächsten fünf bis zehn Jahren Milliarden von Geräten, die mit dem Internet verbunden sind. Eine riesige Menge nützlicher und unnützer Daten, die in die Cloud fließen und aus der Cloud abgerufen werden.
Die Cloud wird dem nicht gewachsen sein, deshalb reden wir immer mehr über das, was man "Edge Computing" nennt. Oder ich mag die wundervolle Definition "Fog Computing". Es ist von der Mystik der Romantik und des Geheimnisvollen umhüllt.
Nebulöse Berechnungen. Es geht darum, dass Wolken zentralisierte Ansammlungen von Wasser, Dampf, Eis und Steinen sind. Nebel hingegen besteht aus Wassertropfen, die in der Atmosphäre um uns herum verteilt sind.
Im nebligen Paradigma wird der Großteil der Arbeit von diesen Tropfen vollkommen autonom oder in Zusammenarbeit mit anderen Tropfen erledigt. Sie wenden sich nur dann an die Wolke, wenn es wirklich notwendig ist.
Das heißt, wieder Dezentralisierung, Autonomie, und natürlich verstehen viele von Ihnen bereits, wohin das alles führt, denn man kann nicht von Dezentralisierung sprechen, ohne die Blockchain zu erwähnen.
Es gibt diejenigen, die daran glauben, das sind die, die in Kryptowährungen investiert haben. Es gibt die, die glauben, aber Angst haben, wie ich zum Beispiel. Und es gibt die, die nicht glauben. Man kann dazu unterschiedliche Meinungen haben. Es gibt Technologie, ein neues, unerklärliches Thema, es gibt Probleme. Wie jede neue Technologie wirft sie mehr Fragen auf, als sie beantwortet.
Der Hype um Blockchain ist verständlich. Selbst wenn man die Goldgräberstimmung beiseite lässt, bietet die Technologie große Versprechen für eine strahlende Zukunft: mehr Freiheit, mehr Autonomie, globales verteiltes Vertrauen. Was gibt es daran nicht zu mögen?
Folglich beginnen immer mehr Ingenieure auf der ganzen Welt, dezentrale Anwendungen zu entwickeln. Und das ist eine Kraft, die man nicht ignorieren kann, indem man einfach sagt: „Oh, die Blockchain ist nur schlecht implementierte verteilte Datenbank.“ Oder wie Skeptiker gerne sagen: „Für Blockchain gibt es keine realen Anwendungen.“ Wenn man darüber nachdenkt, haben sie vor 150 Jahren dasselbe über Elektrizität gesagt. Und in gewisser Hinsicht hatten sie recht, denn was Elektrizität heute möglich macht, war im 19. Jahrhundert absolut unrealistisch.
Übrigens, wer weiß, was das Logo auf dem Bildschirm ist? Das ist Hyperledger. Es ist ein Projekt, das unter dem Dach der Linux Foundation entwickelt wird und eine Reihe von Blockchain-Technologien umfasst. Es ist wirklich die Stärke unserer Open-Source-Community.
Chaotische Ingenieurtechnik
So wird das System, das wir entwickeln, immer komplexer, chaotischer und anpassungsfähiger. Netflix ist ein Pionier von Mikrodiensten. Sie gehörten zu den ersten, die das verstanden haben, und sie entwickelten ein Set von Werkzeugen, das sie Simian Army nannten, von denen das bekannteste wurde. Er definierte das, was als bekannt wurde .
Übrigens haben wir während der Arbeit an dem Bericht diesen Text sogar ins Russische übersetzt, also besucht uns unter , lest, kommentiert und kritisiert uns.
Kurz gesagt, die Prinzipien der Chaos-Ingenieurwissenschaft besagen Folgendes: Komplexe verteilte Systeme sind von Natur aus unvorhersehbar und beinhalten Fehler. Fehler sind unvermeidlich, was bedeutet, dass wir diese Fehler akzeptieren und mit diesen Systemen ganz anders umgehen müssen.
Wir sollten selbst versuchen, diese Fehler in unsere Produktionssysteme einzuführen, um unsere Systeme auf ihre Anpassungsfähigkeit, ihre Selbstorganisationsfähigkeit und ihre Überlebensfähigkeit zu testen.
Und das ändert alles. Nicht nur, wie wir das System in die Produktion bringen, sondern auch, wie wir es entwickeln und testen. Es gibt keinen Stabilitätsprozess, keinen Code-Stopp; im Gegenteil, es gibt einen ständigen Prozess der Destabilisierung. Wir versuchen, das System zu zerstören und zu sehen, dass es weiterhin überlebt.
Protokolle zur Integration verteilter Systeme
Das erfordert natürlich, dass sich unsere Systeme auch irgendwie ändern. Damit sie widerstandsfähiger werden, benötigen sie neue Interaktionsprotokolle zwischen ihren Teilen. Damit diese Teile sich verständigen und zu einer Selbstorganisation kommen können. Es entstehen zahlreiche neue Werkzeuge und Protokolle, die ich einfach „Interaktionsprotokolle verteilte Systeme“ nenne.
Wovon spreche ich? Zunächst einmal vom Projekt . Ein Versuch, ein allgemeines Protokoll für verteiltes Tracing zu schaffen, das ein unverzichtbares Werkzeug zur Fehlersuche bei komplexen verteilten Systemen ist.
Weiter - . Wir sagen, dass wir nicht vorhersagen können, was mit dem System passieren wird, also müssen wir seine Beobachtbarkeit erhöhen. Opentracing gehört zur Familie von Werkzeugen, die die Beobachtbarkeit unserer Systeme bieten. Aber wir benötigen die Beobachtbarkeit, um festzustellen, ob sich das System so verhält, wie wir es erwarten oder nicht. Wie können wir das erwartete Verhalten erkennen? Indem wir in ihm eine Art Politik, einen regelbasierten Rahmen definieren. Das Projekt Open Policy Agent befasst sich mit der Definition dieses Regelwerks über ein breites Spektrum: von Zugriffssteuerung bis Ressourcenplatzierung.
Wie wir gesagt haben, werden unsere Systeme zunehmend ereignisgesteuert. Serverless ist ein hervorragendes Beispiel für ereignisgesteuerte Systeme. Damit wir Ereignisse zwischen Systemen übermitteln und verfolgen können, benötigen wir eine gemeinsame Sprache, ein gemeinsames Protokoll dafür, wie wir über Ereignisse sprechen, wie wir sie einander übermitteln. Dies wird durch ein Projekt namens .
der kontinuierliche Fluss von Veränderungen, der unsere Systeme umspült und sie ständig destabilisiert, ist ein kontinuierlicher Fluss von Software-Artefakten. Damit wir diesen ständigen Fluss von Veränderungen aufrechterhalten können, benötigen wir ein gemeinsames Protokoll, das es uns ermöglicht, darüber zu sprechen, was ein Software-Artefakt ist, wie es validiert ist und welche Verifizierung es durchlaufen hat. Dies wird durch ein Projekt namens bereitgestellt. Das heißt, ein gemeinsames Protokoll für die Metadaten von Software-Artefakten.
Und schließlich, wenn wir wollen, dass unsere Systeme vollkommen autonom, anpassungsfähig und selbstorganisiert sind, müssen wir ihnen das Recht auf Selbstidentifikation geben. Das Projekt namens beschäftigt sich genau damit. Es ist ebenfalls ein Projekt unter der Ägide der Cloud Native Computing Foundation.
Alle diese Projekte sind jung, sie benötigen alle unsere Unterstützung, unsere Überprüfung. Das alles ist Open Source, unser Testen, unsere Implementierung. Sie zeigen uns, in welche Richtung sich die Technologie bewegt.
Aber DevOps war nie in erster Linie eine Technologiefrage, es ging in erster Linie immer um die Zusammenarbeit zwischen Menschen. Wenn wir also wollen, dass sich die Systeme, die wir entwickeln, ändern, müssen wir uns selbst ändern. Tatsächlich ändern wir uns ohnehin, wir haben nicht wirklich eine Wahl.
Es gibt eine bemerkenswerte britische Autorin Rachel Botsman, die über die Evolution des Vertrauens in der Geschichte der Menschheit schreibt. Sie sagt, dass Vertrauen ursprünglich in primären Gesellschaften lokal war, das heißt, wir vertrauten nur denjenigen, die wir persönlich kannten.
Dann folgte eine sehr lange Periode - eine dunkle Zeit, in der Vertrauen zentralisiert war, als wir anfingen, Menschen zu vertrauen, die wir nicht kannten, basierend darauf, dass wir zu demselben sozialen oder staatlichen Institut gehörten.
Und hier ist, was wir in unserer modernen Welt sehen: Vertrauen wird immer dezentraler und verteilter und basiert auf der Freiheit der Informationsströme, auf der Verfügbarkeit von Informationen.
Wenn man darüber nachdenkt, dann sind wir es, die diese Verfügbarkeit, die dieses Vertrauen möglich macht, realisieren. Das bedeutet, dass sich sowohl unsere Kooperation als auch die Art und Weise, wie wir dies tun, verändern muss, denn zentralisierte, hierarchische IT-Organisationen alter Schule hören auf zu funktionieren. Sie beginnen auszusterben.
Grundlagen von DevOps-Organisationen
Die ideale DevOps-Organisation der Zukunft ist ein dezentrales, anpassungsfähiges System, bestehend aus autonomen Teams, von denen jedes aus autonomen Individuen besteht. Diese Teams sind über die ganze Welt verteilt und arbeiten effektiv über asynchrone Kommunikation und hochtransparente Informationsaustauschprotokolle zusammen. Sehr schön, nicht wahr? Eine sehr schöne Zukunft.
Natürlich ist das alles unmöglich ohne kulturelle Veränderungen. Wir brauchen transformationale Führung, persönliche Verantwortung und interne Motivation.
Das ist das Fundament von DevOps-Organisationen: Transparenz von Informationen, asynchrone Kommunikation, transformationale Führung, Dezentralisierung.
Burnout
Die Systeme, Teil von denen wir sind und die wir aufbauen, werden immer chaotischer, und es fällt uns Menschen schwer, mit diesem Gedanken umzugehen, es fällt uns schwer, uns von der Illusion der Kontrolle zu lösen. Wir versuchen weiterhin, sie zu kontrollieren, und das führt oft zu Burnout. Ich spreche aus eigener Erfahrung, ich habe mich ebenfalls verbrannt, bin auch ein Opfer unvorhergesehener Fehlermeldungen in der Produktion.
Burnout tritt dann auf, wenn wir versuchen, das zu kontrollieren, was im Wesentlichen nicht kontrollierbar ist. Wenn wir ausbrennen, verliert alles seinen Sinn, da wir das Verlangen verlieren, etwas Neues zu schaffen, wir gehen in eine defensive Position und beginnen, das Vorhandene zu verteidigen.
Der Ingenieurberuf, an den ich mich oft erinnere, ist in erster Linie ein kreativer Beruf. Wenn wir das Verlangen verlieren, etwas zu erschaffen, werden wir zu Asche, werden wir zu Staub. Menschen verbrennen aus, ganze Organisationen verbrennen aus.
Meiner Meinung nach ist es nur die Annahme der schöpferischen Kraft des Chaos, nur der Aufbau von Zusammenarbeit nach seinen Prinzipien, das uns helfen wird, das Gute, das es in unserem Beruf gibt, nicht zu verlieren.
Das wünsche ich Ihnen: lieben Sie Ihre Arbeit, lieben Sie das, was wir tun. Diese Welt lebt von Informationen, uns wurde die Ehre zuteil, sie zu speisen. Lassen Sie uns also das Chaos studieren, lassen Sie uns Chaosologen sein, Werte schaffen, etwas Neues erschaffen, und die Probleme, wie wir bereits festgestellt haben, sind unvermeidlich, und wenn sie auftauchen, sagen wir einfach „Ops!“, und das Problem ist gelöst.
Was gibt es außer Chaos Monkey?
In der Tat sind all diese Werkzeuge sehr neu. Dasselbe gilt für Netflix, die Werkzeuge für sich selbst entwickelt haben. Entwickeln Sie Werkzeuge für sich selbst. Lesen Sie die Prinzipien der Chaos-Engineering und halten Sie sich an diese Prinzipien, und suchen Sie nicht nach anderen Werkzeugen, die jemand anderes bereits erstellt hat.
Versuchen Sie zu verstehen, wie Ihre Systeme brechen und beginnen Sie, sie zu brechen und zu beobachten, wie sie Schläge aushalten. Das steht an erster Stelle. Und nach Werkzeugen kann man suchen. Es gibt viele Projekte.
Ich habe den Punkt nicht ganz verstanden, als Sie sagten, dass man ein System nicht vereinfachen kann, indem man seine Komponenten vereinfacht, und sofort zu Mikroservices übergingen, die das System gerade durch die Vereinfachung der Komponenten vereinfachen und die Interaktionen komplizieren. Das sind im Wesentlichen zwei Teile, die sich widersprechen.
Das ist völlig korrekt, Mikroservices sind insgesamt ein sehr kontroverses Thema. Tatsächlich erhöht die Vereinfachung von Teilen die Flexibilität. Was geben uns Mikroservices? Sie geben uns Flexibilität und Geschwindigkeit, aber sie bringen uns sicher keine Einfachheit. Sie erhöhen die Komplexität.
Das heißt, in der Philosophie von DevOps sind Mikroservices also nicht unbedingt ein Vorteil?
Jedes Gute hat seine Schattenseite. Es gibt Vorteile: Es erhöht die Flexibilität, gibt uns die Möglichkeit, Änderungen schneller vorzunehmen, aber es erhöht die Komplexität und somit die Zerbrechlichkeit des gesamten Systems.
Worauf liegt also mehr der Fokus: auf der Vereinfachung der Interaktionen oder auf der Vereinfachung der Teile?
Der Fokus liegt zweifellos auf der Vereinfachung der Interaktionen, denn wenn wir das aus der Perspektive betrachten, wie wir miteinander arbeiten, müssen wir zunächst die Vereinfachung der Interaktionen und nicht die Vereinfachung der Arbeit jedes Einzelnen beachten. Denn eine vereinfachte Arbeit verwandelt uns in Roboter. Im McDonald's funktioniert das gut, wenn dir vorgeschrieben ist: hier hast du den Burger hingelegt, hier hast du die Soße draufgegossen. In unserer kreativen Arbeit funktioniert das überhaupt nicht.
Ist es wahr, dass alles, was Sie gesagt haben, in einer Welt ohne Wettbewerb lebt, die dort so freundlich ist und es keine Widersprüche innerhalb dieses Chaos gibt, dass niemand niemanden fressen oder töten will? Wie sollten Wettbewerb und DevOps zusammenleben?
Nun, es kommt darauf an, über welchen Wettbewerb wir sprechen. Über Wettbewerb am Arbeitsplatz oder über Wettbewerb zwischen Unternehmen?
Über den Wettbewerb der bestehenden Dienste, denn Dienste sind keine einzelnen Unternehmen. Wir schaffen einen neuen Typ von Informationsumgebung, und jede Umgebung kann nicht ohne Wettbewerb existieren. Überall gibt es Wettbewerb.
Nehmen wir das Beispiel von Netflix als unser Rollenmodell. Warum haben sie das erfunden? Weil sie wettbewerbsfähig sein mussten. Diese Flexibilität und Geschwindigkeit sind genau die Wettbewerbsanforderungen, sie bringen Chaos in unsere Systeme. Das heißt, Chaos ist nicht das, was wir bewusst schaffen, weil wir es wollen, es entsteht, weil die Welt es verlangt. Wir müssen uns einfach anpassen. Und Chaos ist genau das Ergebnis des Wettbewerbs.
Bedeutet das, dass Chaos das Fehlen von Zielen ist? Oder sind es die Ziele, die wir nicht sehen wollen? Wir sind im Häuschen und verstehen die Ziele der anderen nicht. Wettbewerb entsteht tatsächlich durch die Tatsache, dass wir klare Ziele haben und wissen, wo wir in jedem nächsten Zeitpunkt ankommen werden. Das ist aus meiner Sicht der Kern von DevOps.
Auch eine Perspektive auf die Frage. Ich denke, dass unser Ziel alle das gleiche ist: zu überleben und das mit
maximaler Freude. Und das Wettbewerbsziel jeder Organisation ist dasselbe. Überleben geschieht oft im Wettbewerb, da kann man nichts machen.
In diesem Jahr findet die Konferenz am 7. Dezember im „Technopolis“ statt. Wir nehmen bis zum 11. November Anmeldungen für Vorträge entgegen. uns, wenn Sie sprechen möchten.
Die Registrierung für Teilnehmer ist geöffnet, das Ticket kostet 7000 Rubel. Schließen Sie sich an!
Quelle: habr.com
