Wenn man die DevOps Trends 2019 betrachtet, sticht einem an erster Stelle der Begriff NoOps ins Auge. Was steckt hinter diesem Trend? Muss ich mich als Operations und Infrastructure Engineer nun ernsthaft um meine Zukunft sorgen?
Die Idee von NoOps ist nicht neu. Bereits 2011 schreibt Mike Gualtieri, VP & Principal Analyst bei Forrester Research:
NoOps beschreibt eine Welt in welcher sich das Entwicklungsteam nicht mehr mit dem Operations auszutauschen braucht, da der Fluss aus der Entwicklung in die Produktion vollständig von der Infrastruktur entkoppelt und automatisiert ist.
Betrachtet man das Ziel NoOps allerdings etwas genauer, dann wir klar, dass NoOps überhaupt erst durch eine perfekt funktionierende Infrastruktur und Deployment Pipeline ermöglicht wird. Adrian Cockfront, Vizepräsident bei AWS, beschreibt in seinem Blogpost „Ops, DevOps and PaaS (NoOps) at Netflix“ aus dem Jahr 2012 sehr ausführlich, welche Hürden es für ein Unternehmen auf dem Weg zu NoOps zu bewältigen gibt.
Bei Netflix führte dieser Weg vom klassischen on-premises Datacenter in die AWS Cloud. Über Jahre hinweg haben Dev und Ops gemeinsam an Lösungen gearbeitet, welche es den Entwicklungsteams ermöglicht haben, auf Knopfdruck, neue Features direkt in Amazon Machine Images zu deployen. Diese Images werden vollautomatisch in Regionen überspannende Autoscale Groups eingebunden. Dadurch war es für Netflix bereits 2012 möglich, mehrere tausend Server Instanzen über dutzende AWS Datacenter hinweg, mit einem immer kleineren Team von Cloud Operations Reliability Engineers zu betreiben.
Netflix Entwickler können ihren Code so, ohne je mit einem Ops Engineer gesprochen zu haben, direkt in die Produktion überführen. Falls dabei etwas schief geht, wird das Entwicklungsteam automatisch darüber benachrichtigt.
Adrian Cockfort nennt dies NoOps. Ich tendiere dazu, es Continuos Deployment zu nennen.
Ohne Ops kein NoOps
Eine Heerschar von Infrastruktur Architekten, Sysadmins und Operations Engineers hat also über Jahre hinweg die perfekte Deployment Pipeline gebaut, welche es den Entwicklern erst ermöglicht hat, ihren Code sorglos in die Cloud zu überführen. Ein perfekt justiertes Monitoring sorgt dafür, dass Alarmierungen direkt bei den dafür zuständigen Entwicklerteams eingehen. Ein eigenes Operations Team wird für den Betrieb nicht mehr benötigt. Lediglich ein kleines Team von Reliabiltiy Engineers ist darum besorgt, dass beim externen Cloud Betreiber alles wie vorgesehen läuft.
Adrain Cockfort nennt dies NoOps. Ich tendiere dazu, es „Mission Accomplished“ zu nennen.
NoOps als Momentaufnahme
NoOps erscheint im Gegensatz zu DevOps nicht als Weg, sondern als ein Ziel. Prinzipiell die Wunschvorstellung einer perfekten Welt, in welcher es nichts zu verbessern und nichts dazuzulernen gibt. Eine Welt, an der es nichts mehr zu ändern gibt.
Denn eines ist sicher, bei der nächsten Architekturanpassung sind es wiederum die Infrastruktur Architekten, die Sysadmins und die Operations Engineers die gefragt sind um die dem System zugrunde liegende Infrastruktur auf die neuen Anforderungen auszurichten, damit die sorglos Pipeline auch weiterhin funktioniert.
NewOps anstelle von NoOps
Während es NoOps in letzter Instanz also auf der einen Seite dem Entwicklungsteam ermöglicht, neue Features und Anpassungen ohne Handover direkt in die Produktion zu überführen, entlastet es gleichzeitig auch die Operations Engineers vom reaktiven Troubleshooting. Anstelle sich mit Problemen und Bugs herumzuschlagen, hat das Operations Team nun endlich Zeit all die Aufgaben zu erledigen, welche einen wirklichen Mehrwert schaffen. Zum Beispiel den nächsten Service in den NoOps Zustand zu bringen. Dieser Weg führt nicht über NoOps, sondern über NewOps.
