Blog
Zum Ende der Metadaten springen
Zum Anfang der Metadaten

Wenn über DevOps gesprochen wird, gibt es meiner Erfahrung nach vielfältige "Interpretationen". Die einen treffender, die anderen ... weniger.

Worin sich alle einig sind (egal ob Sie es aus meiner Sicht verstanden haben oder nicht):

  • Wir wollen agil Software entwickeln

  • kleine Iterationen -> schnelleres Feedback → weniger Kosten durch vermeidbare "Rolle rückwärts"
  • "die Cloud" hat ganz neue Anforderungen an Betrieb. Ist komplexer, ist vielfältiger. Ist durch reine Manpower nicht mehr qualitativ sicherzustellen.

 

Was viele noch sagen:

  • Wir wollen die Zusammenarbeit zwischen Entwicklung und Betrieb verstärken

 

Wo sich die Geister leider scheiden:

  • wer ist denn "der DevOp"

 

Nun wird's persönlich: Kurzum: DEN gibt es nicht!!
Und nein, bitte betitelt nun nicht einfach alte "Betriebsführer" aka "Ops" um nur weil Sie eben mal Ansible, Chef, Puppet, Salt und Co. kennen oder mit OpenShift, CloudFoundry oder Rancher irgendwelche (Docker, Kubernetes) Container an den Start bringen müssen.

Nur weil man für Cloud / CaaS / Container Platforms / Scaled Applications ... <name it> andere Mittel braucht und nicht mehr wie früher ein WAR / EAR in "den" JBoss, Tomcat/TomEE oder WebSphere knallt, heißt das noch lange nicht das ist "devOp". Nein, auch nicht wenn man da "Variablen" drin benutzt ... NEIN NEIN NEIN

 

Was bedeutet es aber dann?

  • DevOp ist eine Art "Kultur", keine Rolle
  • SW-Entwickler und Ops sind eben beide T-Shaped people ... Sie haben Ihr Spezialwissen, das T wird aber breiter
    • vielleicht ... ich nenne Sie ab jetzt: pi-shaped (π) teams (Zwinkern)
  • DevOp ist ganzheitlich. Ganz heißt: von vorne bis hinten. Man behilft sich gegenseitig, behindert sich aber auch nicht gegenseitig.
  • Man entwickelt das vorgehen gemeinsam, nicht einseitig.
  • Man bespricht Probleme zusammen, die Spezialisten bieten aber primär an, das ihrer Domäne am nächsten liegende Problem für alle beteiligten zu lösen
  • Es gibt kein "Die" und "Wir"
  • der Grad der Automatisierung und Reproduzierbarkeit sind zwei wichtige Faktoren für ein erfolgreiches, nachhaltiges Produkt
  • "Machen wir später" ist out. Wir liefern (Idealfall) ab der ersten Minute.
  • Wir entwickeln uns auch hier kontinuierlich weiter, genau wie wir es in der Softwareentwicklung selbst tun.
    • Das muss im ersten Schritt nicht perfekt sein, MVP auch hier.

 

Und was passiert wenn ich das eben doch anders mache?

  • dann haben wir "DevOps Teams" die autark arbeiten und Vorgaben entwickeln wie "Pakete" geschnürt werden müssen
  • dann haben wir SW Entwicklungsteams, die sich erst zum spätmöglichsten Zeitpunkt in der Entwicklung um "Deployment" kümmern
    • Bis dahin einfach auch "ihr eigenes Ding" machen
  • Es existieren zwei Welten, zwei Wahrheiten
  • Irgendwo muss was "über den Zaun" geworfen werden
  • Grad der Automatisierung leidet immens
  • Aussagen zur Produktreife durch reproduktion sind stark eingeschränkt
  • Es wird nicht zusammengearbeitet, sondern im Fehlerfall weiter Fingerpointing betrieben

 

Liegt an euch was Ihr d'raus macht ... ich habe euch meine Meinung dazu gesagt, überzeugt mich vom Gegenteil (Zunge)

 

 

 

 

tl;dr

nein DevOps ist nicht tot, nur leider aus meiner Sicht oft falsch verstanden. Der Begriff ist abgenutzt; von Buzzword-Bingo spielern wurde die Sau nun so lange durch's Dorf getrieben und mit Altlasten beladen, dass der Blick auf das richtige und wichtige verloren gegangen ist ... vielerorts

Ein Artikel zum Nachdenken, zum Kommentieren, zum aufregen ... etwas für die besinnliche Weihnachtszeit also (Zwinkern)