DevOps funktioniert nicht

[bigvic]

.. sagt inzwischen sogar Gartner: https://www.heise.de/ix/meldung/Gartner-DevOps-funktioniert-nicht-4072904.html

Aye Aye, Captain Obvious

[Gast Arvi]

Den Artikel hast du aber schon gelesen oder? Gartner sagt nicht, dass DevOps als Konzept nicht funktioniert, sondern dass es in der Regel am Management scheitert und der Hype langsam abflacht. Wenn ich mir manche Kommentare hier im Forum ansehe, wo der Entwickler dann Kunden-Produktivsysteme administrieren und Sysadmin-Ober-Tecki auch Funktionen in der Kundensoftware implementieren soll, dann sieht man doch schon, das es sich hier um große Management Fehler handelt wo DevOps praktisch nicht verstanden wurde und das Management quasi nur die Buzzwörter "Synergie zwischen Entwicklung und Administration" als Quintessenz wahrscheinlich durch Magazine aufgeschnappt hat, ohne wirklich zu verstehen, wann und in welchem Umfang DevOps Sinn macht. Ich weiß gar nicht wie man überhaupt auf die Idee kommt den Entwickler jetzt auch Sysadmin Aufgaben machen zu lassen und den Sysadmin Entwickler Aufgaben zu kommen zu lassen. Was hat das mit DevOps zu tun? Jetzt daraus aber ein Schuh draus zu machen, dass DevOps nicht funktioniert, ist sicherlich falsch. Denn Scrum wurde anfangs auch falsch genutzt und oft dafür missbraucht, um Zielsetzungen und Meilensteine schlampig oder gar nicht zu definieren und zu planen, denn man ist ja "agil". Die Retourkutsche kam dann natürlich mit vielen gescheiterten Projekten.

Was viele grundsätzlich schon nicht verstanden haben ist, dass beispielsweise DevOps Engineer eine Spezialisten Position ist wie etwa ein Projektmanager oder ein Analyst. Wenn ich an mein Ex-Unternehmen zurückdenke, war DevOps im Karrieremodel ein eigener Pfad der zusätzlich (!) neben der Entwicklung, Analyse, Qualitätssicherung und Systemadministration existiert hat. Die Leute haben in einem sehr speziellen abgegrenzten interdisziplinären Bereich gearbeitet, nämlich in der Entwicklung einer Continuous Delivery Build-Pipeline in der die Software Module von 27 Teams praktisch im Minuten-Takt integriert und getestet und in einen Auslieferungsfähigen Stand versioniert wurden. Die Leute haben hier nicht nur die Systeme gebaut, die dafür spezielle Konfigurationen benötigen, sondern vor allem die gesamte Logik-Schicht über die Hybrid-Cloud Grenzen gebaut, da unsere Software ständig installiert und konfiguriert werden musste und dafür haben die Jungs natürlich auch Kenntnisse in der Sysadministration gebraucht, um beispielsweise Cluster-Installationen oder das Konfigurationsmanagement für unsere eigene Software zu implementieren, ständig anzupassen (!) und zu testen - die in großen Teilen auch Auslieferungsrelevant gewesen sind. Ein Entwickler oder Systemadministrator hat gar nicht die Zeit, um sich in die dafür benötigten Tool Konstellationen einzuarbeiten neben dem Tagesgeschäft, was er zu bewältigen hat. Deshalb braucht man dafür Spezialisten.  Das hat wunderbar funktioniert und mir ist keine große U.S. Firma bekannt bzw. eine Menge an Firmen, wo DevOps gescheitert wäre. Man braucht ab einer gewissen Größe einfach diese Leute die interdisziplinär arbeiten, damit man solche Prozesse überhaupt umsetzen kann. Das der Deutsche Mittelstand daran scheitert, wundert mich ehrlich gesagt nicht, die meisten haben ja noch nicht mal eine funktionierende und professionelle Qualitätssicherung die automatisiert die Software testen kann. Für viele ist QS schon wenn Entwickler regelmäßig Unit-Tests schreiben.

Kurzum, man braucht das richtige Umfeld für DevOps Spezialisten. Warum das Thema überhaupt "gehyped" wurde war mir sowieso noch nie wirklich verständlich. Das ist genauso deplatziert als würde man Spezialisten Positionen wie den Projektmanager oder den Analysten hypen. Ab einer gewissen Größe und Komplexität, braucht man einfach Spezialisten in diesem Bereichen. In kleineren Teams werden die Aufgaben einfach aufgeteilt, wo es Sinn macht. So hat man beispielsweise in einer 5-Mann Klitsche nicht unbedingt einen zusätzlichen Analysten. Requirement Engineer und Prozessmanager. Was hingegen keinen Sinn macht, ist die Spezialisten-Positionen eines Entwicklers und Systemadministrators zu vermischen und hoffen dass durch die Auflösung bestehender Strukturen irgendwelche grundlegenden Wettbewerbs-Probleme gelöst würden. Das ist Unsinn. Spezialisten Positionen im DevOps Umfeld existieren immer zusätzlich neben den Anderen Positionen. Und damit man die Arbeit überhaupt sinnvoll beginnen kann, muss das Unternehmen schon eine gewisse evolutionäre Stufe erreicht haben, beispielsweise eine funktionierende Qualitätssicherung die ihren Namen auch verdient hat.

Verständlich das die meisten hier gefrustet sind wenn sie bei Firmen arbeiten, die einfach keine Ahnung haben und durch Experimente die Belegschaft aufwühlen. Wahrscheinlich ist es sogar sehr gut wenn der "Hype" endlich aufhört und DevOps zu dem werden kann, was es ist - eine Spezalisten Position in einem klar abgrenzbaren Aufgabengebiet.

Bearbeitet 23. Juni 2018 von Arvi

[Fauch]

Das ist doch überall das Gleiche, ob man jetzt von DevOps oder Agil oder Sonstwas spricht.

Beispiel:

In meinem Ausbildungsbetrieb, in dem es praktisch keinerlei Strukturen gab, sämtliche Aufträge rein mündlich kommuniziert wurden und sich die Anforderungen ungefähr zweimal am Tag änderten, wurde Scrum eingeführt.

Nur leider interessierten sich die Verantwortlichen aus GF und oberem Management überhaupt nicht für Scrum, Sprints, etc. sondern wollten lieber beim Arbeiten auf Zuruf bleiben, teils auch, um eigene Fehler besser vertuschen zu können.

Dementsprechend hat Scrum bei uns überhaupt nichts gebracht. Zumal die Entwickler meist auch gleichzeitig Scrum-Master waren und die Teams aus ein oder maximal zwei Leuten bestanden.

So, oder so ähnlich kenne ich das auch aus einigen anderen Betrieben. Daraus ableiten zu wollen, das Scrum nichts taugt...fragwürdig. Gleich ist es mit DevOps. Meist passen die Strukturen nicht.

[pantsoff]

@Arvi - Du siehst DevOps schon stark in einer Position, man muss halt den Bullshit-Bingo-Faktor berücksichtigen.

Für manche ist es eine Philosophie, die gewisse Ziele verfolgt.

Man will von den klassischen Problemen weg, dass die Entwicklung ein Produkt fertigt, dass von einer operativen Abteilung betrieben wird. Kommt es zu Problemen, geht die Schuldzuweisung los. Die Reibung unter Betreibern und Herstellern des Produkts ist naturgemäß groß. Devops kann durch Neustrukturierung von Teams und Methoden dafür sorgen, dass jeder für seine eigenen Produkte komplett veranwortlich ist (Motto: Wir haben es entwickelt, wir betreiben es auch, entsprechend groß ist unser Qualitätsanspruch, da wir die Konsequenzen im operativen Betrieb ausbaden).

Eine weiterer DevOps Aspekt ist der Tatsache geschuldet, dass wir eine Cloud-Shift haben.

Kenntnisse von Sysadmins spielen in der Cloud keine Rolle (SAN, Netzwerk, Server, Hardware, Cluster etc. nimmt die Cloud an vielen Stellen ab).

Stattdessen brauchen wir Automatisierer: 

"Infrastructure-as-Code" - Wir brauchen keine "Betreiber" mehr, das machen ebenfalls alles Entwickler, wir brauchen in Zukunft nur noch Entwickler (NoOps) / Automatisierer.

 

Ich schreibe das aus neutraler Sicht und möchte damit nur sagen, DevOps muss nicht in einer Position verankert sein.

[Gast Arvi]

vor 18 Minuten schrieb pantsoff:

@Arvi Ich schreibe das aus neutraler Sicht und möchte damit nur sagen, DevOps muss nicht in einer Position verankert sein.

Das ist richtig, aber wenn du sagst wir brauchen "Automatisierer" ist auch das letztendlich eine Spezalisten Position, denn um etwas zu automatisieren brauchst du letztendlich Kentnisse der Tools, der Programmierung, als auch die Kentnisse in der Fachlichkeit. Jemand der Vorgänge nicht versteht, kann diese auch  nicht automatisieren. Also sind wir letztendlich in einem Interdiszipläneren Teilbereich der sich halt je nach Firma unterscheiden kann. In einer Softwarefirma wie bei uns kann dieser Teilbereich in  meinem oben skizzierten Szenario liegen. In einem Rechenzentrum liegt der Schwerpunkt in der Fachlichkeit die für die Automatisierung notwendig ist woanders.

Das man  in der Cloud keine klassichen Sysadministratoren braucht, sehe ich btw. grundsätzlich anders. Der genannte "Automatisierer" macht letztendlich Deployment Automatisierung. Sind die Systeme aber ausgerollt, dann muss sich darum auch jemand kümmern insbesondere was das (Performance-) Monitoring, Wartung, Fehleranalyse, usw. angeht.  Das kann (und wird) ein Entwickler ("NoOp") nie vollständig beherrschen können denn das verlässt absolut seinen Kompetenzbereich. Es gibt sogar viele Bereiche (egal ob On-Premis oder in der (Hybrid)-Cloud), da macht Automatisierung überhaupt keinen Sinn, nämlich immer dann, wenn es im Geschäftsmodell keine nennenswerten Skaleneffekte gibt. Ein Cluster-Modell das ich nur 1x im Jahr baue und ausrolle, brauch ich nicht automatisieren. Und oft ist es ja so, dass ich in Clouds zwar automatisiert einen Cluster ausrollen kann, z. B. einen  Nginx Web-Cluster, aber letztendlich ist das für viele moderne Applikationen nur ein geringer Teil des geclusterten Technologie-Stacks. Auch hier brauche ich wieder Systemadministratoren, die das Zeug aufbauen und administrieren können. Dafür brauche ich weder einen Entwickler, noch einen Automatisierer, der mir einem 1x im Jahr auftretenden Geschäftsfall automatisiert und diesen ständig mit den neuen Versionen auch aktuell hält, damit ich in dann in einem Jahr auch wieder benutzen kann -> ist Unsinn und in der Praxis nicht Realität.

Bearbeitet 23. Juni 2018 von Arvi

[pantsoff]

vor 32 Minuten schrieb Arvi:

Das ist richtig, aber wenn du sagst wir brauchen "Automatisierer" ist auch das letztendlich eine Spezalisten Position, denn um etwas zu automatisieren brauchst du letztendlich Kentnisse der Tools, der Programmierung, als auch die Kentnisse in der Fachlichkeit. Jemand der Vorgänge nicht versteht, kann diese auch  nicht automatisieren. Also sind wir letztendlich in einem Interdiszipläneren Teilbereich der sich halt je nach Firma unterscheiden kann. In einer Softwarefirma wie bei uns kann dieser Teilbereich in  meinem oben skizzierten Szenario liegen. In einem Rechenzentrum liegt der Schwerpunkt in der Fachlichkeit die für die Automatisierung notwendig ist woanders.

Der Entwickler des Produkts kennt doch die Toolchain für das eigene Produkt am besten. Da ihm die Cloud viel Komplexität abnimmt, kann er sich die Toolchain, die für die Cloud Infrastruktur notwendig ist, leichter aneignen. Er wird damit am ehesten geeignet, alle Aufgaben zu übernehmen. Vielleicht haben wir bald nur noch DevOpsler?

vor 35 Minuten schrieb Arvi:

Das man  in der Cloud keine klassichen Sysadministratoren braucht, sehe ich btw. grundsätzlich anders. Der genannte "Automatisierer" macht letztendlich Deployment Automatisierung. Sind die Systeme aber ausgerollt, dann muss sich darum auch jemand kümmern insbesondere was das (Performance-) Monitoring, Wartung, Fehleranalyse, usw. angeht.  Das kann (und wird) ein Entwickler ("NoOp") nie vollständig beherrschen können denn das verlässt absolut seinen Kompetenzbereich. Es gibt sogar viele Bereiche (egal ob On-Premis oder in der (Hybrid)-Cloud), da macht Automatisierung überhaupt keinen Sinn, nämlich immer dann, wenn es im Geschäftsmodell keine nennenswerten Skaleneffekte gibt. Ein Cluster-Modell das ich nur 1x im Jahr baue und ausrolle, brauch ich nicht automatisieren. Und oft ist es ja so, dass ich in Clouds zwar automatisiert einen Cluster ausrollen kann, z. B. einen  Nginx Web-Cluster, aber letztendlich ist das für viele moderne Applikationen nur ein geringer Teil des geclusterten Technologie-Stacks. Auch hier brauche ich wieder Systemadministratoren, die das Zeug aufbauen und administrieren können. Dafür brauche ich weder einen Entwickler, noch einen Automatisierer, der mir einem 1x im Jahr auftretenden Geschäftsfall automatisiert und diesen ständig mit den neuen Versionen auch aktuell hält, damit ich in dann in einem Jahr auch wieder benutzen kann -> ist Unsinn und in der Praxis nicht Realität. 

Okay, verschiedene Punkte.

Ja man muss nicht alles automatisieren, aber wieso nicht? Wenn ich den Cluster nur einmal im Jahr brauche, habe ich das Infrastructure-as-Code Snippet trotzdem noch zur Hand, denn damit stelle ich "Reproduzierbarkeit" sicher. Ein wichtiger Faktor für Q&A / CI / CD und Testin . Automatisierung schafft in gewisser Weise "Dokumentation" und "Gleichheit" und damit Reproduzierbarkeit. Nimm jetzt bitte nicht das Wort "Dokumentation" auseinander, ich denke du verstehst, wie es in dem Kontext gemeint ist :).

Ich finde nach wie vor keine guten Gründe in deiner Argumenation, wieso ich dediziertes Sysadmin Personal brauche.

Updates -> Macht der Cloudprovider (wenn ich es will)

Security -> Macht der Cloudprovider (für alles, was nicht mit meinem eigenen Code/Konfigs. zu tun hat)

Monitoring -> Bietet der Cloudprovider as a service

nginx Cluster -> Bietet der Cloudprovider as a service

DBCluster -> ....

Ja ich bin bewusst etwas überspitzt, die Grundaussage aber bleibt:

Der Cloudprovider nimmt so viel Komplexität und bietet mir viele "Services", um die sich sonst ein Sysadmin kümmern würde.

Nochmal, mein Standpunkt basiert auf Argumenten, die immer wieder in der Diskussion fallen.

Diese Diskussion möchte ich hier führen.

Meinen eigenen Standpunkt (oder meine Meinung dazu) habe ich noch gar nicht kundgetan.

Ich vertrete jetzt erstmal die Sicht, dass der Entwickler alles selbst kann (und dafür sogar am besten geeignet ist).

[Gast Arvi]

vor einer Stunde schrieb pantsoff:

Ja man muss nicht alles automatisieren, aber wieso nicht? Wenn ich den Cluster nur einmal im Jahr brauche, habe ich das Infrastructure-as-Code Snippet trotzdem noch zur Hand, denn damit stelle ich "Reproduzierbarkeit" sicher. Ein wichtiger Faktor für Q&A / CI / CD und Testin . Automatisierung schafft in gewisser Weise "Dokumentation" und "Gleichheit" und damit Reproduzierbarkeit.

Du hast wahrscheinlich noch keine komplexen Automatisationsprozesse langfristig betreut. Mal angenommen du musst 1x im Jahr eine geclusterte ERP Umgebung in einer neuen Version zur Verfügung stellen. Dein Automatismus den du für einen definierten Stand erstellt hast wird in einem Jahr bei der neuen Umgebung zu einer sehr hohen Wahrscheinlichkeit nicht mehr funktionieren, weil sich durch neue Betriebssystemstände, die neue ERP Software-Version, neue DB Version, oder oder oder ... Abhängigkeiten, Installationsparameter und sich die fachlichen Konfigurationen insbesondere in der ERP Software geändert haben. Das heißt letztendlich das du deinen Automatismus wieder komplett anpassen und stagen musst. Bis der Rollout mal Bullet Proof läuft, hat der Administrator schon 20 solcher ERP Umgebungen installiert und konfiguriert. Es lohnt sich schlicht nicht, einen Automatisierungsprozess zu pflegen, den man nicht benutzt. Sprich reproduziert das du ja als Vorteil angeführt hast. Die Vorteile der Automatisierung und insbesondere die Wirtschaftlichkeit rechnen sich nur, wenn auch die Notwendigkeit des ständigen Rollouts besteht. Denn letztendlich erreiche ich nur durch die Häufigkeit der Nutzung die Gewünschten Degressionseffekte. Die Erstellung und Pflege des Automatismus ist immer teurer als der einmalige manuelle Aufbau. Ich habe schon für große Softwarehersteller in diesen Bereichen gearbeitet und letztendlich heißt Prozesspflege im Deployment, dass du quasi einmal täglich Referenzumgebungen bauen lässt (die halt in der Cloud wegen der CPU Nutzung auch Geld kosten!), um die Reproduzierbarkeit zu gewährleisten. Jeder Patch (OS, DB, Software, etc., jede Version einer Schnittstelle zu einer anderen Software / REST API die aktualisierte wurde, etc. etc. etc.) muss getestet werden damit der Automatismus produktiv genutzt werden kann. Wenn du eine handvoll komplexe Automatismen betreust, dann ist das ein ganzjahres Vollzeit-Job. Deshalb:

vor einer Stunde schrieb pantsoff:

Ich vertrete jetzt erstmal die Sicht, dass der Entwickler alles selbst kann (und dafür sogar am besten geeignet ist). 

Ja natürlich KÖNNTE er das. Genauso wie er sich um das Projektmanagement der Software, die gesamte Softwarearchitektur, die Qualitätssicherung, die Kundenberatung, den Support und sich um alles Andere kümmern könnte. Es ist aber wirtschaftlich und organisatorisch ab einer gewissen Größe oft nicht sinnvoll den Entwickler von seinem eigentlich Aufgabenfeld - der Entwicklung der Software - abzuziehen. Denn letztendlich führt die Erweiterung seines Aufgabenbietes dazu, dass sich auch die Kapazität seiner Arbeitszeit auf die Aufgaben aufteilt. Einen Entwickler stelle ich ein, damit er Software entwickelt, und nicht den Jenkins administriert und Puppet-Provider schreibt. Punkt. Das ist viel zu teuer und organisatorischer Nonsense.

vor einer Stunde schrieb pantsoff:

Updates -> Macht der Cloudprovider (wenn ich es will)

Security -> Macht der Cloudprovider (für alles, was nicht mit meinem eigenen Code/Konfigs. zu tun hat)

Monitoring -> Bietet der Cloudprovider as a Service

Beim IaaS Modell muss sich der Administrator um fast alle diese Sachen kümmern.  Infrastruktur Monitoring macht zwar der Cloud Provider, weil das sein Service ist, aber glaubst du das Amazon oder Microsoft das Monitoring irgendwelcher Worklows in ERP-Systemen oder Streaming Angeboten übernimmt die ich als Kunde in meiner IaaS Umgebung installiere? Natürlich nicht !

Natürlich können durch die Cloud neue Geschätsmodelle abgebildet werden. Das heißt aber noch lange nicht, dass die Systemadministratoren deswegen nicht mehr gebraucht werden. Ganz im Gegenteil. Das Aufgabengebiet der Sysadmins hat sich hingegen sogar noch erweitert weil neben den typischen Fähigkeiten nun auch Administrations Kenntnisse  von Amazon AWS / Azure gefragt sind. Wenn die Cloud das alles selber könnte, dann gäbe es ja schon heute keine Admins mehr, die sich um die Infrastruktur in der Cloud kümmern.

Bearbeitet 23. Juni 2018 von Arvi

[pantsoff]

Natürlich spielen Release Zyklen eine Rolle.

Aber, dein Beispiel vorausgesetzt, niemand installiert 20mal ein ERP inkl. individueller Konfiguration.

Da muss sehr wohl Automatismus her.

Ich sehe jetzt nicht wieso ein Deployment Prozess aufwendiger ist, als 20 mal das Ding rauf und runter zu installieren - okay, beides kann sein, das kann man wohl nicht allgemein gültig sagen und hängt vom Einzelfall ab. Es gibt heute Technologien, die das OS und vieles drum herum von der Applikation entkoppeln.

Aber:

Mal abgesehen davon, dass ich beim manuellen Deployment jedesmal menschliches Versagen als Fehlerquelle berücksichtigen muss.

Außerdem:

Genau der eine Mensch kann dann das ERP rauf und runter konfigurieren.

Und wenn der krank ist, im Urlaub, ausgeschieden aus dem Unternehmen?

Im Idealfall gibt es eine Deployment Pipeline, die jeder aus dem Team mit kurzer Anleitung ausführen kann (ich sage bewusst Deployment Pipeline und nicht Delivery Pipeline, beschränken wir das ganze auf sagen wir das Deployment einer VM und anschließender ERP Installation / Konfiguration inkl. der Anlage aller benötigter Komponenten).

Natürlich kann der Automatismus mehr Zeit kosten, dagegen halte ich nach wie vor das Argument der "Reproduzierkarbeit" (und ein bißchen "Dokumentation", bewusst in Anführungszeichen).

Da muss halt jede Firma für sich entscheiden, wo die Prios sind.

"Automation first" ist mein Ansatz.

 

Ich lasse Dir hier aber deine Meinung und gebe Dir in Einzelfällen recht, da kann der Automation-first Gedanke "teurer" sein (trotzdem sinnvoll aus meiner Sicht).

Naja, temporäre Ressourcen in der Cloud sind bei den meisten Anbietern ein Witz, teuer sind Produktivumgebungen (lange Laufzeiten, viel Traffic ingress/egress etc.).

Deine Schlussfolgerung ist dann also:

Sysadmins sind für die Systeme da, die aufgrund wirtschaftlicher Aspekte nicht automatisiert werden können?

Puh, das ist ja mal harter Stoff, ich kenne sehr viele super fitte (Programmier und Scripting-fähige Sysadmins -> sind das jetzt eigentlich  auch DevOps? :)). Jemand aus der Sysadmin Franktion hier, der etwas dazu sagen möchte?

 

Beim nächsten Punkt hast du mich nicht verstanden.

Jeder im Unternehmen KÖNNTE (also rein von der Sache her) alles. Darum geht es doch aber nicht. Es geht darum, wer ist wofür am besten geeignet. Ist der Entwickler in Zeiten von Cloud und Co. am besten geeignet, seine Infrastruktur Ressourcen selbst zu administrieren?

 

Es gibt viele Entwickler/Sysadmins die aus meiner Sicht NICHT geeignet sind, Projektmanager oder Berater zu sein (es gibt natürlich alle Fälle) und genauso den umgekehrten Fall (vom Potential).

 

Letzer Punkt, Beispiel Monitoring im ERP System:

Natürlich bietet das AWS und Co. nicht an, aber der Entwickler weiß doch am allerbesten, wann ein Alarm schießen soll, sobald dieser und jener Wert in der Datenbank steht? Woher soll der Sysadmin wissen, dass beim Parsen eines Logfiles genau diese Zeile gemeldet werden muss? Natürzlich muss der Monitoring Service des Providers mit Inhalt gefüttert werden (Tritt Fall A ein passiert Aktion B), aber der Monitoring Service des Providers ist bereits fertig im Portfolio, ist hochverfügbar geclustert und skaliert mit zunehmender Workload automatisch mit. Vielleicht ist der Entwickler besser dafür geeignet, das fertige Monitoring System mit Inhalt zu füttern, da er seine Applikation besser kennt als der Admin.

[Gast Arvi]

Irgendwie hast du die Quintessenz nicht verstanden, also noch mal:

1. Die Automatisierung macht nur dort Sinn, wo durch die Automatisierung auch eine Fixkostendegression stattfindet. Man automatisiert nicht "weil man es kann" oder weil es die Transparenz fördert (das ist ein zu begrüßender Nebeneffekt), sondern dort wo es wirtschaftlich Sinn macht. Die fehlende Transparenz kann zu einem wirtschaftlichen Faktor werden, muss es aber nicht. Zumal die Transparenz dort endet, wo der Automatismus endet. Und dann? Soll der Entwickler jetzt auch noch das Konfigurationsmanagement administrieren und betreuen?  Wenn ich einen Automatismus nur 1x im Jahr ausführe, dann ist die Pflege und die Qualitätssicherung des Prozesses teurer als der eigentliche Vorgang.

2. Die Pflege komplexer Prozesse ist ein eigener Vollzeitjob. Deshalb macht das ab einer gewissen Komplexität eben nicht mehr der Entwickler oder der Sysadmin, sondern ein Spezalist. Wie man den jetzt benennt ("DevOps Architect/Engineer" whateever) ist zweitrangig. Für mich ist eine VM klonen und ein Setup ausführen kein komplexer Prozess. Das kann ein Praktikant nach einem Tag Einarbeitung runterskripten.

3. Die Annahme das der Entwickler "seine Software" am besten kennt, ist halt bezeichnend für das Problem deiner Argumentation. Wenn der Entwickler seine Software am besten kennt, dann mag das vielleicht in einer 5 Mann Klitsche zutreffen, aber nicht in einem Unternehmen was komplexe Enterprise Software entwickelt und wo die Arbeit eines Entwicklers nur ein kleines Zahnrädchen eines großen Gebildes ist. In meiner Ex Firma haben 350 Entwickler an einer Software mit 80 Modulen gearbeitet. Nur um die Dimension kurz zu erläutern: Die Software enthielt über 30.000 Unit Tests. Von komplexen Geschäftsprozess-Tests will ich gar nicht reden. Welcher Entwickler soll da neben seinen Hauptjob noch irgendwelche Deployments automatisieren? Dafür müsste er sich erstmal in die gesamte Software Domäne einarbeiten. Das macht wirtschaftlich keinen Sinn.

4. Um gottes Willen jeder Entwickler soll seine Cloud-Ressourcen selber administrieren? Das ist das Anfänger Problem jeder Software Bude die größer wird. "Wie das funktioniert im Integrationstest nicht? Auf meiner Entwickler VM hat es immer funktioniert!!". Nein Entwickler sollen sich selber keine Entwickler Maschinen/Docker Container bauen. Die sollen Aufgrund der Transparenz von einer zentralen Instanz zur Verfügung gestellt werden. Entweder dem Systemadministrator oder einem DevOp der die irgendwo herauspurzeln lässt.

So sieht die Realität aus, wo große Firmen, beispielsweise die mit drei Buchstaben oder die mit dem großen A DevOps zur Automatisierung einsetzen - die auch genau das tun, und nicht am Hauptprodukt entwickeln.

Du siehst es anders? Gut dann siehst du es anders.

 

Bearbeitet 23. Juni 2018 von Arvi

[pantsoff]

Deine Ex Firma ist halt nicht der Nabel der Welt

https://aws.amazon.com/devops/what-is-devops/

 

[Gast Arvi]

vor einer Stunde schrieb pantsoff:

Deine Ex Firma ist halt nicht der Nabel der Welt

https://aws.amazon.com/devops/what-is-devops/

 

Amazon ist der Nabel der Welt? Gut das du das so siehst, denn die meinte ich mit der Firma mit dem großen A  ! Zum einen bestätigt die Seite doch gerade welche Spezalisten Positionen DevOps bekleiden, zum Anderen steht dort explizit nicht, dass Entwickler nun alles machen, sondern dass die Teams zusammengeführt werden und so besser und enger zusammen arbeiten. Das ist überhaupt kein Widerspruch zu dem was ich sage, denn es ist oft so, dass in einem Projekt-Team verschiedene Spezalisten zusammen arbeiten. Beispielsweise der Analyst, der aber im Gegensatz zu den Entwicklern alleine für Prozess-Analyse und BPMN Modellierung verantwortlich ist sowie für Requirement Engineering. Das wird auch nicht auf alle umgelegt sondern statt die Teams organisatorisch voneinander zu separieren werden diese als Team projektbasiert zusammengeführt, woraus nicht folgt, dass jeder nun alles macht! Es ist eben genau nicht was du sagst: Die Entwkckler machen jetzt alle DevOps so "nebenher". Das ist einfach falsch. Sollen wir uns mal zwei Stellen von Amazon in dem Bereich angucken? Willkürliche auswahl:

Spezalisten Stelle im Alexa Projektteam: https://www.amazon.jobs/en/jobs/636357/devops-engineer
Der DevOp Engineer arbeitet mit im Alexa Team, entlastet aber durch seine Aufgaben das Kern-Projektteam (Build-Pipeline, Automatisierung, Tool Entwicklung, Optimierung etc. ) was nach deiner Ansicht ja auf alle Entwickler umgelegt werden sollte laut DevOps -> ist nicht der Fall. Er arbeitet nicht an Alexa. Auch administriert er keine allgemeinen Server Systeme von Amazon. Er macht genau das, was oben in deiner Seite steht: Er begleitet die Alexa Produktentwicklung bis zur Auslieferung und unterstützt das Team an der Front durch seine Spezalisten-Aufgaben.

Spezalisten Stelle im Bereich Webservices: https://www.glassdoor.de/job-listing/devops-support-engineer-amazon-web-services-amazon-JV_IC1139977_KO0,43_KE44,50.htm?jl=2444431153&ctt=1529825076593

Der DevOp Engineer kümmert sich rein um Automatisierungsaspekte im Bereich AWS. Er betreut weder die allgemeinen Server Systeme noch arbeitet er an der Produktseite. Auch eine absolute Spezalisten Position um komplexe Deployments zu automatisieren. Nichts anderes.

Wie gesagt, dort wo DevOps erfolgreich etabliert ist, handelt es sich um klar abgrenzbare Spezalisten Positionen die neben den Systemadministratoren / Systemengineers und Software Entwicklern co-existieren. Diese "Vermischung" die du mit DevOps verbindest, jeder ist jetzt für alle diese Sachen verantwortlich und eigentlich braucht man keine Sysadmins mehr, hat nichts mit DevOps zu tun. Schau dir die Stellenbörse von Amazon an und die Verteilung der Stellen an. Dort siehst du schwarz auf weiss, wie DevOps als Spezalisten Positionen sich ins Gesamtbebild einfügen. Dort kannst du auch nachlesen, was die DevOps tun. Es ist immer eines der Aufgabenbereiche aus deiner zitierten Definitionsseite - also eben eine Spezalisten Position und kein Softwareentwickler der das "nebenher" macht weil er angeblich das Produkt so gut kennt.

Bearbeitet 24. Juni 2018 von Arvi