Ist DevOps noch zeitgemäß?

Sonstiges Spielwiese
1

Da scheint ein bisschen Umdenken einzusetzen:

Im Prinzip ist DevOps eine gute Idee, einfach weil Code schreiben und über den Zaun werfen nicht zielführend ist. Die Frage ist natürlich immer die Umsetzung. Ich habe nichts dagegen, mal in AWS oder GitHub was einzurichten. Ich will aber nicht für die Infrastruktur verantwortlich sein, einfach weil ich nicht genug Zeit und Nerven habe, mich da genug einzuarbeiten. Leider spielen viele Firmen das gleiche Spiel wie mit „Fullstack Entwicklern“, der Programmierer soll kostensparend zur eierlegenden Wollmilchsau werden - was aber nicht die Grundidee von DevOps war.

Ich finde, ein CEO, der sich Fullstack-DevOps mit UX-Erfahrung wünscht, sollte auch seine Gehirn-Op von einem Allgemeinmediziner durchgeführt bekommen…

1 „Gefällt mir“
3

Die Unterscheidung gibt es in vielen Unternehmen nicht mehr, alle sind (in der Praxis mehr oder weniger) DevOps. Und dann gibt es eben diese Einstellung „DevOps ist gut, das machen alle“, ohne dabei zu berücksichtigen, ob man es auch gut macht. Wie schon gesagt, Code über den Zaun werfen kann es auch nicht sein, aber ich will auf der anderen Seite keinen Kybernetes-Cluster oder Apache Kafka aufsetzen. Und da sollten die Firmen auch ein wenig zurückrudern und DevOps vernünftig gestalten - da mache ich auch gerne mit.

1 „Gefällt mir“
4

Ist das denn so extrem? In der Regel hat man da als Entwickler doch relativ wenig mit zu tun. Das wird einmal eingerichtet, aber so viel ist da ja nicht zu tun. Die Entwickler entwickeln in erster Linie.

Klar, es kann ganz kleine Teams geben, wo das dann etwas mehr ist, aber normalerweise hat man eine gewisse Teamstärke und dann verteilt sich das. Und das bedeutet nicht, für die Infrastruktur verantwortlich zu sein.

Nehmen wir einfach so ein SAFe Umfeld mit einem Release Train: Man hat dann halt sowas wie ein System Team, das hier einiges verantwortet. (Aber da muss nicht die eigentliche Infrastruktur verantwortet werden. Die liegt ja in der Regel in einer Cloud oder einer ähnlichen Umgebung.)

Ich habe schon Entwickler getroffen, die da tatsächlich recht extrem unterwegs war. Da wurde direkt in Produktion deployed. Neue Features waren dann schnell da, Ausfälle scheinen nicht so wichtig zu sein, die Daten vermutlich auch nicht … und wenn man was kaputt gemacht hat, dann wurde es schon schnell repariert … Aber sowas ist doch relativ extrem, und eher unüblich. (Oder ich kenne im beruflichen Umfeld schlicht nur Kunden, bei denen es halt entsprechend kritisch gesehen wird. :slight_smile: )

5

Ich würde sagen, das Pendel schlägt gerade in eine realistischere Richtung aus.

Früher: Entwickler schreiben Code, alles andere betrifft sie nicht
DevOps (to the Extreme): Entwickler betreuen die gesamte Infrastruktur mit, sind selbst fürs Deployment Vorgehen etc. verantwortlich.

Der gesunde Mittelweg, wo es sich meines Erachtens hin bewegt: Entwickler arbeiten mit dem Systems/Infrastruktur Team zusammen und bekommen Berechtigungen und Verantwortlichkeiten in dem Umfeld Dinge zu tun, die ihrer Arbeit förderlich ist. So erstellen wir als Entwickler Deployment-Tickets für Deployments in Produktion. Aber es gibt mit Business, Projektleitung Absprachen wann deployed wird - koordiniert vom Release-Management. Die sind auf Input und Austausch der Entwickler angewiesen, aber die Verantwortung liegt nicht bei den Entwicklern. Und die Freigabe der Deployments liegt bei dem Releasemanagement.

Ich möchte als Entwickler nicht erst X-Formulare ausfüllen um irgendwas zu deployen oder Änderungen an der Build-Pipeline vorzunehmen.

Ich möchte aber auch nicht die Verantwortung für die gesamte Build-Pipeline oder die Deployments haben.

Und nach meinem dafürhalten bewegt es sich dahin. Unser Kunde hat ein eigenes „DevOps“-Teams (Wie sinnvoll so eine Name im Sinne von DevOps ist, sei mal dahingestellt) - aber die kümmern sich um die gesamte Infrastruktur, dass die da ist und unterstützen einen.

1 „Gefällt mir“
6

„DevOps“ wird heute oft als „modernes Synonym“ für SysOps verwendet, meist um hip zu wirken und/oder Entwickler anzuziehen die auch nur auf Worthülsen aus sind.
Für mich ist ein eindeutiges Zeichen dafür, dass man ein explizites „DevOps Team“ hat :smiley:

Ansonsten sollte man ein (gut funktionierendes) Platform Team haben, das sind Leute die die Grundlagen herstellen damit Feature Teams DevOps machen können, dann muss das feature Team auch nicht mehr die gesamte Infrastruktur verwalten.
zB. macht das Platform Team die Infrastruktur an sich und ein Framework bzw. templates um MS zu deployen und die MS zu konfigurieren in verschiedenen Umgebungen.

Wenn ich als Feature Entwickler meinen „scheiss“ dann auf die Kunden loslasse, muss ich das beobachten (Visibility/Traceability/Monitoring etc.) und ggf. eingreifen, nicht erwarten das jemand anders mir dann sagt was nicht geht.

Ob ich das als Feature Entwickler für alle meine features mache oder es im Team eine rotierende Rolle die sich darum kümmert is nebensächlich.

1 „Gefällt mir“
7

:confused: Hähwas? Wo das denn?

Wenn sich mal wieder die Gelegenheit ergibt, einen Rant über dieses gefährlich fehlgeleitete Konzept vom „Full-Stack“ abzulassen, nutze ich das doch gerade mal. Dass das unsinnig ist, ist wohl den meisten (Entwicklern) klar. Wer meint, er wäre „Full-Stack-Entwickler“, der möge sich bei mir melden, und dann reden wir mal darüber, was genau das bedeuten soll.

Anekdotisch: Ich hatte mir mal die Aufgabe überlegt: Eine MongoDB im Hintergrund (mit irgendwas trivialem, sowas wie „Nutzername+Notiz“). Darüber eine Node-Express-REST-API. Und ein Frontend dazu, in React oder Angular. Der Nutzer kann sich einloggen, sieht seine „Notiz“ angezeigt, und dann sie ändern und in der DB speichern. Das ganze halt noch schick in irgendwelche Containerchen verpackt und in AWS deployt. Und die Fragen, die ich dann stelle:

  • Kannst du so ein System „von 0 auf“ aufsetzen, ja oder nein? (Die meisten würden sagen „Ja“ - aber die nächste Frage ist wichtig:)
  • Wie lange würdest du dafür brauchen? Ein paar Stunden, eine Woche, einen Monat?
  • Und vielleicht die wichtigste Frage: Könntest du das ohne Google und StackOverflow?

Spätestens bei der letzten Frage würden wohl die meisten zusammenzucken, und kleinlaut zugeben: Naja, vielleicht, wenn alles glatt läuft, aber … das tut es nie. Und wenn man keine Fehlermeldungen googeln und keine murxigen Workarounds unverstanden aus Issues und Stackoverflow rauskopieren kann, ist man schnell mit seinem Latein am Ende…

Die Verantwortlichkeiten, die Entwicklern aufgehalst werden, machen es praktisch unmöglich, in allen Bereichen kompetent genug zu sein, um keinen Mist zu bauen. Ich verstehe nicht, wie man sich List of data breaches - Wikipedia ansehen und dann immernoch mit den Schultern zucken und sagen kann „Ja, aber uns wird das nicht passieren! Unser Entwickler kann Datenbanken. Und HTML-Programmierung kann er auch!!!111“

Jahrzehntelang war eines der wichtigsten Prinizipen in der IT die Entwicklung von Schnittstellen, und so viel Information wie möglich zu verstecken (vor jedem, der diese Information nicht wirklich undebedingt braucht). Und (auch wenn das etwas philosophisch klingt:) Jahrhundertelang war eines der wichtigsten Prinzipien der Menschheit zunehmende Spezialisierung. Dass das sogenannte „DevOps“ da zumindest in einem engen Bereich genau die entgegen gesetzte Richtung eingeschlagen hat, war sicher nicht hilfreich…

2 „Gefällt mir“
8

Also das ist in den Bereichen so, die ich kenne. Und wenn man mal etwas in sich geht: Wie soll das auch anders gehen? Du hast das ja auch schon etwas erläutert. Das könnte ich noch weiter vertiefen, aber es würde auf das hinaus laufen, das Du doch auch schon geschrieben hast - nur eben auf andere Bereiche ausgedehnt.

Es reicht doch, dass ein Entwickler mit seinen check ins einen Build kaputt macht. Will man den auch noch auf die Infrastrutur los lassen (Dann macht er gleich die ganze Infrastruktur kaputt? :slight_smile: )

Aber da geht es aus meiner Sicht generell um das Verständnis, was abgeht. Ich muss kein Held sein, der eine Azure Private Cloud aufbauen kann / konfigurieren kann. In der Regel muss man da auch nicht CI/CD Pipelines konfigurieren. Man muss verstehen, was da abgeht („Hr. Jenkins schreibt Emails - die sollte man verstehen“ oder so). Aber - so ich da nicht als Verantwortlicher für den Bereich genannt bin, muss ich da nicht der Held sein. Ich werde in der Regel für eine Aufgabe bezahlt: Software Entwicklung. Da es viele Berührungspunkte gibt, muss man andere Dinge verstehen. Aber da reicht ein Verständnis aus - da braucht man nicht die tiefe praktische Erfahrung (so man das nicht gezielt machen will).

Und wenn es das bei Dir nicht gibt und Du sowas willst: Vielleicht willst Du ja schlicht und einfach wechseln?

Also nicht missverstehen: Das Wissen ist wichtig. Ich habe daher auch einiges wie PRINCE2 (war damals mal wichtiger ehe alle agile sein wollten) und so gemacht. Was also mit Software Entwicklung nichts zu tun hat. Aber man muss da halt mitreden können / die Anderen verstehen können. Das ist bei DevOps nicht anders.

Ich warte sehnsüchtig auf mein Turing Pi2 - da ich mit einem Kubernetes Cluster spielen will ohne zu viel Strom bezahlen zu müssen. Da geht es aber auch mehr um das tiefe Verständnis. Ich werde sowas nie offiziell administrieren (Wobei ich niemals nie sagen sollte. Mit dem tiefen Verständnis, das ich mir gerne aufbaue, bin ich auch schon bei Eskalationen in Task Forces gelandet, die nichts mit Entwicklung zu tun hatten… )

==> Es geht also mehr über den Überblick und dem Verständnis von Abläufen und so. Was wurde aus welche Grund wie gelöst?

Aber egal - das muss man alles nicht zu sehr vertiefen. Ich denke, dass wir gar nicht so weit auseinander sind mit unseren Meinungen.