Ansible Tower im Meetup-Schnellcheck

Was hat ein Meetup zu Ansible Tower mit dem Weltuntergang zu tun? Nun, stellen wir uns folgende Situation vor: Berlin, wir schreiben den 29. Juni 2017. Es schüttet wie aus Eimern, seit Stunden. Berlin steht unter Wasser, die Feuerwehr ruft den Notstand aus.

Doch eine Handvoll verwegener Coder schlagen sich zum Meetup Ansible mit Ansible Tower in unserem Berliner Mayflower-Büro durch. Wir empfangen sie der Witterung entsprechend mit Glühwein.

Damit hätten wir die Ausgangssituation geklärt. Es folgt ein kurzer Bericht vom Main Act des Abends.

Weiterlesen

Geschafft … Erstes DevOps Meetup Würzburg!

Am Montag, den 07.11.2016 fand das erste DevOps Meetup Würzburg statt. Dafür standen die Räumlichkeiten der Informatik an der Uni-Würzburg zur Verfügung. Mit rund 40 Besuchern waren wir (Steffen Gebert, Sebastian Kremer und Andreas Rudat) mehr als zufrieden. Was uns besonders freute, war der Mix aus Erstsemester-Studenten, Angestellten bis hin zum Geschäftsführer. Weiterlesen

Berlin Ops Summit 2016 | Gute Organisations-Aufstellung in Zeiten digitaler Transformation

Björn Schotte wird am 8. September auf dem Berlin Ops Summit in Berlin sprechen.

Der Vortrag „Gute Organisations-Aufstellung in Zeiten digitaler Transformation“ wird das Buzzword „digitale Transformation“ im Kontext von Organisations-Strukturen näher beleuchten.

Organisationen, die vor dem Aufkommen des Internets bereits existierten, haben es häufig schwer, der neuen Konkurrenz Paroli zu bieten. Insbesondere sogenannten „Online Pure Playern“.

„Klar, wie müssen jetzt agil sein. Alles muss schneller werden. Die Büroräume so hip wie im Digital Valley.“, ist die häufige Antwort der Konzernlenker. Doch wir brauchen gar nicht weit in die Ferne schweifen.

Die gewachsene Struktur der Organisation ist dem zukünftigen Erfolg im Weg. Das Immunsystem wehrt sich.

Björn meint: das muss nicht sein. Wenn die Organisation erst einmal begreift, dass IT nicht mehr nur Unterstützung ist, sondern ein Kern-Anliegen. Und Abteilungen im Sinne des Produkts zusammen arbeiten. Mit IT-Crews, die einen „fit for purpose“ haben.

Der Weg wird steinig sein. Und schmerzhaft. Die Medizin gibt es am 8. September im Vortrag. Und wenn du magst, in ausführlichen Gesprächen auf der Abend-Party. Wer schon einmal das Gespräch suchen möchte, meldet sich am besten per E-Mail.

Wir sehen uns!

 

Noch ein VPN? vagrant up!

These: Aufsetzen von VPNs für ein ganzes Team ist Zeit- und Geldverschwendung!

Aber von vorne:

Wenn wir ein Projekt für einen neuen Kunden starten, steht für uns ganz am Anfang der Zugriff auf dessen Infrastruktur.

Viele Kundeninterna (Jira, Confluence, Sharepoint, SQL-Server, Dateifreigaben) liegen im Netz des Kunden, und wir brauchen erst mal ein VPN, um aufs Netz des Kunden zugreifen zu können.

Hier wird es bunt gemischt: Einige Kunden setzen auf IPsec, wieder andere auf OpenVPN, Tinc oder ein halbes Dutzend herstellerspezifische Lösungen. Weiterlesen

Können wir DevOps noch reparieren?

»Wer DevOps nur auf die Tools reduziert, vermeidet es, sich mit der eigenen Kultur auseinanderzusetzen. Und läuft so Gefahr, am eigentlichen Ziel vorbeizuschießen.«

Anmerkung: dieser Text fasst im Grunde genommen nur das zusammen, was wir in unserer täglichen Arbeit erleben. Im konkreten Fall haben wir diese Zusammenhänge bei zweien unserer Kundenteams beobachten können – Kudos daher an die Teams für ihre Insights.

Warnung: Dies hier ist nur eine erste Zusammenfassung eines in weiten Teilen sehr komplexen Themas. Gerade was das Mindset und die gelebte Kultur hinter dem Begriff DevOps angeht, ist es nicht damit getan, einzelne Punkte als Checkliste herauszuziehen. Trotzdem (oder vielleicht auch gerade daher) liefert der Text aber vielleicht erste Impulse, sich mit neuen Aspekten auseinanderzusetzen. En Détail möchte ich für den größeren Zusammenhang gerne Johanns Keynote „DevOps jenseits der Tools“ weiterempfehlen:

DevOps und die Ziele dahinter

Seit 2009 ist DevOps ein wichtiges Thema auf den IT-Konferenzen, und inzwischen empfehlen auch die großen Beratungshäuser eine DevOps-Strategie. Doch während sich die Tools hoher Popularität erfreuen und Quasi-Standard wurden, sind Kultur und Organisationsdesign auf der Strecke geblieben. Die Tools alleine realisieren nur einen kleinen Teil des Benefits von DevOps, der große Vorteil entsteht erst mit der Integration von DevOps-Struktur, Organisation und Kultur im Unternehmen. Wie breche ich Silos jenseits von Development & Operations auf? Wie schaffe ich gemeinsame Ziele über die Abteilungsgrenzen hinaus? Wie mache ich eine verlässliche Testphase bei einem Deploy am Tag? Woran scheitert es in meinem Unternehmen?

Hinter DevOps steht im Grunde das CAMS-Prinzip: Culture, Automation, Measurement und Sharing. Mit den Zielen, Features deutlich schneller von der Idee zum Kunden zu bekommen, die Verfügbarkeit und Qualität hoch zu halten und dabei den Aufwand und die Zeit für ein Deployment gegen 0 gehen zu lassen. Gleichzeitig sollen die zur Verfügung stehenden Hardware-Ressourcen optimal genutzt werden und Performance- und User-Feedback sehr schnell an Ops, Dev und Product-Development weitergereicht werden.

Nun ist in der Praxis oft genug jedoch nur noch der Punkt Automation spürbar. Schaut man sich die Ursachen dann im Detail an, stellt man eben fest, dass es neben den Tool eben auch noch weiterer Dinge im DevOps-Kontext bedarf. Das Aufbrechen von Silos über viel mehr Kooperation und rollenüberschreitende Teamkultur mit hohem Qualitätsfokus. Autonome Teams. Eine „shared Responsibility“. Vertrauen und Respekt. Und oft genug sind hierzu die grundlegenden Weichen in den Unternehmen noch nicht gestellt, zum Beispiel, wenn die funktionale Struktur lokale KPIs über gemeinsame Ziele stellt, oder eine Hero-Culture die persönlichen Ziele noch vor den Unternehmenszielen würdigt.

Also: Unternehmen brauchen, was DevOps verspricht, und es ist deshalb massiv erfolgreich – ja, insbesondere wegen der Tools. Kultur und Organisation verhindern jedoch noch oft das Erreichen der Ziele und erzeugen so lustige Dysfunktionen. Die kann man reparieren, indem man die Struktur anpasst und an der Kultur arbeitet. Das macht man auf einen von drei Wegen, die tatsächlich helfen, dieses magische Dreieck zu brechen.

Und wie soll man das jetzt reparieren?

Erster Weg zu DevOps: Systems Thinking

  • ein gemeinsames Verständnis des Systems erzeugen
  • Flow von Feature-Idee zu Development zu Produktion zu Kunde und zurück zu Dev abbilden, z.B. über Value Stream Mapping

Zweiter Weg zu DevOps: Feedback Loops einführen

  • „Measure all the things“
  • Feedback über alle Schritte
  • Gemeinsame Anpassungen und Korrekturen

Dritter Weg zu DevOps: Learning Culture

  • Kontinuierliches Experimentieren
  • Risiken eingehen
  • Aus Fehlern lernen
  • Wiederholung und Übung wird zu Meisterschaft
  • Infrastruktur: Learning Cycles & Communities of Practice

Das Resultat: die Gesamtperformance erhöht sich, bei gleichzeitig wachsender Qualität und mehr wertvollen Features. Am Ende stehen mehr Verlässlichkeit und mehr Features bei gleicher Arbeit.

Dieser Artikel ist einer von vielen, die wir regelmäßig in unserem Wiki mit unseren Kolleginnen und Kollegen austauschen. Er beruht in weiten Teilen auf Johanns Notizen, lediglich noch einmal zusammengefasst. Offene Kommunikation ist Teil unserer Kultur und sie hilft uns gut zu sein, in dem was wir tun.

The Puppet Anchor Pattern in Practice

Recently, my team rewrote all Puppet manifests for Mayflower’s core infrastructure with our two year long Puppet experience in mind. Many mistakes were made in the past, but this time we decided to write clean and structured Puppet code based on the latest language features from Puppet 3. More blog posts about advanced Puppet topics are going to be published in 2014.

The main theme of the rewrite was abstraction. Our goal was to use as many third-party modules as possible. Because many modules needed fixes, we contributed a lot of code back to the community. We adopted the Roles, Profiles, Components Design and use Hiera extensively to separate business logic, modules, manifests and data. Our manifests basically glue the modules together and embed them sensibly in our environment, seeded with data from Hiera.

The Problem

If you’ve written your fair share of Puppet manifests, you can imagine that such an architecture requires the definition and inclusion of lots of classes. Sadly, Puppet’s dependency system treats classes different than resources: If you include class foo in class bar, then class  foo and all its contained resources and dependencies won’t have any dependency relations with class bar. Weiterlesen

Percona-Tools für Entwickler, Teil 1

Percona-Toolkit… das ist doch nur für Admins? Mag man denken, aber es gibt in dieser großen Sammlung von Werkzeugen (der Nachfolger von Maatkit) auch Dinge, die ein reiner Developer nutzen kann und sollte. Und ich meine da nicht nur DevOps. Im Artikel wird genau erklärt, welche Tools das sind und wie ihr sie insbesondere als reiner Developer sofort nutzen könnt.

Weiterlesen

IPC die Zweite – DevOps

Nach einem sehr guten Mittagessen, in tollem Ambiente ging es weiter mit dem Powerworkshop von Soenke Ruempler (Jimdo) und Johann-Peter Hartmann (SektionEins GmbH, Mayflower GmbH).
Da sich, vielleicht zum Glück, nur wenige Teilnehmer für diesen Workshop fanden, ging die Vorstellungsrunde recht flink und es wurde schnell deutlich was wir als Publikum zu erwarten hatten.
Die Vortragenden stellten klar das PHP seinen größten Vorteil, das schnelle umsetzen von Anforderungen, durch fortschreitende Professionalisierung eingebüßt habe und Scrum nur einen Teil der Lösung darstellt.
Grund für die Tatsache, dass der Scrumprozess bei dem Benutzer nicht ankommt sind seltene Deployments, welche mehrere Features zusammenfassen.
Dadurch wird der in kurzen Iterationen angelegte Scrumprozess von einem wasserfallartigen Deployment überdeckt.
Grund für die seltenen Deployments ist der erhebliche Zeitaufwand für die Administratoren und der fehlende Projekt überblick, auch als Silo-Problematik bekannt.

Eine mögliche Lösung für das fehlende Betrachten des Gesamtprojektes, wurde mit Kanban recht ausführlich vorgestellt.
Dieses kann genutzt werden, um Engpässe im Projekt zu visualisieren, vor allem wenn diese zwischen Abteilungen entstehen.

Wichtigster Teil des Vortrages war es aber, die Lücke zwischen Development und Administration zu schließen.
Während die Developer vorrangig die Features im Blick haben, steht für die Administration der Reibungslose Ablauf im Tagesbetrieb im Vordergrund.

Schließen kann man diese Lücke durch das richtige Toolset.
Die Administrationsseite kümmert sich darum, eine Infrastruktur zu schaffen, damit das Deployment von den Entwicklern übernommen werden kann und bekommt im Gegenzug das lästige Deployment abgenommen.
Dadurch werden Kapazitäten frei, um die Infrastruktur zu erweitern, was beiden Seiten zu gute kommt.

Für diesen Zweck wurden Puppet und Vagrant vorgestellt.

Puppet ist ein System zur automatisierten Verteilung und Durchführung von Serverkonfigurationen.
Mit Vagrant wurde er Tool vorgestellt, welches anhand von Konfigurationsbeschreibungen beliebig viele virtuelle Maschinen aufsetzten kann.
Konfigurationen können dabei auch aus einem Puppet-Repository stammen, was den Verwaltungsaufwand reduziert.
Mit beiden Tools in Kombination ist es möglich, lokal das Produktivsystem nachzustellen und zu testen.
Das anlegen mehrerer vorkonfigurierter Server wurde dabei ausführlich vorgeführt.

Anschließend wurde noch das Buildpipelining vorgestellt, am Beispiel des Mapolis Projektes.
Buildpipelining beschreibt die Möglichkeit PHPUnit Test und Selenium Test getrennt voneinander auszuführen, letztere nur nach erfolgreichem Verlauf der voran gegangenen Tests.
Theoretisch kann nach erfolgreichem Bestehen aller Buildprojekte ein automatischer Deploy erfolgen.
Praktisch wird jedoch oftmals noch die Freigabe des Projektleiters benötigt.

Das Ziel des Workshops, Administratoren und Entwicklern Tools aufzuzeigen, die die Deploymentrate erhöhen können, wurde in 4 Stunden gut vermittelt und es wurde klar gestellt, dass es mithilfe dieser Tools möglich ist, PHP seinen verlorenen Wettbewerbsvorteil zurück zu geben.
Dennoch waren die 4 Stunden sehr knapp bemessen, die größtenteils abstrakten Inhalte zu vermitteln, weshalb ich trotz der vielen mitgenommenen Ideen danach froh war entspannen zu können.