DevOps ist ein weit verbreiteter Begriff, aber leider ähnlich vage wie „Cloud“: zwar weiss jeder, dass er es will oder braucht und dennoch ist es nicht etwas, was man einfach bestellen und geliefert bekommen kann.
Wir verstehen unter DevOps die interdisziplinäre Zusammenarbeit zwischen Entwicklern (Developers) und Betreibern (Operators) von Software, um die Applikationen schnell und systematisch einzusetzen.

Ähnlich wie bei Agiler Softwareentwicklung (z.B. Scrum) – bei dem der „Product Owner“ mit den Softwareentwicklern zusammen die jeweils nächstfolgenden Entwicklungsschritte spezifiziert und fertiggestellte Arbeiten abnimmt – fördert dies die Kommunikation zwischen den beteiligten Parteien und vermindert Missverständnisse und dadurch teure Fehler.
Die Förderung der Zusammenarbeit zwischen Entwicklern und Betreibern steht im Kontrast zur bisherigen Praxis, diese Teams strikt zu trennen – sei dies aus Gründen der Gewaltentrennung (kein Zugriff der Entwickler auf Produktionsdaten) oder weil Entwickler und Betreiber unterschiedliche Anforderungsprofile erfüllen mussten (Programmierkönnen, Bereitschaftsdienst).
Unterdessen sind aber eine Reihe von Erkenntnisse und bewährte Verfahren aus der Softwareentwicklung auch in den Betriebsprozessen angekommen:

1. Infrastructure as Code: Die Beschreibung und Konfiguration der Infrastruktur-Komponenten mittels Skripts, um wiederkehrende Aufgaben (z.B. Installation eines Servers oder Installation / Upgrade einer Applikation) schnell und zuverlässig zu automatisieren. Je nach Anwendungsfall und Umgebung gibt es dafür unterschiedliche Werkzeuge – Docker, Ansible, Puppet, SaltStack, etc. – die bereits eigene Frameworks und Ökosysteme mit fertigen Bausteinen für Standardkomponenten mitbringen.
2. Testsysteme: Wenn das Aufsetzen eines Servers komplett automatisiert ist, minimiert dies den Aufwand, einen oder mehrere Testserver zu erstellen. Wenn die Entwickler einen Testserver benutzen können, der gleich aufgesetzt ist wie ein Produktionsserver, können sie Fehler finden, bevor sie auf der Produktion auftreten.
3. Versionierung: Ist die Infrastruktur oder zumindest Teile davon in Code abgebildet, so kann man diesen mit bekannten Code-Versionierungstools (Git, SVN, etc.) verwalten. Dies ermöglicht die Nachvollziehbarkeit von Änderungen an der Infrastruktur („Wer hat was wann geändert?“, „Warum funktioniert das plötzlich nicht mehr, obwohl an der Software nichts geändert wurde?“) und das lückenlose Zurückrollen von Änderungen, falls doch mal ein Fehler auftreten sollte.
4. Kontinuierliche Integration des Infrastrukturcodes: So wie auch die eigentliche Applikation automatisch bei jeder Änderung kompiliert und sowohl komponentenweise als auch gesamtheitlich funktional getestet wird, können auch die Anforderungen an die Infrastruktur anhand automatisierter Tests verifiziert werden. Durch das möglichst frühzeitige Erkennen eines Fehlers werden die Auswirkungen minimiert. Zum Beispiel kann das Publizieren von Änderungen gesperrt werden, falls Fehler beim Testen aufgetreten sind.

Umgekehrt fliessen auch Erfahrungen aus dem Betrieb in moderne Softwarearchitekturen ein:

1. Paketisierung und Versionsverwaltung: Damit über den gesamten Qualitätssicherungsprozess von Test- / Entwicklungsserver, Abnahme durch den Product Owner, evtl. externes Testen / Validieren (Beta-, User-, UX-Tests), Integration mit externen Schnittstellen (Backends, APIs) bis zur Produktion alle beteiligten Personen von der jeweils gleichen Version der Software sprechen, wird diese in einem versionierten Paket abgelegt. Die Art der Paketierung kann dabei von der Entwicklungs- (z.B. JAR bei Java, WAR bei Tomcat) oder Betriebsumgebung (z.B. DEB/RPM bei Linux, MSI bei Windows) vorgegeben oder wie z.B. im Falle von Docker auch unabhängig sein. Dies stellt sicher, dass die Software komplett (mit allen benötigten Bibliotheken) installiert und aktualisiert werden kann und automatisiert diese Schritte soweit möglich.
2. Service Oriented Architectures (SOA) und Microservices: Sobald eine Applikation in der Entwicklung so umfangreich und / oder komplex wird, dass sich mehr als eine handvoll Teams darum kümmern, ist es einfacher, die Teams in kleinere Sub-Projekte („Microservices“) aufzuteilen und die Schnittstellen dazwischen explizit zu definieren als alle Teams untereinander im gleichen „Projekt“ bezüglich Technologie, Entwicklungsfortschritt und interner Zuständigkeiten zu koordinieren. Damit können die Teams nicht nur entkoppelt voneinander weiterentwickeln, sondern könnten sogar für ihren Zweck geeignetere Technologien wählen – vorausgesetzt, die Schnittstelle zu anderen Teams ändert sich nicht. Optimalerweise wären die meisten Komponenten / Services untereinander fehlertolerant, funktionieren also bei Ausfall einer Sub-Komponente mit eingeschränkter Funktionalität weiter, wodurch das Gesamtprojekt robuster wird.
3. Configuration Management: Die meisten Applikationen haben Schnittstellen zu anderen Applikationen – zum Beispiel zu einer Datenbank oder anderen APIs / Services – und schreiben Protokolldateien. Während der Entwicklung, dem Testing in der Qualitätssicherung und für die Produktion werden unterschiedliche Endpunkte (Adressen, Zugangsdaten etc.) dafür verwendet. Dies ermöglicht die Isolation von Test- und Produktivdaten; ein Test einer neuen Version kann also nicht aus Versehen die produktiven Kundendaten löschen. Darum werden die Zugangsdaten nicht direkt im Code verwaltet, sondern in Konfigurationsdateien, die wiederum für jede Umgebung automatisch generiert oder aus Umgebungsvariablen gelesen werden können. Eine moderne Definition dafür ist zum Beispiel die Zwölf-Faktoren-Methode (http://12factor.net/de/).
4. Skalierbarkeit: Applikationen und Services, die klar definierte Schnittstellen haben, können einfach horizontal – also über verschiedene Server verteilt – skaliert werden. Dies ermöglicht dem Betrieb, den Service mehrfach, redundant und damit hochverfügbar anzubieten und auf unterschiedliche Last durch hinzufügen oder entfernen von Servern zu reagieren. Selbst diese Schritte können automatisiert werden: Es ist möglich, automatisch aufgrund der aktuellen Auslastung mehr Serverressourcen zu beziehen respektive wieder frei zu geben und abhängig vom Abrechnungsmodell der einzelnen Ressourcen Kosten nur dann zu produzieren, wenn die Leistung auch effektiv genutzt wird.

Was bringt nun die Verschmelzung von Entwicklungsmethoden und Betriebsprozessen konkret?

1. Die Automatisierung der Infrastruktur (siehe „Infrastructure as Code“ oben) macht die Infrastruktur schneller, zuverlässiger und verhindert Inkonsistenzen durch (fehlende) manuelle Schritte auf verschiedenen Systemen. Sie ermöglicht, dass Entwickler und Product Owner ihre Ergebnisse effektiv unter gleichen Bedingungen wie die Produktion testen können.
2. Die Automatisierung des Software-Lebenszyklus von der Entwicklung bis zur Produktion macht den ganzen Prozess schneller, zuverlässiger und kann optimalerweise vom Product Owner selbst nach Freigabe der neuesten Version durchgeführt werden. Dadurch geben nach den Entwicklern auch die Betreiber dem Business die Zügel für die Applikation in die eigenen Hände und stehen für Weiterentwicklungen zur Verfügung. Damit kann der Product Owner sowohl den Umfang als auch die Frequenz der Deployments bestimmen. Je häufiger ausgerollt wird, was zur Folge hat, dass der Umfang der jeweiligen Änderungen kleiner ausfällt, desto kleiner ist das Risiko von unerwünschten Nebenwirkungen und Fehlern. Tauchen dennoch einmal Fehler auf, kann der Product Owner selbst die letzte Änderung rückgängig machen und die Entwickler zur Nachbesserung aufbieten, ohne den Betrieb damit zu belangen.
3. Beides zusammen verhindert, dass die IT im Selbstzweck den kritischen Pfad des Projektes blockiert und befähigt die Entwickler und das Business zur „Selbstbedienung“. Natürlich bedeutet das auch einen Kulturwandel innerhalb eines Unternehmens: schlägt ein Deployment fehl oder treten Probleme in der Produktion auf, so müssen Entwickler und Betriebsleute das Problem zusammen beheben und sicher stellen, dass es nicht wieder vorkommt (z.B. mittels automatischem Test). Dabei ist unerheblich, warum oder wegen wem das Problem aufgetreten ist: es muss kein „Schuldiger“ gefunden, sondern der Gesamtprozess kontinuierlich verbessert werden.

Wir bei VSHN machen den ganzen Tag nichts anderes, als verschiedene Entwicklungsprozesse, verschiedene Technologien, verschiedene Backends (Datenbanken, Cache-Server, Proxies, WAFs etc.) zu automatisieren und gemäss Anforderungen unserer Kunden und / oder Entwicklungs-Partnern auf beliebiger Infrastruktur – seien das öffentliche Clouds wie Amazon, Azure, Cloudscale.ch, Cloudsigma, Exoscale.ch, Safe Swiss Cloud, Swisscom Cloud oder private, also firmeninterne Infrastrukturen auf VMware- oder Hyper-V-Basis – zu betreiben.
Wir beraten unsere Kunden bezüglich Ort der Datenspeicherung (CH, EU, international), sind auch selber bald ISO27001-zertifiziert und können zusammen mit unseren Partnern Hosting gemäss FINMA-Standard anbieten.
Unsere Kernwerte sind Vertrauenswürdigkeit und Erreichbarkeit der fachlichen Kompetenz. Vertrauenswürdigkeit und Sicherheit durch Transparenz: transparente Kommunikation der Prozesse, transparente Auftragsdefinitionen und Verrechnungsmodelle. Wir arbeiten agil mit unseren Kunden und kommunizieren regelmässig. Wir sind 24×7 rund um die Uhr erreichbar und kümmern uns proaktiv um „unsere“ Applikationen.
Wir sind VSHNeers.