Warum NoOps kein Ziel von DevOps-Initiativen sein darf
Warum NoOps kein Ziel von DevOps Initiativen sein darf (Bild: astephan/ Shutterstock.com)

Warum NoOps kein Ziel von DevOps-Initiativen sein darf

Endlich die Admins loswerden! Und auch kein Geschwafel mehr über eine neue Art der Zusammenarbeit zwischen Entwicklern und Admins mit der DevOps-Kultur.

Der Traum vieler Entwickler ist, nie mehr mit Administratoren sprechen zu müssen, oder?! Zumindest wartet kein Entwickler gerne darauf, dass ein Admin sein gerade entwickeltes Werk erst deployen muss, bevor es die Welt erblickt und die Nutzer es genießen können.

Das Ziel: Deployment ohne Zeit- und Ressourcenverlust

Eine Umgebung direkt aus dem Code anlegen und ohne Zeitverzug ein skalierbares Backend bereitstellen zu können; einfaches Deployment ohne Diskussion und kein Budgetverlust durch die Verwaltung von Ressourcen – so sollte eine erfolgreiche Welt von morgen aussehen.

So jedenfalls versprechen es Plattformen wie Heroku, Amazon Lambda oder Google Firebase. Aber wie sieht die Realität aus? – Oder, viel wichtiger: wie kann man diesen Zielen näher kommen?

DevOps: bedingungslose Automatisierung

Bei der DevOps-Kultur geht es um Automatisierung bis ins letzte Detail. Es gibt dann keine Ausreden mehr für Admins, warum irgendetwas erst am nächsten Tag erledigt werden kann. Aber auch Entwickler können in einer DevOps-Welt keine halbgaren Code-Fragmente mehr zur Restintegration an einen Administrator übergeben.

Damit gelten für Entwickler und Administratoren die gleichen Regeln wie für alle Branchen. Die (IT) Revolution frisst mit dem DevOps-Mindset (endlich) ihre eigenen Kinder und kann als Industrie eine neue Reifegrad-Stufe erreichen.

Der ITIL-Ansatz: Ein Anachronismus?!

Im Nachhinein scheint es schon fast anachronistisch, wie wir 30 Jahre lang mit ITIL-Prozessen versucht haben, im Betrieb der IT-Lösungen etwas in Ordnung zu bringen, von dem keiner weiß, ob es im Design-Prozess überhaupt jemand bedacht hat.

Da ist die DevOps-Logik, den Architekten der Lösung von vornherein für Skalierbarkeit und Performance verantwortlich zu machen, genau richtig. Und das geht nur, wenn das Monitoring ganz tief integriert ist, bei der Entwicklung bereits Produktionsmetriken verwendet werden und alle am Entwicklungs- und Betriebsprozess Beteiligten erfahren, wie welche UX-Elemente geklickt und verwendet werden.

All das ist in großen System-Umgebungen jedoch nicht in ein paar Wochen implementiert und bedarf einer Menge menschlicher Energie. Und dies in der Regel auch nicht einmalig, sondern als kontinuierlicher Regelprozess.

“Klare Empfehlung: #DevOps für alle Projekte jenseits des Prototypenbaus“

Twittern WhatsApp

NoOps: neues Modell mit eingeschränktem Anwendungsgebiet

Anstatt uns zu freuen, dass Entwickler und Administratoren endlich ein gemeinsames Vorgehensmodell gefunden haben, kommt jetzt mit NoOps die nächste Welle auf uns zu und gefährdet bereits erarbeitetes gemeinsames Terrain.

Dabei ist der NoOps-Gedanke in seiner Anwendbarkeit klar auf ein eingeschränktes Aufgabengebiet begrenzt und nicht so universell anwendbar wie das DevOps-Gedankengebäude der bedingungslosen Automatisierung.

Für Projekte, die sich klar in eine feste Plattform as a Service-Umgebung (PaaS) wie Heroku, Lambda oder Firebase einfügen und komplett auf diese Umgebungen setzen, kann NoOps ein erreichbares Ziel sein. Das sind heute vor allem Startups oder schnelle Evaluations-Projekte. Erkauft wird NoOps dann durch einen massiven Vendor-Lock-In und mit einer echten Wachstumsbremse. Denn wenn die Systemlandschaft wächst, muss das gesamte Team noch auf das neue Mindset DevOps eingeschworen werden.

Damit ist der NoOps-Anwendungsbereich wirklich klein und die aktuellen Diskussionen über diesen Ansatz werfen viele gut laufende DevOps-Projekte wieder zurück. Den PaaS-Anbietern kann das Zündeln und die Diskussion nur kurzfristig nutzen, aber eine wirkliche Weiterentwicklung findet eher nicht statt.

DevOps ist eine Reise und kein Zustand

Aus dem Praxisbetrieb bei synaix und der Kooperation in/mit verschiedenen Projekten und Unternehmen kann ich die Implementierung von DevOps-Teams und -Strukturen für alle Projekte jenseits des Prototypenbaus unbedingt empfehlen.

DevOps ist eine Reise und kein Zustand. – Machen Sie sich auf den Weg! Denn Menschen im Betriebsprozess bekommt man nur (weg-)automatisiert, indem man alle Projektbeteiligten mit auf den Weg nimmt und alle Möglichkeiten vorher gemeinsam bedenkt und in Code umsetzt.

(Und keine Sorge: Auf die Admins, die damit „frei“ werden, warten schon die nächsten Betriebsthemen.)

Passende Artikel

Wie wird IT morgen betrieben: Zentral, Dezentral – oder egal? Weiterlesen

Wie wird IT morgen betrieben: Zentral, Dezentral – oder egal?

Experten warnen vor weltweiter Cloud-Krise Weiterlesen

Experten warnen vor weltweiter Cloud-Krise

Digitale Zukunft für den deutschen Mittelstand – so geht‘s Weiterlesen

Digitale Zukunft für den deutschen Mittelstand – so geht‘s

Newsletter
Lassen Sie sich per E-Mail über neue Beiträge von Stefan Fritz informieren.

Erhalten Sie meinen regelmäßigen Newsletter mit allen neuen Artikeln bequem per Email.