Dieser Hubpost ist ein Interview mit Anton Weiss, Mitbesitzer der Technologiekonsultation Otomato Software, der über 15 Jahre Erfahrung in der Hochtechnologie verfügt. Er ist Experte für technische Ausbildung, Initiator und Mitautor des ersten DevOps-Zertifizierungskurses in Israel. Anton nimmt an internationalen Konferenzen teil und ist als herausragender Referent bekannt.
Wir werden folgende Themen besprechen:
Der Unterschied zwischen Russland und Israel
Oleg: Erzähl mir bitte, wer du bist und was du machst.
Anton: Ich bin Anton, in St. Petersburg geboren, aber mit 15 Jahren nach Israel gezogen und lebe seitdem dort. In den letzten zwanzig Jahren habe ich in Israel in verschiedenen IT-Bereichen gearbeitet. Von diesen zwanzig Jahren habe ich die letzten zehn mit allem verbracht, was mit der Softwarebereitstellung zu tun hat: Integration, dem, was früher als Configuration Management bekannt war, und dem, was jetzt DevOps genannt wird. Ich habe in großen Unternehmen gearbeitet — in internationalen Konzernen wie AT&T und BMC. Auch in Startups war ich aktiv. In den letzten vier Jahren habe ich meine eigene Unternehmensberatung, Otomato Software, wo wir Organisationen helfen, ihre Bereitstellungsprozesse zu optimieren und neue Werkzeuge zu erlernen: das heißt, wir übernehmen sowohl die technische Seite als auch alles Drumherum.
Oleg: Gibt es einen Unterschied zwischen Russland und Israel in Bezug auf die Arbeit?
Anton: Mit russischen Kunden habe ich fast nicht gearbeitet. Was mich in den letzten drei Jahren mit Russland verbindet, sind Konferenzen. Und in einigen russischen Unternehmen haben wir eine Art Audit durchgeführt: Wir sind gekommen, haben uns umgesehen, uns eingearbeitet, einige Empfehlungen herausgegeben und sind dann wieder gefahren. Das heißt, es gab keine wirklich alltägliche Arbeit, deswegen fällt es mir schwer, genau zu sagen, was anders ist. Ich denke, überall gibt es unterschiedliche Situationen. Zum Beispiel haben wir in Israel solche schweren Unternehmensorganisationen, in denen die Leute schon seit 15 Jahren arbeiten und alles sehr zäh vorangeht. Und egal, wie sehr sie versuchen, eine Transformation durchzuführen oder Prozesse zu verbessern: Sie reden und reden, aber… Wir haben einen Kunden, mit dem wir vor zwei Jahren alles umgesetzt und alle Entscheidungen getroffen haben, alle Programme entwickelt, und irgendwann kam alles zum Stillstand, und wir haben uns zurückgezogen. Vor ein paar Tagen habe ich die Chefs von dort getroffen, mit denen wir gearbeitet haben, und ich sage:
— Wie läuft es?
— Nun, es ist schwierig, — sagen sie — wir machen es, und jetzt fängt etwas an, sich zu bewegen.
Nach zwei Jahren gibt es Politiken und Einflusszonen. Es gibt Menschen, die diese Einflusszonen nicht loslassen wollen. In solchen Situationen ist es sehr schwierig, etwas zu ändern. Der Toolset hingegen entwickelt sich weiter. Auf der anderen Seite gibt es in Israel Startups, in denen sich alles sehr schnell ändert. Neue Tools aufzubauen, ist viel einfacher, und sie sind alle cloud-nativ und arbeiten vollständig in der Cloud. Das kann eine der sinnvollen Unterschiede zwischen Russland und Israel sein. In Israel ist es viel einfacher mit öffentlicher Cloud. Aus dem, was ich gesehen habe, scheint es in Russland für alle außer Startups sehr schwierig zu sein, in die öffentliche Cloud zu gehen, während es in Israel einfacher ist. Heute gibt es sogar ein gewisses Verständnis bei Banken und Versicherungsunternehmen, dass zumindest ein Teil ihrer Dinge in die öffentliche Cloud gehen kann. Und hier schrecken niemanden die Verträge mit Google und Amazon ab. Aus dem, was ich auf Konferenzen in Russland gehört habe, ist es dort immer noch komplizierter, selbst aus Sicht von Sanktionen und rechtlichen Fragen.
Der Unterschied zwischen Startups und Giganten
Oleg: Ich verstehe. Sag mal, wo arbeitest du lieber und angenehmer: in Startups oder in großen Organisationen?
Anton: Natürlich ist es angenehmer in Startups, denn in großen Organisationen … naja, in Wirklichkeit bewegt sich vieles sehr schwerfällig. Es gibt natürlich auch Vorteile. Wenn man sich große Organisationen anschaut, dann haben sie zum Beispiel viel mehr von dem, was man 'Diversity' nennt. Große Firmen sind einfach aufgrund ihres Bedarfs an vielen Mitarbeitern oder aufgrund einer über Jahre gewachsenen Unternehmenskultur bereit, verschiedene Menschen einzustellen. Hier in Israel, zum Beispiel, findest du in Startups kaum Araber, die sind fast nicht vorhanden. In großen Organisationen ist das viel einfacher. Startups entstehen oft aus einem kulturellen Hintergrund, in dem die meisten Teilnehmer hauptsächlich weiße Männer sind. Es herrscht eine Kultur, in der man sich richtig ins Zeug legen muss, und es ist wünschenswert, 10-12 Stunden am Tag zu arbeiten, und das ist auch schon wenig. Es scheint, als ob hinter uns Moskau (also Tel Aviv) steht, ein Zurück gibt es nicht, und deshalb müssen wir hier und jetzt bluten.
Oleg: Wie sieht es mit den Unterschieden im Ansatz zu DevOps in kleinen und großen Unternehmen aus? Das bedeutet, wenn du zum Beispiel mit nur zwei Personen arbeitest, musst du dich nicht um die Einrichtung von CI/CD kümmern, sondern kannst Artefakte über SCP kopieren.
Anton: Einerseits stimmt das. Andererseits bedeutet es heute nicht, dass du mit der Konfiguration von CI/CD tatsächlich Continuous Delivery machst. Es ist jedoch sehr einfach, dir einen Pipeline einzurichten, wenn du ein Unternehmen mit zwei Personen bist. Früher musste man eine Menge Aufwand betreiben, heute gibt es zahlreiche Cloud-Services. Du schreibst einfach YAML – und los geht's. Das ist einfacher. Tatsächlich stellen übergroße Startups eine Herausforderung dar. Wenn sie mehr als 20 Mitarbeiter haben, beginnen die Schwierigkeiten mit der Skalierung, weil es keine Prozesse gibt. Früher hat alles irgendwie funktioniert, aber dann entsteht das Chaos, und es ist unklar, wie wir diese frühere Dynamik bewahren und gleichzeitig Prozesse führen und entscheiden können, wer sich darum kümmern wird.
Und so beginnen all die Dinge wie "wir werden ein DevOps-Team haben, das für DevOps verantwortlich ist". Wir wissen, worauf das in den meisten Fällen hinausläuft: Ein Flaschenhals entsteht, und allmählich wachsen sie dorthin, wo sich jetzt große Unternehmen befinden. In großen Unternehmen gibt es ein ganz anderes Problem: Sie haben nicht einmal einen Flaschenhals, sondern ein so mächtiges Tor, das einmal am Tag geöffnet wird, und den Rest der Zeit sammelt sich dort eine riesige Menge an Müll. Und sie denken: "Wie können wir aus diesem Tor viele kleine Tore machen, die viel einfacher zu öffnen sind?" Also ganz andere Probleme. Startups haben das Problem, dass "wir in den Trichter eingesogen werden, wie kommen wir da wieder heraus?", und große Firmen — sie sind bereits im Trichter, sie sind schon im Untergrund, und jetzt denken sie darüber nach, wie sie wieder nach oben kommen.
Der Trend zur zunehmenden Komplexität und was man damit tun kann
Oleg: Und dazu kommt die technische Seite: Wenn du nur wenige Leute hast, einfache Technologien benötigst, musst du ein gewisses Basiswissen über Linux haben, und das war's. Aber bei der kleinsten Skalierung musst du etwas wie Kubernetes lernen, und das scheint ein Problem zu sein.
Anton: Und das ist zweifellos ein Problem. Wir hatten vor gerade mal zwei Tagen eine Konferenz, und es war sehr deutlich zu spüren, dass fast alle, die dort etwas sagten, ein Wort erwähnten: „Komplexität“. Das ist zu einem bestimmenden Begriff des gesamten DevOps-Discours von heute geworden.
Oleg: War das vor einem Jahr auch so?
Anton: In dem Versuch, alles schnell und dynamisch zu machen, um die berüchtigte Flexibilität zu erreichen, haben wir uns eine solche Komplexität aufgehalst. Tatsächlich gibt es sehr viele kleine Pipelines, die für sich genommen hervorragend funktionieren, und dann versuchen wir, aus all dem ein Gesamtbild zu erstellen, und genau dort entsteht plötzliche Komplexität. Denn aus all diesen kleinen Pipelines bauen wir jetzt einen einzigen Prozess, damit die gesamte Firma vernünftig arbeiten kann.
Oleg: Und welche Antwort gibt es? Wie geht man mit dieser Komplexität um?
Anton: Nein, es gibt keine Antworten, sie entstehen im Prozess. Mein Vortrag handelte von einer solchen Lösung. Im Wesentlichen führt das zu einer Frage: Ich war einst von systemischem Denken infiziert, das im DevOps oft erwähnt wird. Ich wurde neugierig, las Bücher von Peter Senge, Russell Ackoff, Donella Meadows – Menschen, die das systemische Denken in irgendeiner Form einführten und seine grundlegenden Postulate darlegten. Eine der zentralen Perspektiven, durch die systemisches Denken die Welt betrachtet, sind Rückkopplungsschleifen. Mit dieser Komplexität treten diese Rückkopplungsschleifen auf, das heißt, die Komplexität wird sehr hoch, und wir beginnen, Werkzeuge zu suchen, um diese Komplexität irgendwie zu zügeln. Ich spreche nicht davon, sie zu verringern – sondern sie zu zügeln, damit sie uns nicht überrollt.
Zentralisierte Lösungen erscheinen, im Wesentlichen sogar Kubernetes – das ist etwas Ähnliches. Du hast einen zentralisierten Control Plane, der, solange du ihn kontrollierst, die gesamte Komplexität der Dienste steuern wird, die rundherum laufen. Das Service Mesh, genau dieser Service-Mesh-Ansatz, ist eine Lösung desselben Typs. Wir sagen: 'Wir haben eine Menge Dienste, und sie müssen irgendwie miteinander kommunizieren, weil sie unklar verteilt sind und wir nicht wissen, ob sie antworten werden oder nicht, und sie schaffen es alleine nicht. Also lassen Sie uns jetzt so vorgehen, dass wir in der Mitte ein gewisses universelles Gehirn einsetzen, das ihnen sagt, mit wem sie sprechen können, mit wem nicht, und sie beschützt, falls ihnen plötzlich etwas Unhöfliches gesagt wird.' Und damit gibt es viele Fragen. Einerseits ist das eine Notwendigkeit, weil die Organisationen nicht zurechtkommen. In den letzten paar Jahren haben wir mehreren Organisationen geholfen, in die neue, mutige Welt des Cloud Native überzugehen, besonders wenn es mit dem Wachstum des Unternehmens und der Skalierung zu tun hat, und die Leute einfach verloren gehen. In der Mitte all dem befindet sich ein kleines Team sogenannter DevOps, das Tausende von YAML-Zeilen schreiben muss, um mit all dem irgendwie fertig zu werden, und alles reißt einfach auseinander.
Cloud Native
Oleg: Kannst du ein bisschen erklären, was Cloud Native bedeutet? Es ist ja zu einem Buzzword geworden, das jetzt überall an den Wänden steht. Wie siehst du das?
Anton: Im Grunde genommen begann alles mit dem Ansatz „Platform as a Service“. Das bedeutet, dass wir viel mehr Software und Web-Services bereitstellen mussten als früher. Wir haben erkannt, dass wir jeden Service nicht mehr einzeln wie ein geliebtes Haustier behandeln konnten, das wir bei Namen nennen und ein Leben lang pflegen. Stattdessen mussten wir lernen, mit ihnen wie mit einer Herde umzugehen. Dafür brauchen wir eine einheitliche Plattform, auf die wir diesen Code werfen können, und die Plattform muss intelligent genug sein, um ihn zu verwalten. Eine Art automatische Tränke- und Futterstelle für den Service.
Pioniere dieses Ansatzes waren Heroku. Sie sagten, dass diese Dienste, um unsere Infrastruktur nutzen zu können, auch bestimmte Eigenschaften haben müssen. So entstand die 12-Faktor-App, die so wenig stabilen Zustand wie möglich enthalten sollte. Eine solche Anwendung wird unbedingt in einer Art Pipeline erstellt, in der ihre Kompatibilität mit der Plattform überprüft wird. Sie muss resilient sein — wissen, dass man, wenn etwas schiefgeht, nicht sofort abstürzen sollte. Andererseits sollte man in gewissem Sinne auf die Plattform vertrauen. Im Großen und Ganzen ist es ein gewisser Hybrid. Man muss verstehen, dass man nicht für sich allein ist, dass es eine Plattform gibt, und dass man ihre Einschränkungen respektieren muss. Letztendlich begann alles dort.
Doch irgendwie hat sich dieser Ansatz "Plattform als Dienst" nicht bewährt, und der versprochene Boom ist ausgeblieben. Es gab Heroku, und danach haben sofort alle großen Anbieter aus diesem Bereich entsprechende Lösungen entwickelt: Google App Engine, und bei Amazon — Elastic Beanstalk. Ich habe viel mit Unternehmen gearbeitet, die damit begonnen haben. Aber in dem Moment, in dem man etwas macht, das ein wenig über die von der Plattform erlaubten Grenzen hinausgeht, verwandelt sich das in einen schrecklichen Kopfzerbrechen. Man beginnt auf Wände zu stoßen, die überall vorhanden sind. Und wie es den Menschen eigen ist, wenn sie auf Wände stoßen, fangen sie an, Wege zu suchen, um diese Wand zu durchbrechen.
Moderne Cloud Native ist hier entstanden: Wie man weiterhin in der Cloud arbeitet, Plattformdienste nutzt und gleichzeitig außergewöhnliche Flexibilität gewährleistet. Wir balancieren ständig zwischen Flexibilität und Einfachheit. Flexibilität führt zu Komplexität, während Vereinfachung und der Aufbau einer klaren Plattform immer Einschränkungen mit sich bringen. Cloud Native ist anscheinend das Finden eines Gleichgewichts zwischen den Einschränkungen der Cloud-Plattform und der Flexibilität, die dir die Cloud mit ihrer automatischen Skalierung bietet, und all das hat seinen Preis.
Oleg: Wahrscheinlich muss sich die Organisation irgendwie lernen, prozessual mit all dem umzugehen.
Anton: Natürlich, natürlich! All das hat Auswirkungen. Mikroservices fallen auch darunter. Im Grunde genommen ist es die Vorstellung, dass wir kleine Services und Anwendungen haben, die in der Cloud verteilt sind und zu jedem Zeitpunkt irgendwo sein können. Heute gibt es vielleicht 10 Instanzen, morgen könnten es 1500 sein; das gehört ebenfalls zu Cloud Native. Die Vorstellung ist, dass wir nicht durch die physischen Grenzen eines Rechenzentrums eingeschränkt sind. Im Grunde genommen ist die ganze Welt meine Cloud — das ist eine wirklich bemerkenswerte Vision und ein großartiges Ziel, aber es hat seinen Preis. Dieser Preis ist Komplexität; die Herausforderung ist, dass niemand sich vorstellen kann, was passiert, wenn unsere Anwendung plötzlich von 10 Instanzen auf 1500 wächst. Niemand kann sich so etwas vorstellen, und damit beginnen alle Artefakte des Skalierens aufzutauchen. Wir als Menschen, als Betreiber, können nichts dagegen tun, außer auf das aufkommende Chaos zu reagieren. Und dann fangen wir an zu überlegen: „Wie können wir unsere Anwendung und unsere Infrastruktur so gestalten, dass wir, wenn diese Artefakte entstehen, sie erstens vorhersehen und zweitens irgendwie mit diesen Artefakten umgehen können und weiterhin funktionsfähig bleiben?“
Kombination technischer und nicht-technischer Fähigkeiten
Oleg: Du hast Vorträge über technische Dinge, zum Beispiel und es gibt Vorträge über Führung, über Management und so weiter. Bist du insgesamt eher eine technische Person, oder bist du ein Manager, oder ist es bei dir irgendwie anders?
Anton: Ich habe sogar irgendwann angefangen, darüber einen Post zu schreiben, habe ihn aber noch nicht zu Ende gebracht. In gewisser Weise fühle ich mich persönlich zwischen diesen beiden Dingen hin- und hergerissen, weil ich einerseits gerne verstehe, wie Dinge funktionieren und damit arbeite. Wenn ich es schaffe, ein technisches Problem zu lösen, gibt mir das einfach ein unglaubliches Gefühl meiner Fähigkeiten, das, was man instant gratification nennt: "Oh, cool, ich kann es, ich habe es gelöst." Und davon ist es schwer, loszukommen. Und weil das so ist, mache ich weiterhin technische Dinge. Neue Technologien begeistern mich: es ist großartig, etwas zu erkunden und zu verstehen. Deswegen ergibt es sich, dass Menschen diese Kenntnisse kaufen wollen, und ich verkaufe sie weiter.
Auf der anderen Seite verstehe ich, dass dies nur ein kleiner Teil eines großen Ganzen ist. Ich habe lange genug in der Branche gearbeitet und kann nicht übersehen, dass Technologie nur ein Aspekt eines umfassenderen Systems ist, nur eine von vielen Komponenten. Ich habe Teams geleitet und verstehe, wie wichtig es ist, die Interaktion von Technologien und Werkzeugen mit den Menschen, die sie nutzen, zu berücksichtigen. Schließlich existieren Informations- und jede andere Technologie, damit Menschen sie benutzen. Technologien zu entwickeln, ohne darüber nachzudenken, wer sie verwendet, ist vollkommen sinnlos. Technologie an sich ist nicht interessant, wenn man nicht an ihre Anwendung denkt, und diese Anwendung ist immer mit den Menschen verbunden, die davon profitieren. Daher interessiert mich alles, was mit Technologien zu tun hat, ebenfalls sehr. Ich habe das Gefühl, dass darüber gesprochen werden muss, ich verstehe, dass alles ohne dieses Verständnis tatsächlich seinen Sinn verliert. So sehr, dass ich manchmal das Vergnügen habe, zwei bis drei Tage oder sogar Wochen an etwas zu tüfteln. Ich kann mich von einem Problem mitreißen lassen, das ich nicht lösen kann, und dann kann ich es lösen und einen großartigen Nutzen daraus ziehen. Doch dann hebe ich den Blick von der Tastatur, schaue mich um und erkenne, dass um mich herum etwas geschieht, das ich auf keinen Fall ignorieren kann. Und dann wird mir das Coden und das Herumspielen mit Linux völlig uninteressant und unwichtig, und ich möchte beginnen, Probleme auf einem anderen Level, auf menschlicher Ebene zu lösen.
Wie kann man sich schnell in DevOps zurechtfinden?
Oleg: Sag mal, kannst du etwas empfehlen für Leute, die gerade gleichzeitig Ingenieurwesen betreiben und die Praktiken von DevOps lernen? Wie kann man das alles unterbringen und in welcher Reihenfolge? Sozusagen, wie könnte man seine Karriere planen, um in kurzer Zeit erfolgreicher zu werden?
Anton: Tja… Es gibt keine universellen Ratschläge, zumindest nicht aus meiner Erfahrung. Ich war lange, wahrscheinlich die ersten 10 Jahre meiner Karriere, mit meinem Platz unzufrieden. Ich habe gesucht, was mir nicht gefallen hat, darauf fokussiert und nach interessanteren Beschäftigungen gesucht. Doch im Großen und Ganzen habe ich nichts unternommen. Der wichtigste Rat ist… Wann habe ich das Gefühl, dass meine Karriere einen Aufschwung nahm? Als ich anfing, über Dinge zu sprechen, die mich interessierten. Der Bereich des technischen Wissens, nicht nur technisch, sondern generell die Welt der Informationstechnologien ist sehr breit. Man kann sowohl Techniker sein: Entwickler, Tester, Integrator oder Systemadministrator – alles sind das unterschiedliche Dinge, wo jeder seine Nische finden kann. Wenn du nicht vollständig Techniker sein willst und dich sowohl technische als auch geschäftliche Themen interessieren, beschäftige dich mit Produktmanagement oder Projektmanagement. Es gibt viele Nischen, finde die, die dir gefallen wird.
Aktuell wird viel über Fachleute im „T“-Format gesprochen. Man muss verstehen, wo der Fuß deines Ts steht, etwas auswählen und dort anfangen zu graben. Beim Graben entdecken sich erstaunliche Tiefen. Aber man kann überall graben. Ich bin mir bewusst, dass es viele Bereiche gibt, in die ich nicht tief gegraben habe, weil ich es versucht habe, aber festgestellt habe, dass es nicht mein Bereich ist. Dort, wo es für dich interessant ist zu graben, mach weiter, und es ist sehr wichtig, darüber zu sprechen. Ich verstehe auch, dass das nicht für jeden ist. Aber selbst hier hat jeder verschiedene Ausdrucksformen: Vielleicht passt es jemandem, Blogs zu schreiben. Wenn du keine literarischen und humorvollen Blogs schreiben kannst, schreib einfach technische Blogs, veröffentliche Gists auf GitHub. Hast du ein Problem gelöst? Dann veröffentliche es.
Letztlich geschieht die Karriereentwicklung heute durch das Teilen von Wissen. Es ist kein Zufall, dass im DevOps der Wissensaustausch eine so große Bedeutung hat. Alle profitieren davon, und auch du selbst gewinnst immer, wenn du dein Wissen teilst. Jeder, der seinen Code Open Source gemacht hat, weiß, wie wichtig es ist, den Code zu überarbeiten und ganz anders zu denken, wenn du ihn jemand anderem zur Verfügung stellst; du verstehst, dass jemand anderes damit arbeiten wird. Dabei kommen die soziotechnischen Aspekte ins Spiel, von denen ich sprach. Du beginnst zu begreifen, dass es sich nicht nur um Code handelt, sondern um Code, den jemand anderes lesen wird. Vielleicht möchte er ihn ändern, also muss er verstehen, was dieser Code macht. Und wenn diese Interaktionen entstehen, beginnst du bereits in deinem Kopf, mit anderen Menschen zu interagieren. Die Karriere eines Menschen entwickelt sich nur durch die Interaktion mit anderen Menschen. Letztlich, was ist Karriere? Karriere bedeutet, dass ich für mehr Menschen nützlich und wichtig werde. Ich erwerbe Wissen, das für mehr Menschen gebraucht und nützlich ist. Dafür ist es notwendig, zu verstehen, was diese Menschen wollen und was sie brauchen. So ist das immer. Am Ende dreht sich alles um die Menschen.
Oleg: Angenommen, wir sind großartig und beschäftigen uns mit DevOps, neuen Praktiken und Ähnlichem. Es gibt diejenigen, die das wissen und respektieren, und dann gibt es alle anderen. Stell dir vor, du arbeitest in einem Team, besonders in einem großen Unternehmen, wo dies noch… sagen wir, höflich, nicht gut bekannt und nicht sehr geschätzt ist. Gibt es Möglichkeiten, wie man all diese Ideen einführen kann? Wenn du kein Vorgesetzter bist. Klar, wenn du der Vorgesetzte bist, kannst du einfach sagen: „Führen wir das morgen ein“. Aber was ist, wenn du eine normale Person bist und du verbessern möchtest?
Anton: Erstens ist es nicht garantiert, dass es funktioniert, wenn du als Chef sagst: „Führen wir das morgen ein“. Die Leute werden Aufgaben erledigen, aber das bedeutet nicht, dass ein tiefes Verständnis dafür, warum das eingeführt wird, von selbst kommt. Zudem mag niemand Veränderungen, besonders wenn ihnen gesagt wird: „Du musst dich ändern.“
Oleg: Was tun?
Anton: Schau, ich war in dieser Position und habe solche Prozesse tatsächlich von Grund auf umgesetzt, anfangs als einfaches Teammitglied und später als Teamleiter. Der einzige Ansatz, der funktioniert, ist der des Drogenhändlers. Das nenne ich "Zusammenarbeit, basierend auf dem Bewusstsein, dass du Dienstleistungen anbietest" – also dienstleistungsorientierte Zusammenarbeit. Grundsätzlich weißt du, dass da Leute um dich herum sind, die du als deine Kunden wahrnehmen kannst. Wir bieten etwas an, und jemand anderer nutzt das. Im einfachsten Szenario, das Agile einst beschrieben hat: Ich bin Entwickler, ich habe einen Kunden, entsprechend muss ich verstehen, was mein Kunde will, um Software effizient entwickeln zu können.
In einem großen Unternehmen habe ich oft keinen direkten Kontakt zum Kunden oder Nutzer. Aber um mich herum sind Menschen. Zum Beispiel schreibe ich eine Bibliothek — andere integrieren sie, ich entwickle ein Backend — da habe ich Frontend-Entwickler, die damit kommunizieren müssen. Ich schreibe Code — da gibt es Tester, die entweder Tests für mich schreiben oder ich gebe ihnen Versionen, die sie testen können. Im Wesentlichen muss ich einfach darüber nachdenken: „Ich bin der Dienstleister, ich habe Kunden. Am besten funktioniert alles, wenn ich dafür sorge, dass meine Kunden zufrieden sind. Wenn meine Kunden zufrieden sind, dann bin ich es auch. Ich werde anscheinend nicht nur meinen Ruf aufbauen, sondern gewinne auch positive Beziehungen und bekomme gutes Feedback.“ Und zurück zu der Herangehensweise eines Drogenhändlers: Ich möchte, dass diese Kunden zu mir zurückkommen, um mehr von dem Gleichen zu bekommen.
Das heißt, wenn ich der Meinung bin, dass ein bestimmter Ansatz richtig ist, zum Beispiel Continuous Integration mit Tests… Es gibt Programmierer, für die es heute beispielsweise schwierig ist, ihre Arbeit zu testen. Es muss dafür gesorgt werden, dass sie darüber nicht zu viel nachdenken müssen, sondern diese Tests so einfach wie möglich erhalten. Heute wirkt das recht banal, vor 10 Jahren war das jedoch alles andere als trivial: In dem Moment, als ich meinen Code gepusht habe, sollte alles automatisch irgendwo gebaut und bereitgestellt werden, und nur wenn ein Fehler aufgetreten wäre, hätte ich eine Nachricht erhalten, während ich in der Zwischenzeit in Ruhe einen Kaffee trinken und nicht daran denken konnte, dass ich jetzt die Kompilierung auf meinem Computer starten muss, um alle benötigten Tools zu haben, denn das war auch eine Nervenaufreiberei. Wenn man also die Kopfschmerzen reduzieren kann, gewöhnt man sich daran. Wir sehen das alle: In dem Moment, in dem du einen gut funktionierenden Pipeline hast, können sich alle, die ihn nutzen, ihr Leben ohne ihn nicht mehr vorstellen. Wenn ich etwas ändern möchte, muss ein Prozess geschaffen werden, von dem die Menschen eine gewisse emotionale Abhängigkeit entwickeln.
Oleg: Gut. Viele Menschen hoffen, dass irgendein König, ein großer Führer, etwas anderes kommt und ihnen sagt, wie sie leben sollen, und danach werden alle natürlich in eine neue, mutige Welt mit DevOps oder etwas anderem übertreten. Ist ein solcher König notwendig?
Anton: Nein, ein König, der erzählt, wie man leben soll, ist keineswegs notwendig. Ein Vorgesetzter, der bereit ist, seinen Mitarbeitern zuzuhören, ihnen zu vertrauen und sie darin zu unterstützen, ihre Arbeit so zu machen, wie es ihnen am bequemsten und richtigsten erscheint? Ja, eine solche Person ist notwendig, denn ohne sie wird es einfach ein Kampf. Und der Kampf der Untergebenen gegen ihre Vorgesetzten endet nie gut. Am Ende wird es für jemanden ganz sicher schlecht ausgehen, entweder für den Vorgesetzten oder für die Untergebenen.
Das Problem ist jedoch, dass es sehr schwierig ist, den Menschen zu sagen, was sie tun sollen und was nicht. Letztendlich tun sie das, was ihr kultureller Hintergrund, ihr Ego oder ihr momentaner emotionaler Zustand sie leitet.
Die nützlichsten Praktiken und Technologien aus der Welt von DevOps
Oleg: Übrigens werden gerade jetzt eine Vielzahl von Praktiken propagiert: Es gibt Ansätze von Google, Ansätze von Netflix und von verschiedenen Referenten auf Konferenzen. Sag, welche Praktiken du als besonders nützlich empfindest?
Anton: Das Problem der meisten Organisationen, egal ob groß oder klein (insbesondere Start-ups sind davon stärker betroffen), ist, dass sie keine Sichtbarkeit der Prozesse haben — kein Verständnis dafür, wie wir insgesamt arbeiten, wie wir Software liefern und wo Dinge ins Stocken geraten. Ich empfehle normalerweise eine Übung, die aus dem Ansatz des Lean Management stammt — sie heißt Value Stream Mapping. Kартierung des Wertstroms. Das erfordert eine gewisse Bereitschaft, die Hauptakteure der Organisation in einen Raum zu bringen, alle Personen, die irgendwie am Lieferprozess beteiligt sind: diejenigen, die notwendige Änderungen definieren, Produktmanager, Projektleiter, Entwickler, Tester, Systemadministratoren und sogar Vertriebsmitarbeiter, die mit den Kunden arbeiten. Versammelt sie alle und versteht, wie Änderungen in der Software stattfinden und welchen Weg sie normalerweise nehmen.
Es scheint ganz trivial zu sein: was ist da los? Jemand hat es sich ausgedacht – jemand hat es kodiert, wir haben eine Pipeline, es wurde durchlaufen – und jetzt ist es fertig. Ja, wir wissen, dass der Build hier viel Zeit in Anspruch nimmt, das werden wir lösen. Ja, wir wissen, dass Programmierer derzeit nicht auf ihren Computern kompilieren können, weil sie Java haben, und dafür braucht man sehr viel Speicher – auch das wissen wir, das werden wir lösen. Und ich komme häufig zu Organisationen, und sie sagen:
— Hier muss das automatisiert werden, das muss gelöst werden.
— Sind Sie sicher, dass wir damit überhaupt anfangen sollten? Woher wissen Sie das?
— Nun, wir wissen es definitiv nicht, aber wir spüren, dass dort ein Schmerzpunkt ist.
Es gibt , die besagt, dass es letztlich nichts löst, das Problem an einem Ort zu behandeln, der keine Einschränkung ist – das macht die Problematik nur komplizierter. Was vielen fehlt, ist das Verständnis davon, wo Dinge stecken bleiben und wie sie fließen.
Manchmal versammelt man einfach verschiedene Leute, einer sagt:
— Hier geht der Release in diesem Moment zur Genehmigung dorthin.
Ein anderer sagt:
— Nein, das ist nicht so, bei uns geht das nicht. Hier warten wir auf die Umgebung für Lasttests.
Oder Spezialisten sagen zum Beispiel:
— An dieser Stelle machen wir normalerweise alles von Hand.
Die Programmierer sagen dann:
— Aber wir haben doch einen automatisierten Prozess dafür. Warum nutzt ihr ihn nicht?
Die Tester antworten:
— Wir wussten nicht, dass es den gibt.
Jedes Team sieht nur seinen eigenen Teil, und niemand hat das große Ganze im Blick — das beeinflusst unsere Fähigkeit, Software effizient auszurollen oft viel stärker, als die bloße Verfügbarkeit eines Tools. Diese Aspekte sind entscheidend. Wir sollten mit der Prozesskartierung beginnen. Klar, wenn in der Firma derzeit kein CI/CD vorhanden ist — das ist schon alte Schule. Wir wissen, dass man auch das aufbauen muss. Aber zuerst sollte man die Frage klären, wie viel man investieren möchte und welche Probleme dadurch gelöst werden. Dazu braucht man ebenfalls Leute, die wissen, wie man das richtig macht.
Oleg: Technisch gesehen, auf welche Technologien sollte man achten? Es ist klar, dass man über simples CI/CD nicht mehr reden muss. Welche spannenden neuen Technologien sollte man sich anschauen?
Anton: Zunächst einmal ist für alle offensichtlich, dass Container gewonnen haben. Daher sollten diejenigen, die noch keine Container nutzen, sich unbedingt damit befassen und so schnell wie möglich einen Blick darauf werfen, denn die Bewegung geht in diese Richtung. Auch große Unternehmen verstehen bereits, dass sie ihre Software in Container packen müssen. Auf der Plattformebene hat Kubernetes den Sieg davongetragen: egal, ob in der Cloud oder nicht – wir werden unseren Kunden eine Lösung mit Kubernetes anbieten. Jetzt hat auch VMware angekündigt, dass sie Kubernetes direkt auf dem Hypervisor haben werden. Es ist also klar, Google hat gewonnen. Das war allgemein niemanden ein Überraschung.
Oleg: Hat Google gewonnen?
Anton: Wenn wir uns vor ein paar Jahren umsehen, war es nicht ganz klar, ob Swarm oder Kubernetes die Zukunft sind und ob Docker überleben wird. Docker ist ganz offensichtlich tot. Alle, einschließlich Microsoft und Amazon, haben zusammen daran gearbeitet – „lasst uns Docker gemeinsam besiegen“. Docker wurde besiegt! Aber letztendlich war Docker selbst schuld. Sie dachten, sie könnten kommen, alles auf den Kopf stellen, sich nicht verkaufen wollen und gleichzeitig gegen alle gewinnen, auch gegen Google, Microsoft und Amazon? Die Chancen, dass das gelingt, waren sehr gering. Anscheinend haben sie nicht die richtigen Freunde gefunden. Wenn du mit niemandem verbündet bist, bist du am Ende verloren. Genau das ist passiert.
So ist das. Deshalb muss man Container im Auge behalten. Container und Orchestrierung werden heute immer mehr zur Norm. Das heißt, die Berichte auf Konferenzen lauten bereits: „Mit Kubernetes zu beginnen, ist nie zu spät, selbst wenn Sie Rentner sind“. Das ist also wichtig. Rund um Kubernetes passiert aktuell eine Menge Interessantes. Eine der coolen Funktionen von Kubernetes ist im Grunde die Schaffung einer universellen API, die es uns ermöglicht, alles zu beschreiben, was in unserer Infrastruktur passiert. Im letzten Jahr haben wir versucht, rund um diese API eine Menge weiterer Technologien zu entwickeln. Das Service Mesh ist ein solches Beispiel: Fast alle Implementierungen eines Service Mesh, die derzeit existieren, sagen in gewisser Weise: „Wir erweitern die API, wir fügen Intelligenz hinzu, wir beschreiben Objekte außerhalb von Kubernetes, aber wir lesen die Objekte aus Kubernetes und wissen so, was zu tun ist“.
Ein weiteres Beispiel ist das, was derzeit mit der Continuous Delivery Foundation geschieht, die vor etwa anderthalb Jahren ins Leben gerufen wurde. Wiederum handelt es sich um Google, CloudBees und GitLab. Es gibt das Google-Projekt Tekton, dessen Hauptidee die Schaffung einer universellen API zur Beschreibung des Continuous Delivery-Prozesses ist. Im Großen und Ganzen versuchen sie, alles in bestimmte Objekte zu zerlegen, die zwingend in einem Continuous Integration / Continuous Delivery-System vorhanden sein müssen, und in irgendeiner Weise zu ermöglichen, diese Dinge in Kubernetes zu verzeichnen, damit verschiedene Komponenten diese Definitionen lesen und entscheiden können, was damit zu tun ist. Bei den Service Meshes geschieht das Gleiche, darüber habe ich auf meinem . Microsoft arbeitet derzeit an einer Spezifikation, die festlegt, was ein Service Mesh tun sollte, dem sogenannten SMI Spec. Die Idee ist, dass jede Implementierung eines Service Mesh in der Lage sein wird, alles aus dieser Spezifikation sowie noch weitere Funktionen zu erfüllen.
Deshalb hat Kubernetes gewonnen. In dem Moment, in dem du zur Plattform für weitere Innovationen wirst, ist es sehr schwierig, dich später einfach loszuwerden, denn darauf wurde bereits aufgebaut. Kubernetes einfach wegwerfen, das wäre, als würde man das Baby mit dem Badewasser ausschütten.
Welche Vorträge sollte man besuchen
Oleg: Welche Vorträge besuchst du selbst, was hältst du für interessant?
Anton: Zunächst einmal, wenn es eine neue technische Funktion oder ein Gadget gibt, das ich noch nicht selbst gesehen habe, und es einen Redner gibt, der in der Lage ist, darüber verständlich zu berichten, dann betrachte ich das als einen großen Vorteil. Denn anstatt jetzt selbst zu lesen, zu graben und möglicherweise Schwierigkeiten beim Verstehen zu haben, kannst du einfach kommen und in einer halben Stunde hören, wie jemand dir das zeigt und erklärt. Dafür sind natürlich bestimmte Fähigkeiten und der Wille erforderlich, über Technologie zu sprechen. Ich verstehe, dass das auch nicht einfach so kommt; man muss daran arbeiten. Ich habe dafür auch viel Zeit gebraucht. Übrigens hat mir meine Tätigkeit im technischen Unterricht dabei sehr geholfen. Wenn du vor einer Klasse stehst und den Leuten etwas erklären musst, und du bemerkst, dass sie einfach nicht verstehen — dann kommt dir die Erkenntnis, dass die Probleme wahrscheinlich in der Art und Weise liegen, wie du es erklärst, und nicht darin, dass die Leute dumm sind.
Oleg: Was genau ist technischer Unterricht? Was machst du da?
Anton: Ich unterrichte seit etwa 7-8 Jahren technische Fächer. Angefangen hat alles mit Maven und Shell-Scripting, das ich ein Jahr lang gelehrt habe. Da ich mich intensiv mit Jenkins beschäftigt habe und umfangreiche Kenntnisse darüber habe, habe ich den Leuten die Arbeit mit Jenkins und die Administration beigebracht. In den letzten Jahren habe ich alles unterrichtet, was mit Cloud Native zu tun hat: Kubernetes, Container und alles, was dazugehört. Bald fahre ich nach London, um einen Workshop über Istio zu geben. Das ist nicht mein Hauptbeschäftigungsfeld, aber etwa einmal im Monat oder alle zwei Monate halte ich Workshops.
Oleg: Geht es dir hauptsächlich um den Vortrag, das Thema oder die Person?
Anton: Wenn ich weiß, dass der Referent gut ist, gehe ich einfach zu der Person, weil es mir auch sehr wichtig ist, von anderen zu lernen, wie man gut erzählt. Lernen ist immer wichtig. Wenn es ein Thema gibt, und ich den Referenten nicht kenne, gehe ich mal vorbei, aber das ist meistens so wie bei einem Stand-up: Ich schaue mir die ersten 10-15 Minuten an, wenn es nicht gefällt – gehe ich. Oder es gibt Referenten, zu denen ich auf jeden Fall gehe, weil sie immer interessant erzählen, selbst Dinge, die du schon weißt, schaffen es, aus einer neuen Perspektive gezeigt zu werden, was dir hilft, die ganze Frage neu zu betrachten. Von den Leuten, die mir in letzter Zeit gefallen... Zunächst einmal gibt es Simon Wardley – einen Berater, der seine eigene Methode zum Zeichnen von Karten hat. Mit Hilfe von Karten erklärt er, wie Unternehmen ihre Strategie richtig gestalten können. Er war einmal CTO, CEO von Start-ups, er spricht viel darüber, über die Technologie. Er setzt sich übrigens ständig für Serverless ein und sagt, dass die, die heute kein Serverless machen, große Probleme haben werden.
Oleg: Das ist der Typ, bei dem ? Он её в виде постов сделал. Ein ungewöhnliches Format.
Anton: Er erzählt wirklich sehr interessant. Seine Vorlesungen in den letzten 2-3 Jahren sind mir am meisten im Gedächtnis geblieben. Nun, John Willis, der letztes Jahr zu DevOops kam — einfach weil er . Es gibt allerdings ein gewisses Problem mit ihm, da er sehr viel über die amerikanische Realität spricht, Dinge, die manchmal einfach nicht auf die russische oder israelische Realität anwendbar sind. Sie haben dort momentan einen Konflikt mit irgendeinem Change Approval Board, über das sie ständig sprechen. Das ist offenbar eine Sache, die in amerikanischen Unternehmen existiert; dort gibt es einen Prozess zur Durchführung und Genehmigung von Änderungen in der IT, der durch bestimmte Komitees führt.
Oleg: Aber bei uns gibt es das nicht — ich verstehe überhaupt nicht, wovon du sprichst.
Anton: Ich verstehe das auch nicht wirklich, in Israel gibt es so etwas auch nicht. Aber dort sprechen sie ständig darüber. Wenn man all diese Leute hört, wie DORA, die , schreiben sie auch viel darüber. Ich meine nur, dass die Leute von einem Problem sprechen, das nur bei ihnen existiert, und es interessiert dich überhaupt nicht.
Oleg: Du warst beim letzten DevOops, welche Vorträge sollte man dort besuchen und sich die Aufzeichnungen anschauen?
Anton: Siehe . Das Thema interessiert mich ein wenig – ich werde hingehen.
Oleg: Da gibt es einen Anton Weiss, glaube ich. Wahrscheinlich sollte ich mir ihn ansehen.
Anton: Nein, geh nicht zu ihm, das ist total langweilig 🙂
Oleg: Nun gut, vielen Dank. Das war großartig! Ich sehe, dass du schon einen Vortrag für die nächste Konferenz eingereicht hast. Lass uns beim nächsten DevOops wiedersehen!
Konferenz Es findet am 29.-30. April statt, diesmal – in Moskau. Den Inhalt der Konferenz haben wir im Voraus auf Habré beschrieben. . Das Programm wird aktiv zusammengestellt (bis zur Konferenz sind es noch viele Monate), aber die ersten Sprecher sind bereits . Dort kann man auch .
Quelle: habr.com
