Wir reden nicht nur über DevOps, wir MACHEN es! – Teil 3

Wenn Entwicklung und Betrieb an einem Projekt zusammenarbeiten, spricht man von DevOps. Das erfordert auf beiden Seiten starkes Umdenken, damit gemeinsam möglichst effizient gearbeitet werden kann. Im Interview berichten Lytuskan und Tobias, wie aus eigentlich zwei getrennten Arbeitseinheiten eine geworden ist und welche Herausforderungen aber auch Chancen sich durch die Kooperation ergeben haben.

Lyutskan Lyutskanov (OPS) ist System-Architekt und hat sich auf Cloud-Lösungen und Automatisiertes Deployment in der Open Telekom Cloud spezialisiert.

Tobias Wohland (DEV) ist Software-Engineer und hat sich auf das Thema Blockchain und das Ethereum-Ökosystem spezialisiert.

• 

• 

Wie kam es zu eurer Zusammenarbeit? Hattet ihr von Anfang an DevOps im Kopf?

Tobias: Unsere Zusammenarbeit ist aus dem Projekt „Validation as a Service“ (VaaS) heraus entstanden. Es war klar, dass wir im Blockchain Solutions Center (BCSC) fachliche Unterstützung dafür brauchten, die benötigte Infrastruktur für das Projekt aufzubauen und zu betreiben. Entsprechend suchten wir einen kompetenten Ansprechpartner. Den haben wir im Operations- und Entwicklungsbereich gefunden. Dabei hat es tatsächlich ein wenig gedauert, bis wir als EIN Team agierten. Zu Beginn wurde DEV und OPS noch relativ getrennt voneinander betrachtet. Das lag allerdings auch daran, dass das Projekt im ständigen Wandel war. Mit der Zeit haben wir aber zueinander gefunden, was am Schluss, so glaube ich, beiden Seiten zugutegekommen ist.   

Lyutskan: Sehr hilfreich fand ich, dass sich die Kollegen vom BCSC schon von Anfang an Gedanken gemacht haben, wie man die geplante Lösung aus OPS-Sicht aufbauen und betreiben soll. Da die Blockchain-Technologie sich ständig weiterentwickelt, reicht es nicht, nur ein Produkt bereitzustellen und Hotfixes nachzuliefern. Es muss eine permanente aktive Weiterentwicklung im Betrieb stattfinden. Somit wurden wir schon von Anfang an am Projekt beteiligt und konnten nach einer kurzen Zeit zusammenkommen und uns als ein „DevOps“-Team sehen. Selbstverständlich hat das auch einige Zeit gedauert. Aber es gibt leider immer noch genug Beispiele, wo es gar nicht zu diesem Zusammenwachsen kommt. 

Wie habt ihr euch für eure tägliche Arbeit organisiert?

Lyutskan: Da das Scrum-Vorgehen im OPS-Bereich nicht immer optimal ist, arbeiten wir meistens an ITIL angelehnt. In den letzten Jahren kommt Scrum als Vorgehen aber immer häufiger zum Einsatz. Damit hatten wir uns also bereits angefreundet. Als System-Architekt arbeite ich viel in Transitions-Projekten mit, wo Scrum auch viel mehr Sinn macht, als im reinen Betrieb. Am Anfang hatten wir zeitliche Probleme, da ich parallel in mehreren Projekten arbeite und feste Zusagen in anderen Kundenprojekten Vorrang hatten. Somit war der Anlauf etwas träge.

Tobias: Aus der DEV-Welt waren wir Scrum gewohnt. Daher haben wir in dem Projekt von Anfang an auf Scrum gesetzt. In meiner Erinnerung waren das die OPS-Kollegen nicht gewohnt bzw. wird diese Methodik nicht überall eingesetzt. Das und andere Gründe hatten zur Folge, dass zu Beginn die OPS-ler nicht regelmäßig an den Scrum-Meetings teilnehmen konnten und die Transparenz ihrer Aufgabenbearbeitung nicht immer gegeben war. Zusätzlich hat auf der DEV-Seite auch manchmal das Verständnis dafür gefehlt, wie die OPS-Kollegen arbeiten. Aber ein Vorteil von Scrum ist, dass man als Team ständig bestrebt ist, den Scrum-Prozess für die realen Bedingungen selbst zu verbessern. Letztlich haben also die Scrum-Tools, das Commitment auf beiden Seiten, sowie das große Verständnis seitens der DEV-Seite dazu geführt, dass wir effektiv zusammengearbeitet haben.

Mit welchen Meeting-Formaten und Kommunikations-Tools habt ihr gearbeitet?

Lyutskan: Wir haben die direkte Kommunikation per Telefon und RocketChat gewählt, oft mit Screensharing über Skype. Sonst haben wir Jira und Confluence eingesetzt. Jira unterstützt uns, um unsere Tasks zu definieren und die Umsetzung zu verfolgen. 

Tobias: Als Meetingformate dienten uns die üblichen Scrum-Formate sowie der direkte Austausch. Gerade der direkte Austausch hat enorm geholfen, um die Arbeit des jeweils anderen besser zu verstehen und gut unterstützen zu können. Als Hauptkommunikationstool hat sich hierbei RocketChat als unentbehrlich erwiesen. Allein der Punkt, dass Chatverläufe, wie bei jedem anderen Messenger, gespeichert werden, vereinfacht die Zusammenarbeit enorm. Daneben nutzen wir Jira mit Scrumboard als Übersicht für die gerade laufenden und anstehenden Tasks, sowie Confluence für die Dokumentation.

Welche Relevanz hat die Automatisierung von Arbeitsabläufen im Projekt gespielt?

Lyutskan: Einen hohen Grad an Automatisierung zu erlangen, war von Anfang an unser Ziel im DevOps-Team. Das ist uns auch sehr gut gelungen. Durch GitLab, was schnell das zentrale Verwaltungstool in unserem Team wurde, konnten wir unseren Ansprüchen gerecht werden. In diesem Tool haben wir vor Allem Codes und Pipelines untergebracht und die Codes von DEV als auch von OPS zusammengeführt, weiterentwickelt und gemeinsam genutzt. Mit Merge-Requests konnten die Codes dann teilweise auch akzeptiert und freigegeben werden.

Tobias: Die OPS-Kollegen haben uns gezeigt, wie sie mit GitLab arbeiten und uns auch einen Zugang gegeben. Dort haben wir die entsprechenden Repositorys  des Projekts gehostet. Für mich persönlich hat GitLab ein ganz besonderes Highlight des Projekts dargestellt, da dieses Tool auch für mich sehr viel mehr bietet als Bitbucket, mit dem ich bisher gearbeitet habe.

Welche Hindernisse und Hürden seht ihr in einem interdisziplinären DevOps Team? 

Tobias: Ein Hindernis bei der Entwicklung ist im Zweifel die Zeit, die die einzelnen Teammitglieder in ein Projekt investieren können. Beispielsweise betreuen die OPS-Kollegen meist mehrere laufende Projekte. Das bedeutet, wenn es irgendwo brennt, hat das oberste Priorität. So kam es bei unserem Projekt zu Terminabsagen bzw. nicht geschafften Tasks. Hierfür Verständnis zu entwickeln ist ein wichtiger Punkt, um ein gemeinsames Ziel erreichen zu können. Am Ende muss das in die gesamte Projektorganisation einbezogen werden. Das hat aber bei uns mit leichten Startschwierigkeiten von Anfang an recht gut funktioniert.

Lyutskan: Wie bereits erwähnt, muss der DevOps-Modus schon von Anfang an angesteuert werden. Wenn DEV schon startet und OPS irgendwann später dazu kommt, wird es schwierig. Auch die Arbeitsweise unterscheidet sich oft. Eine Software-Architektur ist eben keine System-Architektur. Und mit Cloud, Kubernetes, Container usw. wird es für die Entwicklung nicht einfacher, einen Durchblick zu bekommen. Obwohl man mit der Bereitstellung von Containern wenigstens garantieren kann, dass die Services immer gleich funktionieren.

Seht ihr auch Grenzen in der SCRUM-Methode?

Tobias: OPS in Scrum zu integrieren ist nicht ganz trivial, so mein Gefühl. In der DEV-Welt können wir uns für einen Sprint klar gesteckte Ziele setzen: Das User Interface (UI) erhält einen Button X, der Button führt Aktion Y aus etc. Das lässt sich gut tracken und der Fortschritt lässt sich gegenüber dem Product Owner einfach kommunizieren. Natürlich läuft es im Hintergrund komplexer: Rest-Endpoints implementieren, die Datenbank anschließen, UI bauen und an die Rest-API anschließen etc. Aber der Punkt ist, dass man am Ende Button X zeigen kann, der Aktion Y ausführt. In der OPS-Welt gibt es natürlich auch abgesteckte Ziele, aber es gibt eben nicht diesen einfach vorzeigbaren Button. So wurden etwa komplexe Deployment-Skripte gebaut, und man kann dem Product Owner davon nur Dinge auf der Konsole zeigen. Eventuell hängt das aber auch vom Product Owner ab. Sofern er Erfahrung mit OPS hat, wiegt dieser Punkt also im Zweifel gar nicht so stark. Erleuchtend fand ich genau diesen Punkt, als ich selbst an der Infrastruktur mitgearbeitet habe. Einen OPS-Task konnte man einfach nicht so abgesteckt betrachten wie im DEV-Bereich, wodurch Scrum einfach etwas schlechter funktioniert hat. Allerdings muss man hier sagen, dass meine geringe OPS-Erfahrung im Zweifel nicht repräsentativ ist und das genaue Abstecken von Tasks sehr wohl möglich, nur ungewohnt ist. 

Lyutskan: Ich habe festgestellt, dass man den DEV-Kollegen von Anfang an einen tieferen Einblick bei der Automatisierung, dem Aufbau der Infrastruktur und der Operations der Anwendung geben sollte. Da ich selbst als Software-Entwickler angefangen habe, kann ich mir gut vorstellen, welche Aufwände sich hinter einer User Story verstecken. Bei Operations ist das im ersten Moment nicht so klar. Man stellt z.B. eine Virtual Machine bereit. Wie lange kann das schon dauern? Sind ja „nur“ 5 Klicks in der Cloud Web-UI. Dass diese Prozesse aber auch vollautomatisiert über Schnittstellen gesteuert werden sollen und fehlerfrei wiederholbar sein sollen, wird zu Beginn nicht ersichtlich. Nur so kann man aber weitere Umgebungen auf Zuruf in wenigen Stunden oder sogar Minuten bereitstellen, oder bei auftretenden Problemen von Null wiederaufbauen. Diese „Insights“ müssen auch richtig mitgeteilt werden, was bei uns am Anfang nicht so optimal umgesetzt war. Diese Kommunikation zu steuern, und nicht davon auszugehen, dass schon alle verstehen, was gemeint ist, muss ein besonderes Merkmal der gemeinsamen Arbeit sein.

In welchen fachlichen Themen habt ihr euch ganz konkret ausgetauscht und voneinander gelernt?

Lyutskan: Meinerseits habe ich mehr Verständnis bekommen, wie DEV sich heutzutage weiterentwickelt hat, und wie man aus DEV-Sicht mit Containern in der lokalen Umgebung umgeht. Da ich schon seit fast sechs Jahren nicht mehr aktiv Software entwickle, waren das sehr spannende Einblicke. Mich hat es besonders gefreut, dass Tobias sich auch für die Umsetzung des Systems in der Cloud interessiert hat und sich die Zeit genommen hat, das zu verstehen. Jetzt kann er auch kleine Konfigurationsanpassungen an der DEV-Umgebung vornehmen und versteht, wie man neue Services onboarded. Auch hat er mich bei der Arbeit mit Git unterstützt und mir geholfen, meine Git-Kenntnisse zu vertiefen. Wir arbeiten an weiteren Projekten in Blockchain-Umfeld zusammen, und ich freue mich auf die zukünftige Arbeit und Erfahrung mit dem Team!

Tobias: Lyutskan hat uns Entwicklern mal einen Überblick über ihr Tooling gegeben. Das hat uns erstmal erschlagen. Mit der Zeit habe ich aber die grobe Struktur verstanden. So konnte ich mich dann zumindest auf ein Kubernetes-Cluster bzw. die einzelnen Pods schalten, um Dinge zu prüfen sowie zur Not auch mal eine Variable für einen Service anpassen. Daneben habe ich auch viel über GitLab gelernt. Ich kannte es vorher schon, aber nach ein paar intensiveren Sessions zu bestimmten Themen hat sich mein Wissen deutlich erweitert. Außerdem habe ich generell einiges über Infrastruktur-Komponenten sowie vor allem die Integration dieser Komponenten in der Cloud gelernt. Generell hat sich mein Verständnis für die Cloud deutlich erweitert. Das lag auch vor allem daran, dass sich Lyutskan die Zeit genommen hat, mir einiges zu erklären. Wir als DEV-ler bauen uns ja im Normalfall eine lokale Entwicklungsumgebung auf. Das sieht dann so aus, dass wir alle Komponenten in eine docker-compose stecken. Das reicht für uns. Aber das ist eben etwas anderes, als einen Service produktionsreif in der Cloud zu deployen.

Wie geht es mit eurem DevOps-Team weiter? Arbeitet ihr weiterhin zusammen oder ist das Projekt bereits abgeschlossen?

Tobias: Wir arbeiten weiter zusammen und verbessern stetig unseren Scrum-Prozess. Das Projekt hat eigentlich gerade erst begonnen. Das einzigartige hierbei ist, dass wir keine Kunden haben sondern, direkt auf den Blockchainprotokollen aktiv sind und somit mit den Erstellern des jeweiligen Protokolls bzw. dem Protokoll selbst interagieren. Das nächste Teilprojekt steht auch kurz vorm Livegang. Danach steht bereits das nächste Projekt in den Startlöchern, bei dem ich schon einen PoC aufbauen konnte. Und daneben gibt es noch eine Liste mit weiteren Interessenten, die mit uns zusammenarbeiten möchten. Während den weiteren Umsetzungen hoffen wir, dass wir den Prozess, ein Blockchainprotokoll mit Infrastuktur zu „versorgen“, immer weiter standardisieren können, so dass neue Protokolle immer schneller bedient werden können. Für 2021 stehen für das Projekt also alle Vorzeichen auf Erfolg.

Das Interview führte Christine Maßloch (DevOps-Consultant).

Sie möchten den aktuellen Reifegrad Ihres Unternehmens in Bezug auf DevOps herausfinden?

>Wir beraten Sie gern!

DevOps – You build it, you run it!

>Zum Podcast