Selbst die traditionellsten und konservativsten Unternehmen müssen heute die Digitale Transformation vorantreiben. Denn nur wer seinen Kunden schneller bessere Services bietet, kann im Wettbewerb mit dynamischen Startups konkurrieren. Im Zuge dieser Anforderungen ist das Konzept DevOps entstanden, das durch gemeinsame Prozesse und Tools eine effizientere Zusammenarbeit von IT-Entwicklung und -Betrieb ermöglicht. Damit lässt sich nicht nur die Geschwindigkeit bei der Erstellung neuer Software-Versionen erhöhen, sondern auch die Bereitstellung erleichtern, die Komplexität senken, Innovationen fördern und Fehler reduzieren.
Da sich in den letzten Jahren viele Märkte stark veränderten, haben zahlreiche Unternehmen bereits DevOps-Prozesse eingeführt. Außerdem haben sie Anwendungen vom eigenen Rechenzentrum in virtuelle und Cloud-basierte Umgebungen unter Nutzung von Container-Technologien und PaaS-Angeboten migriert. Doch in Zukunft müssen die Unternehmen auch zunehmend Microservices, eine schnellere Skalierung bei Bedarf sowie automatische Fehlerbehebung nutzen. Gleichzeitig fordern die jungen "Cloud-nativen" Mitarbeiter SaaS-basierte Lösungen. Dabei muss ein Monitoring die Lücke zwischen dem "Enterprise Stack" aus Lösungen wie Mainframe, WebSphere oder WebLogic mit dem "Neuen Stack" wie JavaScript-, NGINX- oder Mobile-Technologien überbrücken. Zudem ist die Erweiterung des DevOps-Ansatzes durch die Berücksichtigung von Geschäftsmodell (Biz) und Sicherheit (Sec) nötig.
Um eine führende Rolle im Markt zu behaupten, müssen Unternehmen daher ihre Strategie ändern, wie sie Software planen, entwickeln, testen, aufbauen und betreiben. Es reicht nicht mehr, zwei große Versions-Updates im Jahr bereitzustellen. Inzwischen sind schon zweiwöchentliche Aktualisierungen normal, die über SaaS und das eigene Rechenzentrum angeboten werden. Dabei lassen sich Code-Installationen innerhalb einer Stunde erreichen. Das funktioniert in vier Schritten:
Foto: Dynatrace
Schritt 1: Qualität in die Entwicklung bringen
Im Rahmen der Software-Entwicklung nutzen bereits viele Unternehmen agile Prozesse und Continuous Integration. Dabei zeigen die Entwickler bei den regelmäßigen Code Reviews jedoch häufig neue Funktionen auf ihrer eigenen Workstation - und damit ohne Prüfung, ob die Funktion in einem integrierten Sprint Build wirklich funktioniert. Ein solcher Test lässt sich gewährleisten, indem die Sprint Builds automatisch in eine produktionsnahe Umgebung übertragen werden. Erst wenn die neue Funktion in einer solchen Umgebung erfolgreich demonstriert werden kann, ist sie als vollständig zu erachten. Dadurch sind die Entwickler dazu angehalten, eine hohe Qualität sicherzustellen.
Gleichzeitig sollten aktuelle Monitoring-Lösungen zur Überwachung der internen Systeme wie Webseiten, Communities oder Fehlerverfolgung eingesetzt werden. Dann lässt sich sofort erkennen, ob ein fehlerhafter Sprint Build die überwachten Anwendungen beeinträchtigt. Wenn die Nutzer nicht mehr auf Webseiten oder die Community zugreifen können, kann das Unternehmen den Sprint Build sofort wieder zurücknehmen. Das erhöht die Lernkurve und fehlerhafter Code lässt sich früher in der Entwicklungs-Pipeline stoppen.
Schritt 2: Architekten für produktive Version verantwortlich machen
In Zukunft sollten die leitenden Software-Architekten für die Qualität, Performance und Skalierbarkeit der Funktionen im Betrieb direkt verantwortlich gemacht werden. Dabei definieren sie auch die Strategie für das Production Monitoring und bestimmen, welche Metriken zu messen sind und welche Dashboards im Alltag eingesetzt werden, zum Beispiel zur visuellen Darstellung von Engpässen. Durch die höhere Verantwortung lässt sich die Qualität bereits in der Entwicklung weiter verbessern.
Schritt 3: Entwickler sollten Produktionsmetriken nutzen
Die Entwickler benötigen dafür einen vollständigen Zugang zu Production Monitoring-Daten - mit speziellem Fokus auf die Funktionen, die sie gerade entwickeln. Nur mit diesen Informationen können sie verstehen, wer tatsächlich ihre Funktionen mit welchen Browsern auf welche Weise nutzt. Daher sollten Entwickler Zugriff auf UEM (User Experience Management)-Daten erhalten und daraus ihre eigenen Schlüsse zur Effektivität einer neuen Funktion ziehen. Mit Hilfe dieses Feedbacks können sie auch mit verschiedenen Optionen experimentieren, um den Einfluss auf das Nutzerverhalten zu testen. Dadurch lässt sich sicherstellen, dass die späteren Anwender keine Probleme mit den Funktionen haben.
Foto: Dynatrace
Schritt 4: NoOps durch Automatisierung
Im traditionellen IT-Betrieb gibt es in der Regel ein Team zur Netzwerkverwaltung, das Ausfälle so schnell wie möglich behebt. Anhand von Runbooks starten sie dann zum Beispiel Prozesse oder Server neu, wenn sich das System im Fehlerzustand befindet. Die meisten dieser Tätigkeiten und Aktionen lassen sich automatisieren. So enthalten Runbooks häufig Anleitungen, die Scripts mit "Wenn-Dann"-Bedingungen mit Folgeaktionen ähneln. Werden diese automatisiert, wird der manuelle Routine-IT-Betrieb praktisch überflüssig, so dass sich die Mitarbeiter auf strategische Entscheidungen und die Entwicklung neuer Funktionen konzentrieren können. In Zukunft werden wir in der IT, ähnlich wie in der Produktion, einen Betrieb ohne Menschen erleben. Nur wenn sich das System nicht von selbst heilen kann, sollte der Dienst habende Techniker benachrichtigt werden.
Mit Hilfe dieser Schritte verwandeln sich auch traditionelle Unternehmen in wenigen Monaten zu einem Cloud-nativen Software-Unternehmen. Und nur dann können sie Kunden schneller bessere Services mit einem klaren Mehrwert bieten, um im Wettbewerb mit Startups weiterhin erfolgreich zu sein.