Kultur, Theorie und Praxis. Was bedeutet eigentlich DevOps?
Veröffentlicht am 28.10.2020
- Was ist DevOps? | Dev-Insider
- Was bedeutet eigentlich „DevOps“? | t3n – digital pioneers
- DevOps explained – Devops.ch
- DevOps aus Sicht eines Systemadministrators – Devops.ch
- DevOpsDaysZH 2017 … | Dirks Logbuch
- Praktische Administration – Speaker Deck
- OpenRheinRuhr 2018 – Ops hates containers! Why?
Musik von MDK
Intro & Outro: MDK – Super Ultra (Smooth Jazz Remix)
MDK auf YouTube
Finde den neuen Podcast echt gut. Würde mir gerne mal das Buzzword „Container“ wünschen. Natürlich im Zusammenhang mit IT 🤪. Die Devops-Folge war sehr informativ. Hier hat man gut erkannt, dass die Funktion des Devops nicht zur Reduktion der Arbeitsplätze eingesetzt werden sollte, um einen effizienten Ablauf zwischen Betriebsführung und Entwicklung zu erhalten bzw. zu erzielen. Weiter so Leute 🥳🥳🥳
Vielen Dank für Dein Feedback und Dein Lob Sascha. Dein Wunsch Wunsch-Buzzword “Container” habe ich in unsere Liste aufgenommen.
Aber genau mit den von Dir angeführten Missverständnissen möchten wir gerne aufräumen. Ich freue mich darüber, dass es uns anscheinend gelungen ist.
Hallo Ihr beide,
ich bin dann jetzt auch mal bei Folge 3 angekommen. Ich finde es schön zu hören, dass Ihr euch so schnell an den Redefluss des anderen gewöhnt und angepasst habt. Diese Folge war richtig rund und ich hab interessiert zugehört.
Zum Thema DevOps meine ich, dass man es nicht zu ernst nehmen sollte. Will sagen: Viele Devs oder Ops mittleren und höheren Alters fühlen sich sehr überrumpelt, wenn in einer Stellenbeschreibung DevOps Erfahrung gewünscht ist. Ihnen gebe ich dann immer zu bedenken, dass es nur eine Umschreibung für etwas ist, was viele von ihnen schon lange mal mehr, mal weniger, gemacht haben.
Die Ops kennen sich meist bereits mit Scripting aus, da Automatisierung meist das zu erreichende Ziel ist. Da ist der Weg zum Verständnis für Anwendungsentwicklung nicht zu lang.
Die meisten Devs wiederum, haben für das eine oder andere Projekt in der Vergangenheit schon ein Grundsystem aufsetzen müssen, um mit der eigentlichen Entwicklung beginnen zu können. Vllt. haben sie nicht gleich eine ganze Serverarchitektur aufbauen müssen, mussten aber ihre Basistechnologien wählen, evaluieren und einrichten.
Die meisten von uns haben also schon DevOps gemacht bevor es cool war 🙂
Für beide Fraktionen gelten meines Erachtens zwei Eigenschaft, welche sie mitbringen müssen. Mut, die eigene Komfortzone zu verlassen und Motivation, neues zu lernen.
Ich freu mich schon auf die nächste Folge.
Pierre, danke für das Lob.
Dass wir das auf Systemebene schon immer gemacht haben, ist richtig, aber die Entwickler haben einfach das bessere Marketing …
Das Problem ist, dass sehr häufig und vermutlich auch eher in grösseren Firmen (Weiter)Entwicklung und Betrieb getrennt sind. Das erlebe ich auch auch sehr vielen Konferenzen.
Guckst Du auch: https://www.deimeke.net/dirk/blog/index.php?/archives/3814-DevOpsDaysZH-2017-….html
Hallo ihr beiden
Vielen Dank für den tollen Podcast. Ich habe dieser Folge interessiert zugehört, da ich, wie Mario, ebenfalls nicht genau wusste, was ich unter DevOps nun zu verstehen habe. Vor allem darum, weil meiner Ansicht nach viel in dieses BuzzWord “verpackt” wird. Ich persönlich habe die Erfahrung gemacht und mache sie immer noch, dass der Wegfall von Ressourcen damit kompensiert wird, dass der Entwickler jetzt auch noch die Arbeit des nicht existenten Kollegen zusätzlich übernehmen darf und dass dann als DevOps verkauft wird. Dasselbe beobachte ich im Bereich der Cloudifizierung, da das Management sich der Tatsache nicht bewusst ist, dass das Betreiben einer Cloud auch mit Arbeit verbunden ist und auch von irgendwem erbracht werden muss.
Dann mache ich mich mal auf den Weg und höre mir eure weiteren Werke an und freue mich darauf etwas Neues zu lernen.
Grüsse aus der Schweiz
Hampa
Vielen Dank, Hampa.
Genau, weil es diese Begriffsverwirrung gibt – ich kenne ein halbes Dutzend Definitionen von DevOps – machen wir diesen Podcast.
Ich sehe das Thema nicht als Sparmassnahme, sondern eher als ganzheitlichen Ansatz. Wir machen in unserem Team die Weiterentwicklung und den Betrieb der Plattformen unter unsere Kontrolle.
Was wir im Betrieb herausfinden, fliesst in die Weiterentwicklung ein. (Wir sind kein DevOps-Team). In der Anwendungsentwicklung gab es diesen Ansatz noch nicht, da gab es häufig eine Grenze zwischen Betrieb und Entwicklung, die so genannte “Wall of Confusion”.
Für Cloud gebe ich Dir Recht. Der Begrifssschwachsinn gipfelt im Begriff “Serverless” …