© Excellent backgrounds/Shutterstock.com
Java Magazin
Pro und Contra DevOps

Warum wir auf NoOps setzen

Eigentlich wollten wir für unser neues SaaS-Produkt DevOps einführen. Letztendlich landeten wir aber bei NoOps. Warum das Sinn macht und wie es dazu kam, möchte ich hier umreißen.

Bernd Greifeneder


Let’s face it. Der klassische Anwendungsbetrieb ist tot. Wozu braucht man jemanden, dem man mit Runbooks alles erklären muss, wenn dann doch Probleme immer zu den Entwicklern eskaliert werden und Standardprobleme von Automatisierungstools gelöst werden. NoOps bietet hier einen radikalen neuen Ansatz, der auf verstaubte Betriebskonzepte verzichtet und DevOps als Enabler für die Entwicklung sieht. Es schafft das Dogma von „Männern, die auf Dashboards starren“ ab. In dieser neuen Welt muss sich der Betrieb neu erfinden, indem er sich selbst überflüssig macht, also NoOps.

Wie wir bei NoOps angekommen sind? Unser Engineering-Team hat vor einigen Jahren eine sehr effiziente CI aufgebaut, aber genau null SaaS-Erfahrung. Also machten wir uns mit einem Pilotprojekt daran, unser Produkt für eine handvoll Kunden als SaaS-Service in unserem damaligen Rechenzentrum in den USA zu hosten. Dass es drei Monate dauerte, die benötigte Hardware zu bekommen, war frustrierend, aber noch verständlich. Endlich im Betrieb, flog uns der Beweis, dass wir doch keine vollständig fehlerfreie Software bauen, um die Ohren. Wir brauchten einen raschen Fix für einen der Pilot-SaaS-Kunden. Nachdem unsere CI schon damals in ca. 30 Minuten aus dem Code von hundert Entwicklern einen getesteten Build mit Installer produzieren konnte, war es klar, dass der Fix innerhalb von 24 Stunden auszurollen sei. Also auf zum Change-Request-Meeting. Was? Das ist erst am Donnerstag? Also drei Tage warten und dann erst im CRM einplanen. Wie bitte? Ihr werdet den Fix für nächsten oder übernächsten Donnerstag fürs Deployment einplanen? Und ihr gebt uns keine Berechtigungen, es selbst zu machen? Ihr wollt allen Ernstes den Kunden zwei bis drei Wochen warten lassen?

Nachdem wir so viel in eine schnelle und umfassende CI investiert hatten, brach hier für mich die Welt zusammen. Es kann doch nicht sein, dass Operations dem Business im Weg steht. Die Anforderung, AWS-ähnliche Automatisierungsschnittstellen zu bekommen, führte zu dem eher verzweifelten Angebot einer selbstgestrickten Private-Cloud des Betriebsteams. Es wurde schnell klar, dass so ein Unterfangen mit bloßen Puppet- und Chef-Kenntnissen sowie mangelnder Agilität nicht zu bewerkstelligen war, um den gewünschten Automatisierungsgrad zu erreichen. Die Folge war eine radikale Auslagerung des neuen SaaS-Produkts in die AWS-Public-Cloud. Nur wer betreibt die dort laufenden Instanzen nun? Aus Sicht der Entwickler war es undenkbar, eine Menge Runbooks zu sch...

Java Magazin
Pro und Contra DevOps

Warum wir auf NoOps setzen

Eigentlich wollten wir für unser neues SaaS-Produkt DevOps einführen. Letztendlich landeten wir aber bei NoOps. Warum das Sinn macht und wie es dazu kam, möchte ich hier umreißen.

Bernd Greifeneder


Let’s face it. Der klassische Anwendungsbetrieb ist tot. Wozu braucht man jemanden, dem man mit Runbooks alles erklären muss, wenn dann doch Probleme immer zu den Entwicklern eskaliert werden und Standardprobleme von Automatisierungstools gelöst werden. NoOps bietet hier einen radikalen neuen Ansatz, der auf verstaubte Betriebskonzepte verzichtet und DevOps als Enabler für die Entwicklung sieht. Es schafft das Dogma von „Männern, die auf Dashboards starren“ ab. In dieser neuen Welt muss sich der Betrieb neu erfinden, indem er sich selbst überflüssig macht, also NoOps.

Wie wir bei NoOps angekommen sind? Unser Engineering-Team hat vor einigen Jahren eine sehr effiziente CI aufgebaut, aber genau null SaaS-Erfahrung. Also machten wir uns mit einem Pilotprojekt daran, unser Produkt für eine handvoll Kunden als SaaS-Service in unserem damaligen Rechenzentrum in den USA zu hosten. Dass es drei Monate dauerte, die benötigte Hardware zu bekommen, war frustrierend, aber noch verständlich. Endlich im Betrieb, flog uns der Beweis, dass wir doch keine vollständig fehlerfreie Software bauen, um die Ohren. Wir brauchten einen raschen Fix für einen der Pilot-SaaS-Kunden. Nachdem unsere CI schon damals in ca. 30 Minuten aus dem Code von hundert Entwicklern einen getesteten Build mit Installer produzieren konnte, war es klar, dass der Fix innerhalb von 24 Stunden auszurollen sei. Also auf zum Change-Request-Meeting. Was? Das ist erst am Donnerstag? Also drei Tage warten und dann erst im CRM einplanen. Wie bitte? Ihr werdet den Fix für nächsten oder übernächsten Donnerstag fürs Deployment einplanen? Und ihr gebt uns keine Berechtigungen, es selbst zu machen? Ihr wollt allen Ernstes den Kunden zwei bis drei Wochen warten lassen?

Nachdem wir so viel in eine schnelle und umfassende CI investiert hatten, brach hier für mich die Welt zusammen. Es kann doch nicht sein, dass Operations dem Business im Weg steht. Die Anforderung, AWS-ähnliche Automatisierungsschnittstellen zu bekommen, führte zu dem eher verzweifelten Angebot einer selbstgestrickten Private-Cloud des Betriebsteams. Es wurde schnell klar, dass so ein Unterfangen mit bloßen Puppet- und Chef-Kenntnissen sowie mangelnder Agilität nicht zu bewerkstelligen war, um den gewünschten Automatisierungsgrad zu erreichen. Die Folge war eine radikale Auslagerung des neuen SaaS-Produkts in die AWS-Public-Cloud. Nur wer betreibt die dort laufenden Instanzen nun? Aus Sicht der Entwickler war es undenkbar, eine Menge Runbooks zu sch...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang