DevOps: Woher kommt der Trend und was macht einen DevOps-Spezialisten aus?

Im Jahr 2016 ist die Anzahl der Entwickler und Systemadministratoren, die sich intensiver mit DevOps beschäftigen, rasant gestiegen. Diese Entwicklung ist nachvollziehbar: In einer Zeit, in der einzelne Entwickler mit nur geringen Kosten und wenigen API-Aufrufen eine global verteilte Anwendungsinfrastruktur einrichten können, beginnt sich die Kluft zwischen Entwicklung und Systemadministration zu schließen.

Während sich viele Artikel und Blog-Posts auf die neuesten Tools und Praktiken im DevOps-Umfeld konzentrieren, gibt es wenige Artikel, die einen Einstieg in die Welt von DevOps beschreiben. Dieser Artikel startet mit der alten Welt die zurückgelassen wird, und beleuchtet die Reise, die Systemadministratoren bevorsteht, wenn sie sich auf DevOps einlassen.

IT der “alten Welt”

Wenn man die Zukunft verstehen will, ist es wichtig, die Vergangenheit zu verstehen. Das trifft auch auf DevOps zu. Um die Verbreitung und Popularität der DevOps-Bewegung zu verstehen, ist es hilfreich, sich ein Bild davon zu machen, wie die IT in den späten neunziger Jahren und dem Großteil der Nullerjahre aussah.

Zu jener Zeit wurden Server, Netzwerkgeräte, Kabel und Software für die Erweiterung der Infrastruktur hauptsächlich telefonisch, zum Beispiel bei Dell, bestellt. Technologieabteilungen verfügten häufig über eine spezielle Gruppe, die sich um Datacenter Engineering und Operations kümmerte. Dieses Team hatte die Aufgabe, die monatlichen Leasingraten herunterzuhandeln, die Systeme ordnungsgemäß zu kühlen und sicherzustellen, dass die Mitarbeiter der ausgelagerten Rechenzentren über ausreichende Kenntnisse hinsichtlich der Server-Modelle ihrer Kunden verfügten, um nicht versehentlich außerhalb der üblichen Handelszeiten den falschen Stecker zu ziehen.

In der damaligen Zeit kümmerten sich andere Teams in erster Linie darum, dass die Betriebssysteme und die darauf installierte Software betriebsfähig bereitgestellt werden. Die Techniker waren dafür zuständig, zuverlässige Architekturen für das Einspielen von Patches, die Überwachung dieser Systeme und für Benachrichtigungen im Fehlerfall zu entwerfen. Der Großteil dieser Arbeit erfolgte durch viel manuelles Experimentieren und daraus entwickelten Run-Books.

Software-Releases waren ein noch ganz anderes Thema. In Meetings, zu denen Entwickler nicht eingeladen waren, haben Analysten technische und funktionale Anforderungen festgelegt, zu denen dann im Nachgang die Software geschrieben wurde. Optional schrieben Entwickler Unit-Tests für ihren Code. Danach wurde der Code mit “Fertig für QA” markiert. Die Qualitätssicherung übernahm die Software. Fehler wurden dann abhängig vom sonstigen Tagesgeschäft früher oder später in die Entwicklung zurückgesendet.

Auch wenn Systemadministratoren und Entwickler nicht allzu oft einer Meinung waren, hatten sie eines gemeinsam: Den Widerstand gegen Change Management. Der Begriff “Change Management” bezog sich zu jener Zeit auf hochregulierte und dringend erforderliche Vorschriften und Verfahren darüber, wann und wie technische Änderungen in einem Unternehmen implementiert werden sollten.

Diese große Anzahl an manuellen Schritten im IT-Bereich war mit vielen Fehlern verbunden. Diese Fehler führten wiederum zu hohen Umsatzeinbußen. Die Aufgabe des Change Managements bestand darin, die durch Fehler verursachten Umsatzeinbußen zu minimieren.

Dies erreichte man üblicherweise dadurch, dass Releases nur alle zwei Wochen durchgeführt wurden. Server-Änderungen wurden in die Warteschlange gestellt und irgendwann zwischen Freitag 16:00 Uhr und Montag 05:59 Uhr vorgenommen. Ironischerweise führte diese schubweise durchgeführte Arbeit zu noch mehr und noch schwerwiegenderen Fehlern.

DevOps ist eine Art zu denken

Der Wunsch, mit Menschen zu arbeiten, die einem ähnlich sind, ist eine menschliche Eigenschaft, die in der IT zu funktionalen Silos führt. Systemadministratoren und Entwickler bildeten nicht nur solche natürlichen Silos, sondern traten als geschlossene Gruppen auf, die im Konflikt standen, wobei die Mitglieder einer Gruppe eine “Gruppenposition” fast blind verteidigten.

Die Entwickler ärgerten sich über die Systemadministratoren, wenn ihre Umgebungen defekt oder zu stark abgeriegelt waren. Die Systemadministratoren ärgerten sich über die Entwickler, die ihre Umgebungen ständig willkürlich zerstörten oder weit mehr Rechenleistung forderten als tatsächlich notwendig war. Beide Seiten konnten und wollten sich nicht verstehen. Mit DevOps sollte diesem Zustand ein Ende gemacht werden.

DevOps ist kein Team. Es ist auch keine Gruppe in Jira. DevOps ist eine Art zu denken. Die DevOps-Bewegung beruht auf der Idee, dass Entwickler, Systemadministratoren und die wirtschaftlichen Akteure in einer idealen Welt als Team zusammenarbeiten. Und auch wenn sie wahrscheinlich nicht alles über die Welt des jeweils anderen wissen, wissen sie doch genug, um sich gegenseitig und ihre Backlogs zu verstehen. Das heißt, sie sprechen weitgehend dieselbe Sprache.

Fähigkeiten: Die Grundlagen erlernen

Derzeit stellen Unternehmen viele unterschiedliche Anforderungen an einen DevOps-Spezialisten. Kleinere Unternehmen, bei denen zwar viele Softwareentwickler tätig sind, die aber nur über wenige Mitarbeiter verfügen, die sich mit der Infrastruktur auskennen, suchen häufig jemanden, der Erfahrung in der Systemadministration mitbringt. Größere Unternehmen mit einer soliden Systemadministrationsorganisation sind eher auf der Suche nach Mitarbeitern mit Erfahrung, die ein Google Site Reliability Engineer (SRE), hat, das heißt, nach einem Softwareentwickler für die Gestaltung von Betriebsfunktionen.

Vor diesem Hintergrund sind Unternehmen meistens auf der Suche nach Infrastrukturentwicklern und DevOps Champions, die Interesse daran haben, sich in folgenden Bereichen weiterzubilden:

• Administration und Gestaltung sicherer und skalierbarer Cloud-Plattformen (AWS; Azure, Google Cloud Platform und PaaS-Anbieter wie DigitalOcean und Heroku)
• AEinrichtung und Optimierung von Deployment-Pipelines und -Strategien mittels gängiger CI-/CD-Tools wie Jenkins und GoCD oder cloud-basierter Tools wie Travis CI oder CircleCI
• Überwachung und Protokollierung von Systemänderungen sowie Benachrichtigung über solche Änderungen mit Tools wie Kibana, Grafana oder Splunk sowie Loggly oder Logstash
• Betrieb von Infrastruktur als Code mit Konfigurationsmanagement-Tools wie Chef, Puppet oder Ansible sowie Bereitstellung besagter Infrastruktur anhand von Tools wie Terraform oder CloudFormation.

Container nutzen

Container werden immer beliebter, da diese schnell eine großartige Möglichkeit bieten, eine extrem hohe Dichte an Diensten und Anwendungen zu erreichen. Diese benötigen in Summe weniger Systeme zur Ausführung der Software, bei gleichzeitiger Erhöhung der Zuverlässigkeit. Orchestrierungs-Tools wie Kubernetes und Mesos können bei Ausfall des Host-Servers zum sekundenschnellen Spin-up neuer Container genutzt werden.

Die Möglichkeit, Applikationen von einer Deployment-Pipeline schnell und unkompliziert in ein Container-Image packen zu lassen, und dieses Image dann auf verschiedensten Servern, physischen oder virtuellen, und allen bedeutenden Betriebssystemen laufen zu lassen, macht Container zu einer verlockenden Wahl für alle, die schnelle und häufige Implementierung beabsichtigen.

Container tragen zudem zur Bewältigung vieler Herausforderungen bei, die mit der Systemkonfiguration einhergehen und für die Konfigurationsmanagement-Plattformen schon länger eine Lösung bieten. In einer Container-basierten Infrastruktur sind Patching, die Verwaltung der Umgebungsvariablen sowie der Systemstatus von geringerer Bedeutung. Wichtig hingegen ist, dass der Kern des Betriebssystems, auf dem der Container-Dienst ausgeführt wird, die ausgeführten Container unterstützt und dass die für die Ausführung erforderlichen externen Abhängigkeiten vorhanden sind.

Warum ist das wichtig? Es ist sehr wahrscheinlich, dass die Konfigurationsmanagement-Fähigkeiten von heute in weniger als fünf Jahren gänzlich obsolet sein werden.
 

Querschnittsfertigkeiten: Nach Links und Rechts schauen

Wenn Systemadministratoren über einen Jobwechsel nachdenken, sollten sie sich mit Programmierung auskennen. Python und Ruby sind gängige Programmiersprachen. Sie sind portabel (das heißt, sie können auf jedem Betriebssystem genutzt werden), schnell, einfach zu lesen und zu erlernen. Sie bilden darüber hinaus das Fundament für die branchenweit gängigsten Konfigurationsmanagement-Tools (Python für Ansible, Ruby für Chef und Puppet) und Cloud-basierten API-Clients (Python und Ruby werden in der Regel für AWS, Azure und GCP-Clients verwendet).

Entwickler hingegen sollten sich intensiver mit UNIX, Windows und Netzwerkgrundlagen beschäftigen. Auch wenn die Cloud viele früher sehr komplizierte Sachverhalte für die Systemadministration einfacher gemacht hat, helfen diese Kenntnisse über die zugrundeliegenden Technologien, Performance-Probleme zu vermeiden oder besser in den Griff zu bekommen.

Übung macht den Meister

Dies alles erscheint auf den ersten Blick sehr kompliziert. Aber es gibt viele kleine Projekte, welche die Möglichkeit bieten, in die Materie einzutauchen. Eines davon ist der Voter Service von Gary Stafford, eine einfache Java-basierte Abstimmungsplattform. Viele Unternehmen bitten Bewerber, den Dienst von Github über eine Pipeline zur Produktionsinfrastruktur zu bringen. Dies lässt sich mit der sehr guten Einführung in Ansible und Continuous Delivery von Max Griffiths kombinieren, um zu erlernen, wie man dies erreicht.

Eine andere gute Möglichkeit, sich mit diesen Tools vertraut zu machen, ist die Einrichtung einer Infrastruktur für gängige Dienste mit Hilfe von AWS und dem Konfigurationsmanagement. Diese Infrastruktur kann zunächst manuell eingerichtet werden, um sich ein Bild davon machen kann, was zu tun ist. Im zweiten Schritte können Interessenten die Arbeitsschritte mit Hilfe von CloudFormation (oder Terraform) und Ansible replizieren. Erstaunlicherweise ist dies ein wesentlicher Teil der Arbeit, die Infrastrukturentwickler tagtäglich für ihre Kunden leisten. Und diese Arbeit ist von sehr hohem Wert!

Über den Autor

Carlos Nuñez ist Senior Infrastructure & DevOps Consultant bei ThoughtWorks, einer weltweit tätigen IT-Beratung. Das Unternehmen hat seinen Hauptsitz in Chicago (USA) und in Deutschland Büros in Hamburg, Köln, Berlin und seit kurze auch München. Dort arbeiten zurzeit sechs Mitarbeiter, das Team soll noch in diesem Jahr auf 40 Mitarbeiter anwachsen.

 Loading ...