Überlegungen eines DevOpsologen

"DevOps ist die Verbindung von Menschen, Prozessen und Produkten, um eine kontinuierliche Bereitstellung von Werten für unsere Endbenutzer zu ermöglichen." Donovan Brown

Im Herzen bin ich ein Entwickler. Ich liebe es, Code zu programmieren und Teil eines Teams zu sein, das Code programmiert. Aber ich bin auch von Menschen fasziniert - und die Überschneidung von Kultur und Technik ist es, die mich zu DevOps geführt hat.

Wenn ich über meine Reise nachdenke, sehe ich eine Menge Menschen, die in mich investiert haben. Ohne sie wäre ich heute nicht da, wo ich bin. Im wahrsten Sinne des Wortes - ich bin ein Einwanderer in die USA und meine Karriere hat mich hierher gebracht. Ich habe auch hart gearbeitet, als sich mir die Gelegenheit bot. Ich wurde von einem Mentor betreut und habe andere als Mentor betreut. Ich habe auf meinem Weg einige Dinge gelernt, die ich hoffentlich durch meine Geschichte weitergeben kann.

Aber Moment - bevor ich anfange: Was ist ein DevOpsologist? Ich weiß nicht mehr, woher ich den Begriff habe (er stammt nicht von mir), aber ich finde ihn toll. Er kommt von DevOps und dem Suffix "-ologie" (das Studium von etwas, ein Zweig des Lernens). DevOps entwickelt sich ständig weiter und verändert sich, und ich glaube nicht, dass wir jemals "ankommen" werden. Mich selbst als DevOpsologist zu bezeichnen, erinnert mich daran, dass es immer mehr zu lernen gibt!

Die Geschichte

Die Reise beginnt

Es war im Sommer 2004 (zumindest auf der südlichen Halbkugel). Ich war gerade von Johannesburg nach East London, Südafrika, gezogen, wo ich in einem Team von etwa 20 Entwicklern für ein Finanzdienstleistungsunternehmen arbeitete. Ich war als Senior-Entwickler eingestellt worden - und ich ahnte nicht, dass die nächsten sechs Jahre einen Großteil meiner Karriere bestimmen würden.

Ich hatte den Job jetzt etwa drei Monate inne. Mein vorheriger Job hatte nicht annähernd etwas mit Microsoft zu tun gehabt. Es war alles C++, CORBA und Linux. Jetzt war ich hier, ein leitender Entwickler in einem Team, das SQL Server und Webdienste auf der Grundlage von .NET Framework 1.1 verwendete. Ich hatte zuvor CVS für die Versionskontrolle verwendet, und das neue Team setzte WinCVS ein. Es war nicht schön. Es gab so gut wie keinen Prozess - wir verwendeten die Funktion "Veröffentlichen mit der rechten Maustaste" von Visual Studio und Fatfingering war so üblich, dass es erwartet wurde.

Ich erinnere mich, dass ich dachte: "Ich bin vielleicht nicht der erfahrenste .NET-Entwickler, aber es muss doch einen besseren Weg geben, um die Bereitstellung von Code zu verwalten." Also öffnete ich einen Browser und benutzte meine Lieblingssuchmaschine, WebCrawler, um zu sehen, ob ich etwas Besseres finden konnte.

Und das habe ich getan. Ich fand ein Tool, das so neu war, dass es sich noch in der Beta-Phase befand. Die Installation dauerte etwa eine Woche. An einem Punkt schlug die Installation fehl und ich konnte sie nicht wiederherstellen. Der Fehler war sogar so schlimm, dass ich schließlich den gesamten Rechner formatierte und neu startete. Aber ich blieb hartnäckig - und konnte schließlich eine glänzende neue Instanz von Team Foundation Server (TFS) 2005 beta 2 aufsetzen.

Die glorreichen TFS-Tage

So begann meine Reise zu DevOps. Nur dass der Begriff DevOps noch nicht geprägt worden war. Er lautete noch "Application Lifecycle Management" (ALM). Ich glaube, ich habe diesen Begriff bis etwa 2008 nicht einmal gehört. Aber auch wenn ich nicht wusste, wie es genannt wurde, habe ich es getan. Meistens aus Instinkt.

Wir haben damit begonnen, unseren gesamten Code in TFS zu speichern. Wir begannen sogar mit automatischen Builds mit MSBuild! So konnten wir wenigstens von einer bekannten Quelle der Wahrheit aus bauen, anstatt zu hoffen, dass das, was wir auf unseren Entwicklungsmaschinen hatten, der neueste Code war.

Unsere nächste Phase war die Einführung von Unit-Tests. Ich erinnere mich an einige sehr hitzige Debatten mit dem Team. "Wir haben zu viel Code und unsere Abdeckung wird praktisch null sein!", war eine gängige Meinung. Es gelang mir, das Team davon zu überzeugen, dass eine Codeabdeckung von 0,2 % besser ist als 0 %. Also begannen wir damit, dass wir bei jeder Änderung an einer Methode (oder beim Hinzufügen einer Methode) nur dann eine Implementierung vornahmen, wenn wir einen Unit-Test für den geänderten Code hatten. Schon bald lagen wir bei der Codeabdeckung im Bereich von 60%. Kleine, inkrementelle Änderungen hatten mit der Zeit eine große Wirkung.

Wir begannen auch mit dem Work Item Tracking. Wir haben alle eine Prince2-Schulung absolviert (eine Variante des Wasserfallmodells der britischen Regierung) und unsere Vorlagen, Work Items und Berichte entsprechend angepasst. Damals mussten wir unser eigenes Tool für das Release Management entwickeln, da es in TFS erst Jahre später ein solches Tool gab.

Zu Beratung springen

Im Jahr 2008 nahm ich an der TechEd Africa in Durban, Südafrika, teil. Das war meine erste Erfahrung mit einer großen Tech-Konferenz. Ich besuchte einen Vortrag von Chris Menegay, der ein kleines Beratungsunternehmen in Dallas, Texas, namens Notion Solutions leitete. Chris hielt einen ALM-Vortrag, in dem es um TFS ging. Ich wusste, dass ich irgendwann in die Beratung gehen wollte, aber bis zu diesem Zeitpunkt hatte ich keine Ahnung, in welchem Bereich ich beraten sollte! Als ich Chris über sein Team von ALM-Beratern sprechen hörte, wusste ich, dass ich genau das tun wollte. Allerdings war gerade mein erstes Kind geboren worden, und ich hielt es nicht für den richtigen Zeitpunkt, einen Job mit festem Gehalt aufzugeben.

Ich war 2009 auf der TechEd Africa - und Chris war wieder Gastredner! Diesmal war ich bereit für eine Veränderung - also hatte ich nach seinem Vortrag ein 5-minütiges Gespräch mit ihm. Ich erinnere mich, dass ich ihn fragte, ob er in Südafrika arbeite, und er antwortete, er könne einen Berater schicken (später fand ich heraus, dass er dabei an Donovan Brown dachte, der damals für Chris arbeitete). "Nein, ich möchte in die Beratung einsteigen", antwortete ich. Chris und ich unterhielten uns mit einer Schlüsselfigur von Microsoft - und jemandem, dem ich für all die Hilfe in meiner Anfangszeit zu Dank verpflichtet bin - Ahmed Salijee, der den Vertrieb von Visual Studio für Microsoft in Südafrika leitete.

Aus irgendeinem Grund ging Chris ein Risiko mit mir ein - und ein paar Monate später gründete ich die südafrikanische Niederlassung von Notion Solutions! Chris steckte ein paar Tausend Dollar ein, damit ich ein festes Gehalt hatte, aber ich habe alles gemacht. Ich habe angerufen. Ich lieferte. Ich habe Rechnungen geschrieben - ich habe in dieser Zeit so viel gelernt. Zum Glück hatte ich den kollektiven Verstand von Notion Solutions hinter mir, so dass ich selbstbewusst begann, obwohl ich nicht wirklich wusste, was ich tat. Das war ein guter Weg, um zu wachsen.

Wie bin ich hierher gekommen?

Im September 2010 flog mich Chris zu einem Notion Solutions-Treffen in Irving, Texas. Es war eine seltene Gelegenheit, alle Notion-Berater an einem Ort zu haben. Ich erinnere mich, dass ich ehrfürchtig war. Ich befand mich im selben Raum wie einige meiner "ALM-Helden" wie Chris Menegay, Dave McKinstry, Abel Wang, Donovan Brown, Steve St. Jean und Ed Blankenship. "Wie bin ich hierher gekommen?" fragte ich mich - aber ich war fest entschlossen, alles von diesen Leuten zu lernen und mein Glück nicht für selbstverständlich zu halten!

Die meisten Mitglieder des Notion-Teams waren Microsoft Most Valuable Professionals (MVPs) und ich wurde inspiriert, diese Auszeichnung ebenfalls zu erlangen. Also gründete ich meinen Blog - Colin's ALM Corner, den es heute noch gibt. 2011 wurde ich mit meiner ersten MVP-Auszeichnung geehrt. Im Jahr 2012 nahm ich an meinem ersten MVP Summit in Redmond, WA, teil. Dort traf ich einige Leute, denen ich bis heute verbunden bin - führende Köpfe der ALM-Community wie Marcel de Vries, René van Osnabrugge, Pieter Gheysens, Brian Randell, Nino Loje, Mickey Gousset, Esteban Garcia, Martin Hinshelwood und viele andere - darunter auch Steven Borg.

Umzug nach Amerika

Steve und ich verstanden uns sehr gut - und schließlich bot er mir eine Stelle in seinem Unternehmen Northwest Cadence an. Northwest Cadence hatte seinen Sitz in Seattle und war ebenfalls ein kleines ALM-Beratungsunternehmen. Northwest Cadence hat sich durch alle rechtlichen Verfahren gekämpft, um mich und meine Familie 2016 nach Seattle umzusiedeln, und seitdem bin ich in den USA.

Steve hat mich inspiriert - er ist ein hervorragender Kommunikator, der über alles etwas weiß. Und seine Beherrschung von schlanken Prozessen und Agilität war erstaunlich. Ich weiß noch, wie ich dachte: "Wenn ich groß bin, möchte ich genau wie Steve sein!" Ich habe in meiner Zeit bei Northwest Cadence so viel gelernt und denke immer noch in Begriffen wie Fluss, Effizienz und Warteschlangentheorie.

Im Jahr 2018 fusionierte Steve sein Unternehmen mit dem in Chicago ansässigen Unternehmen 10th Magnitude. 10th Magnitude leistete großartige Arbeit mit Azure, stellte aber fest, dass immer mehr Kunden ihre Softwareprozesse modernisieren wollten, als sie ihre Rechenzentren in die Cloud migrierten. Die Mitarbeiter von Northwest Cadence brachten eine Fülle von Erfahrungen in den Bereichen Prozessberatung und DevOps in 10th Magnitude ein, so dass es eine wirklich gute Ergänzung war.

Sie gehen in den... Verkauf?

Kurz nach meinem Einstieg bei 10th Magnitude wurde eine Stelle für einen Solution Architect ausgeschrieben. Ich sah mir die Stelle an, sprach mit einigen Leuten und stellte fest, dass es sich um eine technische Vertriebsrolle handelte. "Ich bin kein Verkäufer, ich bin ein Berater!" war meine erste Reaktion. Ich verhandelte jedoch mit der Geschäftsleitung und nahm die Stelle auf der Grundlage an, dass ich 30 % der Zeit verkaufen und die anderen 70 % beraten würde.

Das hat sich nie bewahrheitet. Am Ende habe ich viel mehr verkauft als beraten. Aber eines Tages hatte ich eine Erleuchtung: Ich liebe es, komplexe Probleme zu lösen. Und genau das tat ich in meinem Verkaufsprozess! Ich traf mich mit Kunden und nahm mir Zeit, um ihr Umfeld, ihre Menschen und ihre Herausforderungen zu verstehen. Dann entwarf ich Dienstleistungen und Angebote, die wir unseren Kunden zur Verfügung stellten, damit sie ihre Ziele erreichen konnten. Obwohl ich nun im Vertrieb tätig war, konnte ich das tun, was ich am liebsten tue - Technik und Kulturtechnik einsetzen, um Probleme zu lösen.

Was ist diese Git-Sache?

Ich erinnere mich noch, als TFS um 2013 herum Git-Repositories einführte. Ich konnte den Reiz nicht erkennen - wer würde ein Versionskontrollsystem verwenden, mit dem man die Historie überschreiben kann? Nachdem ich jedoch einige Zeit damit verbracht hatte, fing ich an, das Licht zu sehen - so sehr, dass ich einige Jahre lang einen Vortrag bei VSLive hielt, in dem ich die These aufstellte, dass man ohne Git keine moderne Entwicklung betreiben kann!

Und dann - 2018 - kaufte Microsoft GitHub. Also begann ich - widerwillig - herauszufinden, wie ich die Plattform nutzen konnte. Ich bevorzugte Team Foundation Server - das ein paar Mal den Namen gewechselt hatte und jetzt Azure DevOps heißt. Das heißt, bis GitHub GitHub Advanced Security (GHAS) veröffentlichte.

AppSec ist die Zukunft

Ich habe einen Entwicklungshintergrund - die Sicherheit war immer das Team, das "verhindert hat, dass Sie zu prod gehen". Ich sprach nicht die Sprache der Sicherheit, und ich hatte noch nie einen Sicherheitsexperten getroffen, der die Sprache der Entwickler sprach.

Aber GHAS war anders. Ich ahnte instinktiv, dass dies ein Tool war, auf das ich mich einstellen wollte. Mit der Zeit war ich in der Lage, dieses instinktive Gefühl zu verbalisieren - es ist einfach ein Sicherheitstool für Entwickler. Ich erkannte, dass dies ein Wendepunkt war.

Zu diesem Zeitpunkt war ich der DevOps Practice Lead bei 10th Magnitude und habe eines der ersten GHAS-Partnerangebote entwickelt. Wir boten einen 2-wöchigen GHAS Adoption Service an und konnten in den ersten Tagen einige Unternehmen bei der Einführung von GHAS unterstützen.

Umzug zu GitHub

Ich durfte auch einige GitHub/10th Magnitude Roadshows durchführen. In dieser Zeit lernte ich einige Hubbers kennen - darunter Kevin Alwell, einen Solution Engineer an der Ostküste. Im Jahr 2021 bewarb ich mich für eine Stelle als Solution Engineer bei GitHub - und etwa zwei Tage später rief mich Kevin aus heiterem Himmel an. Nachdem wir uns unterhalten hatten, erzählte er mir, dass es eine Stelle als Solution Engineer gäbe, für die ich seiner Meinung nach gut geeignet wäre... und der Rest ist, wie man so schön sagt, Geschichte.

Reflexionen

Ich habe eine unglaubliche Reise hinter mir - und habe noch viel vor mir! Das Aufkommen der generativen KI durch ChatGPT und GitHub Copilot ist gerade dabei, die Entwicklung, wie wir sie kennen, zu revolutionieren. Wenn die Software die Welt gefressen hat, dann ist jetzt die KI an der Reihe!

Da ich ein bekennender DevOpsologe bin, verkünde ich, dass ich ständig lerne. Was habe ich also im Laufe der Jahre bei der Arbeit mit DevOps gelernt?

Finden Sie Ihre Inspiration außerhalb Ihrer Karriere

Mein Glaube und meine Familie sind der Kern meiner Identität. Ich liebe es, SE und Technologe zu sein - aber das ist es, was ich tue, nicht das, was ich wirklich bin. Das ist wichtig, um mit Druck und harten Zeiten umzugehen - wenn die Arbeit scheiße ist (was sie zwangsläufig von Zeit zu Zeit sein wird), habe ich nicht das Gefühl, dass ich scheiße bin. Ironischerweise habe ich festgestellt, dass ein Leben für etwas anderes als Arbeit und Technologie zu mehr Erfüllung in der Arbeit und der Technologie geführt hat! Finden Sie also etwas, für das Sie sich begeistern können und das nicht Ihre Arbeit ist - und Ihre Arbeit wird sich tatsächlich verbessern!

Menschen sind wichtig

Ich liebe es, Code zu verticken. Ich liebe es, ein Geek zu sein. Aber egal, wie technisch versiert ich bin und egal, wie toll die Technik ist, die Menschen sind immer noch das Herz von DevOps. Ich sehe viele Unternehmen, die scheitern, nicht weil sie nicht klug sind oder die falschen Tools haben, sondern weil sie den Menschen und der Kultur keine Priorität einräumen.

Eines meiner Lieblingsgesetze ist das Conway'sche Gesetz. Conway (ein Programmierer) stellte 1967 eine Idee vor, die eine "homomorphe Kraft" zwischen der Kommunikationsstruktur eines Unternehmens und den von ihm produzierten Architekturen aufzeigt. Mit anderen Worten: Die Kultur spielt eine entscheidende Rolle bei der Gestaltung der Technologie.

Wenn Sie Team Topologies noch nicht gelesen haben, tun Sie sich einen Gefallen. Hören Sie auf, darüber zu debattieren, ob Sie Microservices implementieren sollten, und verwenden Sie einige Zyklen auf die Gestaltung Ihrer Teams. Mit anderen Worten: Menschen sind wichtig - stellen Sie sich auf diese Kraft ein, damit Sie nicht ständig dagegen ankämpfen müssen.

Ich musste lernen (und lerne immer noch), dass die Art und Weise, wie Sie etwas sagen, genauso wichtig ist wie das, was Sie sagen. Das war etwas, das ich als Beraterin lernen musste - und ich muss immer noch jeden Tag daran arbeiten. Ich kann abweisend und herablassend wirken - ein Nebenprodukt meiner Veranlagung, ein Problem sehr schnell auf den Punkt zu bringen. Aber ich muss ständig darüber nachdenken, wie ich das, was ich sehe, kommuniziere. Denn Menschen sind wichtig.

Bleiben Sie gelehrig

Eine logische Folge des oben Gesagten ist, dass Sie wichtig sind. Und wenn Sie wichtig sind, dann sind Sie es wert, in Sie zu investieren. Eine der besten Möglichkeiten, in sich selbst zu investieren, ist, um Feedback zu bitten (oder unaufgefordertes Feedback sorgfältig zu prüfen). Wir alle haben blinde Flecken, Vorurteile und Bereiche, in denen wir wachsen können. Wenn Sie nicht in der Lage sind, zuzugeben, dass Sie sich geirrt haben - und daraus zu lernen und zu wachsen -, dann werden Sie Ihr Potenzial begrenzen.

Manager, Kollegen und Kunden haben mir alle irgendwann einmal Feedback zu etwas gegeben. Jedes Mal versuche ich herauszufinden, was ich aus diesem Feedback lernen kann. Manchmal habe ich "das Fleisch gekaut und die Gräten ausgespuckt". Nicht jedes Feedback ist immer richtig - also versuche ich, die Dinge zu finden, aus denen ich lernen und wachsen kann - und ignoriere den Rest.

Lernen Sie weiter

Das ist eine meiner Kernstärken (von Gallup's CliftonStrenths). Lernen fällt mir also leicht - das ist nicht bei jedem so. Aber ich glaube, dass jeder ständig lernen sollte. Und angesichts des Tempos in der Softwarebranche ist dies bei DevOps fast schon eine Voraussetzung.

Ich hätte GitHub Advanced Security ignorieren können - schließlich bin ich kein Sicherheitsexperte. Aber ich habe mich bemüht, etwas darüber zu lernen - und das war der Schlüssel zu meinem Erfolg in den letzten Jahren. Manchmal müssen Sie sich einfach zusammenreißen und etwas lernen, auch wenn es nicht "in Ihrer Sparte" liegt - Sie werden überrascht sein, was alles passieren kann!

Gehen Sie kalkulierte Risiken ein

Ich wusste nicht, ob die Beratung langfristig eine gute Wahl für meine Karriere sein würde. Ich wusste nicht, ob ein Umzug in die USA gut für meine Familie wäre. Ich wusste nicht, ob ein Wechsel in den Vertrieb etwas wäre, das ich langfristig machen könnte. Ich ging an jede Entscheidung so rational wie möglich heran und holte mir gegebenenfalls Rat von Freunden, Familie, Kollegen und Managern. Aber ich ließ mich nie in eine "Analyse-Lähmung" verfallen. Irgendwann musste ich einige kalkulierte Risiken eingehen. Zum Glück hatte ich einen guten Lauf, auch wenn es Unsicherheiten gab.

Zum Schluss

Die Arbeit in der DevOps-Branche ist unglaublich erfüllend - von der Arbeit, die ich tun konnte, über die Menschen, die ich kennengelernt habe, bis hin zu der Art und Weise, wie ich als Mensch gewachsen bin und mich entwickelt habe. Jeden Tag schätze ich mich glücklich, dass ich einen Job habe, den ich liebe - und dass ich in einer Branche tätig bin, die sich ständig verändert und weiterentwickelt. Ich hoffe, dass meine Geschichte und einige meiner Erkenntnisse Sie dazu inspirieren können, sich weiterzuentwickeln - und hoffentlich kann ich eines Tages auch Ihre Geschichte hören.