DevOps - alles

[Dieses Material ist eine Übersetzung einer Reihe von Tweets von Michael DeKhan, einem der Schöpfer der beliebten Ansible-Automatisierungs-Engine . ]

Opsmop hat also das gleiche Problem mit dem Zeitplan für Akzeptanz und Beteiligung wie vespene_io , und ich sehe auch keinen Grund, fortzufahren. Ich glaube hartnäckig an die Idee selbst, aber ich denke, dass die ganze Welt der Open Source-IT ausgebrannt ist, und ich bin es leid zu versuchen, Menschen zu interessieren.

Für diejenigen, die sagen, dass dies ein Produkt war, das nicht auf den Markt kam, oder dass ich etwas länger warten sollte - bei allem Respekt liegen Sie falsch. Ich kenne dieses Gebiet viel besser als jeder andere außer fünf Menschen auf der Welt :-) Die Gründe dafür sind interessant ...

Im Wesentlichen bedeutet (1) ein agiles Diagramm, dass niemand Zeit zum Arbeiten hat. (2) DevOps konnte nicht wie beabsichtigt funktionieren. Sowohl das als auch das brauchten Zeit für eine allmähliche Manifestation und verursachten Schaden. Ehrlich gesagt, ungefähr 12 Jahre alt.

DevOps [-Ansatz - ca. ] hätte wie eine Mischung aus Entwicklung und Verwaltung werden sollen [Entwicklung / Betrieb - ca. Übersetzung], aber stattdessen stellen die Leute alltägliche Tools her, und Entwickler tun viel, was Administratoren gewohnt sind. Und Administratoren werden * noch mehr * Systemadministratoren als zumindest in der Mitte dieses Zeitraums [mit 12 Jahren - ca. übersetzt].

Der Schlüssel zum Erfolg von Open Source liegt darin, dass sich das Publikum von Benutzern und Entwicklern (diejenigen, die einen Beitrag leisten können) stark überschneidet und auch involviert und inspiriert ist.

In unserem Fall deuten viele Diskussionen darauf hin, dass jeder beschäftigt ist, niemand Zeit hat und dennoch ... jeder mehr und mehr an Lösungen wie „wenig Code / kein Code“ interessiert ist. Dies gilt nicht für Open Source im Allgemeinen, sondern nur für das IT-Verwaltungssegment.

Rückblickend auf Lizenzdiskussionen (Mongo, Redis, Confluent) - sie hatten Recht und verteidigten sich gegen „trübe“ Missbräuche, aber dies sagt noch etwas anderes aus: Um dies zu tun, mussten sie sich einem abnehmenden Wert bei der Interaktion mit der Community stellen.

Zwar sind nicht alle vorgeschlagenen Verbesserungen immer gut, aber die Interaktion und Erfahrung mit Menschen ist sehr positiv. Aber sie scheinen überall langsamer zu werden . Sie würden wahrscheinlich denken, wenn jemand eines dieser Stücke auf GitHub geschrieben hat, das die meisten Verbesserungswünsche erhält, würden die Leute gerne seine neuen Stücke ausprobieren und Ideen austauschen, aber in meinem Forum gibt es nur 60 Teilnehmer und Nur 10 von ihnen kamen letzte Woche herein. Jedes Projekt wird nur zweimal am Tag und dann höchstwahrscheinlich automatisch geklont.

Ich sehe starke Bewegungen in anderen Bereichen, wie dem JavaScript-Ökosystem. Ich bin sehr begeistert von Open Source und dem Austausch von Ideen. Ich habe viel mit Leuten gesprochen, die ernsthafte Probleme mit dem Konfigurationsmanagement haben. Aber am Ende schlägt die Interaktion fehl.

Open Source-Programme fördern die Interaktion. Und im Grunde ist hier meine Diagnose - Burnout in großem Maßstab. Es kam langsam und wir haben es nicht bemerkt. Agile und DevOps - Burnout. Meiner Meinung nach sind wir in einigen Bereichen technologisch ärmer als vor sechs Jahren. Warum?

Wir sind müde und lassen einfach alles los, wie es geht. Wir verwenden das gleiche wie andere. Wir werfen ohne Grund Wolken auf unsere verdammten Wolken und interessieren uns viel mehr für technische Mode als für das, was uns produktiv macht. Wir ertragen Software mit Tausenden von Fehlern.

Grundsätzlich lassen wir unsere Manager-Software zum Witz werden. Anstatt auf der Beherrschung des Weltraumraketen-Levels zu bestehen, schrauben wir einfach noch mehr Schichten darüber. Und niemand hat die Kraft, nein zu sagen. IT-Software ist zu weit von einem Anschein von Engineering entfernt.

Ich möchte helfen, dies zu bekämpfen, aber am Ende sind Engagement und Brainstorming mein Treibstoff. Wenn es keine Beteiligung gibt und ich diese Beteiligung nicht beheben kann, werde ich nichts davon bekommen. Ich stellte mich also als der Kanarienvogel heraus - mehr oder weniger.

Ich schreibe immer noch gerne Software, aber ich werde versuchen, Projekte zu erstellen, die für mich persönlich interessant sind, und der Unterstützung der Führung deutlich den Rücken kehren. Das bedeutet Sachen wie mein Projekt für einen Musiksequenzer. Weil ich glaube, dass die Leute sich nicht um ein Hobby kümmern ...

Ich hoffe, dass hier Engagement in großer Zahl zum Ausdruck kommt. Wenn nicht, können Sie es trotzdem verwenden, um coole Songs abzulegen. Vielleicht werde ich mich mit einigen interessanten Dingen der Datenanalyse befassen, weil sie mich auch interessieren.

Wie können wir Open Source für die IT im Allgemeinen und im Allgemeinen beheben? Schauen Sie sich an, wer DevOps sein sollte ... er sollte genauso ein Entwickler sein, genauso ein Administrator. Bekämpfe die Agilität, die deinen Zeitplan verschlingt. Probieren Sie neue Dinge aus, überlegen Sie sich, lernen Sie Optionen und versuchen Sie nicht, jemand anderes zu sein.

Blockieren Sie Twitter "Entwickleranwälte". Wir lieben es, über Repräsentation zu sprechen, aber denken Sie darüber nach, was Technologie bedeuten kann, „lokal zu kaufen“. Unterstützung kleiner Projekte und ISVs [unabhängige Softwareanbieter - ca. ]. Interagiere. Die meisten von uns ernähren sich mehr als alles andere von Interaktion.

Die Zukunft, in der wir einfach Software konsumieren, die von einer der vier Marken veröffentlicht wurde, erscheint mir ziemlich langweilig, insbesondere wenn es in dieser Zukunft nicht genug Code gibt. Um diese Vereinigung zu überleben, brauchen wir Vielfalt. Und um zu ihm zu kommen, müssen wir die Verknöcherung von Praktiken ablehnen.

Wir machen nur sehr wenige Dinge auf die beste Art und Weise, im Grunde genommen so, wie es jeder tut. Die meiste Software, die jeder benutzen möchte, ist Mist. Nun, was ist der Haken, wirklich? Gib die Mittelmäßigkeit auf und tue, was du für richtig hältst.

In Bezug auf Depressionen / Burnout - achten Sie auf Ihre Fähigkeiten. Genieße die Aufführung. Erstellen Sie kugelsichere Gegenstände. Teilen Sie geschriebene Skripte. Bloggen. Alles. Kommunizieren und teilen Sie noch mehr. Vielleicht können wir das nach und nach ändern.

Aber wenn das Gespräch das nächste Mal zu einem Paradigmenwechsel wie "agil" oder "devops" kommt, der von jemandem gestartet wurde, der nichts Bedeutendes geschrieben oder aufgebaut hat, sei höflich, aber lass dich nicht von der Tatsache täuschen, dass er versucht, dich zum Lachen zu bringen.

Wir sollten die technische Arbeit schätzen - was wir schaffen, spezielle, relevante Dinge, keine beschissenen Sprüche oder sich wiederholenden Mantras über Prozesse. Die ersten sind ein Indikator für unseren Wert und wie stark wir uns verbessern.

Wir haben die Bewegungen gemacht, die uns das angetan haben, und wir tun es immer noch. Akzeptanz der Ossifikation [Praktiker - ca. ] und spucken auf die Qualität der Software, die wir alle unterstützen, müssen einfach aufhören. IT ist Engineering, also behandeln Sie sie entsprechend.

Wenn mir das schwer fällt, stellen Sie sich vor, wie es für jemanden ohne Plattform ist. Für mich war OSS eine großartige Möglichkeit, viele Menschen und viel Freude kennenzulernen, und ... wenn ich es heute nicht kann - oh ...

Alle Arten von cooler Hilfe in Bezug auf die OSS-Bewegung, die wir 2006 bei RedHat genossen haben, glaube ich heute einfach nicht. Die Bewegung war nicht falsch, nur etwas bewegte sich in der Kultur und tötete ihn.

Ich kann mir nicht helfen zu denken, dass es nicht daran lag, dass Red Hat nicht für die Distribution verkauft wurde, sondern (laut einer IBM-Ankündigung) für die Kubernetes- und OpenStack-Distributionen. Sind sie auch darauf gestoßen? Was denkt jedes große Unternehmen mit einem OSS-Projekt über Engagement, kann es aber nicht sagen?

Natürlich würden sie höchstwahrscheinlich etwas anderes sagen, aber ich frage mich, was sie denken. Und ich denke, dass sie alle denken, dass Freemium ein gutes Download-Modell ist, aber echter Code und Zusammenarbeit bedeuten nichts mehr, weil die Leute nicht involviert sind.

(an alle, die ein "Plus" dafür setzen, hmm ... danke?)