AppDynamics
19.07.2017, 10:57 Uhr
Bedeutet NoOps das Ende von DevOps?
Die Befürworter von NoOps sehnen eine Zukunft herbei, in der sich nie wieder ein Entwickler mit einem IT-Administrator an einen Tisch setzen muss – weil das Deployment vollständig auf IaaS und PaaS basiert.
ustin Vaughan-Brown, Director Product Marketing bei AppDynamics [1]
Automatisierung ist einer der Grundpfeiler von DevOps. Aber was passiert, wenn der Automatisierungsgrad so weit steigt, dass der IT-Betrieb seine Daseinsberechtigung verliert? Wird DevOps dann zu NoOps? Stehen dann vielleicht alle mit leeren Händen da, die sich jetzt auf DevOps spezialisieren? Das oberste Ziel von DevOps lautet, die Zusammenarbeit von Devs und Ops zu verbessern. Die Befürworter von NoOps denken noch radikaler: Sie sehnen eine Zukunft herbei, in der sich nie wieder ein Entwickler mit einem IT-Administrator an einen Tisch setzen muss – weil das Deployment vollständig auf IaaS und PaaS basiert.
Bedeutet NoOps also das Ende von DevOps? Wer das glaubt, liegt falsch. Denn DevOps stirbt nicht, sondern es entwickelt sich weiter. Justin Vaughan-Brown, Director Product Marketing bei AppDynamics [1], nennt sieben Gründe, weshalb dem Ansatz noch ein langes Leben bevorsteht.
1. Der Weg ist das Ziel
„DevOps is a journey, not a destination“ – diese Binsenweisheit kennt jeder, der schon mal eine DevOpsDays-Konferenz besucht hat. Wer sich mit der Geschichte von DevOps auseinandersetzt, wird sehr schnell feststellen, dass die meisten Techniken und Methoden schon wesentlich älter sind als der Begriff. Gleiches gilt für NoOps-Lösungen, die ebenfalls schon Jahre zuvor existierten. Und dennoch wächst DevOps nach wie vor mit einer immensen Geschwindigkeit.
2. DevOps erobert immer mehr Unternehmen
81 Prozent der Großunternehmen und 70 Prozent der kleinen und mittleren Unternehmen arbeiten aktuell an der Einführung von DevOps. Das geht aus RightScales letzter State of the Cloud Survey hervor. Firmen investieren mehr denn je in DevOps – und wie Puppets State of DevOps Report zeigt, zahlt sich das Investment aus. Leistungsstarke IT-Unternehmen, die DevOps anwenden, haben 46-fach schnellere Lead Times – das ist die Zeit, die von einer Idee bis zur funktionierenden Software in Produktion vergeht. Außerdem sorgt DevOps für dreimal niedrigere Change Failure Rates, 96-fache Mean Time to Recovery (MTTR). Jobs im DevOps-Bereich sind also auf absehbare Zeit gesichert.
3. NoOps bietet keine „One-Size-Fits-All“-Lösungen
Wenn DevOps so toll ist, wieso nicht gleich einen Schritt weitergehen – zu NoOps? Zunächst einmal ist NoOps auf Anwendungen beschränkt, die in bestehende PaaS-Lösungen passen. Viele Unternehmen betreiben aber noch immer monolithische Legacy-Software, die in weiten Teilen aktualisiert oder neu geschrieben werden müsste, um in einer PaaS-Umgebung zu funktionieren. Außerdem werden auch in Zukunft immer wieder neue Technologien auftauchen, die mit NoOps nicht zusammenpassen.
4. NoOps folgt den DevOps-Prinzipien
Im DevOps Handbook definieren die Autoren drei Grundprinzipien, von denen sich alle DevOps-Maßnahmen ableiten lassen. Das erste Prinzip heißt „Flow“: Es beschreibt die Bewegung neuer Features durch die CI-Pipeline. NoOps-Lösungen verringern den Reibungswiderstand und beschleunigen diesen Prozess – unter diesem Aspekt lässt sich NoOps als erfolgreiche Umsetzung von DevOps begreifen.
Das zweite Prinzip ist kontinuierliches Feedback. Weil im Rahmen von NoOps Software-Fehler genauso schnell ausgeliefert werden wie neue Features, bedarf es automatisierter Feedback-Systeme, mit denen sich Fehler früh erkennen und beseitigen lassen. Auch hier passt NoOps also ins DevOps-Schema. Das dritte Prinzip von DevOps ist kontinuierliches Lernen und kontinuierliche Verbesserung. NoOps steht exemplarisch für das Ergebnis eines solchen Prozesses, denn letztlich basiert es auf dem erfolgreichen Zusammenspiel neuer Tools, Techniken und Ideen, die das Resultat kontinuierlicher und offener Zusammenarbeit sind.
5. Der IT-Betrieb wird schon vor der Produktion tätig
DevOps bringt mit sich, dass ein Großteil der traditionellen Aufgaben des IT-Betriebs bereits erledigt wird, ehe der Code in Produktion geht. Zu jedem Release gehören Monitoring, Logging und A/B-Tests. CI/CD-Pipelines umfassen Unit-Tests, Security-Scans und Policy-Checks für jeden Commit. Deployments erfolgen automatisch. Controls, Tasks und Nonfunctional Requirements werden nun vor dem Release implementiert, anstatt im Chaos nach einem kritischen Ausfall. Durch die möglichst frühe Mitwirkung von Systemadministratoren, Auditoren, Sicherheitsleuten, QA-Testern und anderen Akteuren wird sichergestellt, dass alle Stakeholder von Anfang an im Boot sind und Probleme rechtzeitig erkannt werden.
6. DevOps stellt Menschen in den Mittelpunkt
Wichtiger noch als die Technologie sind für DevOps die Menschen. Die DevOps-Bewegung begann damit, dass Entwickler und Systemadministratoren auf einer Konferenz zusammenkamen, um Ideen und Erfahrungen über zukünftige Formen der Zusammenarbeit auszutauschen. DevOps bedeutet, alle Beteiligten an der Software-Entwicklung an einem Tisch zu versammeln, sie auf gemeinsame Ziele einzuschwören und die Kooperation sowie den Informationsaustausch entlang des Software Development Lifecycles zu stärken. Dieser kulturelle Aspekt behält hohe Bedeutung – unabhängig von allen technischen Entwicklungen.
7. DevOps erfordert ständiges Lernen
Wie bereits gesagt, bilden kontinuierliches Lernen und kontinuierliche Verbesserung einen der Grundpfeiler von DevOps. Anstatt sich gegenseitig die Schuld zuzuweisen, sollen Entwickler und Systemadministratoren Probleme und Fehler gemeinsam angehen. Aber sogar wenn alles nach Plan läuft, gibt es immer Raum für Optimierungen und neue Lösungen. Weil wir demnach auch im Rahmen von DevOps nie auslernen, kann NoOps nicht das Ende der DevOps-Reise bedeuten. Eingangs wurde gesagt, dass DevOps kein Ziel sei, sondern eine Reise. Auch NoOps ist kein Ziel – sondern allenfalls ein Zwischenhalt.
[1] Justin Vaughan-Brown, Director Product Marketing, ist vorrangig für die Content-Erstellung rund um das Thema DevOps bei AppDynamics verantwortlich, da er früher als Lead und Senior DevOps Market Strategist bei CA Technologies tätig war. Er verfügt über 20 Jahre Erfahrung im Technologie-Marketing und arbeitete für Software AG, Microsoft, BusinessObjects und SAS. Zu seinen Stationen gehören auch hochrangige europäische Marketingrollen bei Datenintegrations-, Sicherheits- und Hochleistungs-Datenbankanbietern. Justin ist Autor mehrerer Strategiepapiere und hat unter anderem auf Konferenzen wie dem Gartner Symposium in Brasilien, Hongkong und Südafrika gesprochen.
Bedeutet NoOps also das Ende von DevOps? Wer das glaubt, liegt falsch. Denn DevOps stirbt nicht, sondern es entwickelt sich weiter. Justin Vaughan-Brown, Director Product Marketing bei AppDynamics [1], nennt sieben Gründe, weshalb dem Ansatz noch ein langes Leben bevorsteht.
1. Der Weg ist das Ziel
„DevOps is a journey, not a destination“ – diese Binsenweisheit kennt jeder, der schon mal eine DevOpsDays-Konferenz besucht hat. Wer sich mit der Geschichte von DevOps auseinandersetzt, wird sehr schnell feststellen, dass die meisten Techniken und Methoden schon wesentlich älter sind als der Begriff. Gleiches gilt für NoOps-Lösungen, die ebenfalls schon Jahre zuvor existierten. Und dennoch wächst DevOps nach wie vor mit einer immensen Geschwindigkeit.
2. DevOps erobert immer mehr Unternehmen
81 Prozent der Großunternehmen und 70 Prozent der kleinen und mittleren Unternehmen arbeiten aktuell an der Einführung von DevOps. Das geht aus RightScales letzter State of the Cloud Survey hervor. Firmen investieren mehr denn je in DevOps – und wie Puppets State of DevOps Report zeigt, zahlt sich das Investment aus. Leistungsstarke IT-Unternehmen, die DevOps anwenden, haben 46-fach schnellere Lead Times – das ist die Zeit, die von einer Idee bis zur funktionierenden Software in Produktion vergeht. Außerdem sorgt DevOps für dreimal niedrigere Change Failure Rates, 96-fache Mean Time to Recovery (MTTR). Jobs im DevOps-Bereich sind also auf absehbare Zeit gesichert.
3. NoOps bietet keine „One-Size-Fits-All“-Lösungen
Wenn DevOps so toll ist, wieso nicht gleich einen Schritt weitergehen – zu NoOps? Zunächst einmal ist NoOps auf Anwendungen beschränkt, die in bestehende PaaS-Lösungen passen. Viele Unternehmen betreiben aber noch immer monolithische Legacy-Software, die in weiten Teilen aktualisiert oder neu geschrieben werden müsste, um in einer PaaS-Umgebung zu funktionieren. Außerdem werden auch in Zukunft immer wieder neue Technologien auftauchen, die mit NoOps nicht zusammenpassen.
4. NoOps folgt den DevOps-Prinzipien
Im DevOps Handbook definieren die Autoren drei Grundprinzipien, von denen sich alle DevOps-Maßnahmen ableiten lassen. Das erste Prinzip heißt „Flow“: Es beschreibt die Bewegung neuer Features durch die CI-Pipeline. NoOps-Lösungen verringern den Reibungswiderstand und beschleunigen diesen Prozess – unter diesem Aspekt lässt sich NoOps als erfolgreiche Umsetzung von DevOps begreifen.
Das zweite Prinzip ist kontinuierliches Feedback. Weil im Rahmen von NoOps Software-Fehler genauso schnell ausgeliefert werden wie neue Features, bedarf es automatisierter Feedback-Systeme, mit denen sich Fehler früh erkennen und beseitigen lassen. Auch hier passt NoOps also ins DevOps-Schema. Das dritte Prinzip von DevOps ist kontinuierliches Lernen und kontinuierliche Verbesserung. NoOps steht exemplarisch für das Ergebnis eines solchen Prozesses, denn letztlich basiert es auf dem erfolgreichen Zusammenspiel neuer Tools, Techniken und Ideen, die das Resultat kontinuierlicher und offener Zusammenarbeit sind.
5. Der IT-Betrieb wird schon vor der Produktion tätig
DevOps bringt mit sich, dass ein Großteil der traditionellen Aufgaben des IT-Betriebs bereits erledigt wird, ehe der Code in Produktion geht. Zu jedem Release gehören Monitoring, Logging und A/B-Tests. CI/CD-Pipelines umfassen Unit-Tests, Security-Scans und Policy-Checks für jeden Commit. Deployments erfolgen automatisch. Controls, Tasks und Nonfunctional Requirements werden nun vor dem Release implementiert, anstatt im Chaos nach einem kritischen Ausfall. Durch die möglichst frühe Mitwirkung von Systemadministratoren, Auditoren, Sicherheitsleuten, QA-Testern und anderen Akteuren wird sichergestellt, dass alle Stakeholder von Anfang an im Boot sind und Probleme rechtzeitig erkannt werden.
6. DevOps stellt Menschen in den Mittelpunkt
Wichtiger noch als die Technologie sind für DevOps die Menschen. Die DevOps-Bewegung begann damit, dass Entwickler und Systemadministratoren auf einer Konferenz zusammenkamen, um Ideen und Erfahrungen über zukünftige Formen der Zusammenarbeit auszutauschen. DevOps bedeutet, alle Beteiligten an der Software-Entwicklung an einem Tisch zu versammeln, sie auf gemeinsame Ziele einzuschwören und die Kooperation sowie den Informationsaustausch entlang des Software Development Lifecycles zu stärken. Dieser kulturelle Aspekt behält hohe Bedeutung – unabhängig von allen technischen Entwicklungen.
7. DevOps erfordert ständiges Lernen
Wie bereits gesagt, bilden kontinuierliches Lernen und kontinuierliche Verbesserung einen der Grundpfeiler von DevOps. Anstatt sich gegenseitig die Schuld zuzuweisen, sollen Entwickler und Systemadministratoren Probleme und Fehler gemeinsam angehen. Aber sogar wenn alles nach Plan läuft, gibt es immer Raum für Optimierungen und neue Lösungen. Weil wir demnach auch im Rahmen von DevOps nie auslernen, kann NoOps nicht das Ende der DevOps-Reise bedeuten. Eingangs wurde gesagt, dass DevOps kein Ziel sei, sondern eine Reise. Auch NoOps ist kein Ziel – sondern allenfalls ein Zwischenhalt.
[1] Justin Vaughan-Brown, Director Product Marketing, ist vorrangig für die Content-Erstellung rund um das Thema DevOps bei AppDynamics verantwortlich, da er früher als Lead und Senior DevOps Market Strategist bei CA Technologies tätig war. Er verfügt über 20 Jahre Erfahrung im Technologie-Marketing und arbeitete für Software AG, Microsoft, BusinessObjects und SAS. Zu seinen Stationen gehören auch hochrangige europäische Marketingrollen bei Datenintegrations-, Sicherheits- und Hochleistungs-Datenbankanbietern. Justin ist Autor mehrerer Strategiepapiere und hat unter anderem auf Konferenzen wie dem Gartner Symposium in Brasilien, Hongkong und Südafrika gesprochen.
