DevOpsCon 2015 – Erfahrungsbericht von Sascha Kranz

11. Juni 2015


 

Sascha Kranz ist Softwareentwickler bei EsPrestoIch war zusammen mit meinen Kollegen Steve Borchhardt und Denis Gotthans, sowie teilweise auch mit Tobias Burckhardt und Martin Kresse bei der ersten DevOpsCon. Ich versuche hier mal die für mich spannenden Dinge zusammenzufassen.

Tag 1

Docker Basis Workshop (@prossbach)

Hier hatten glaube ich alle recht große Erwartungen, die leider nicht erfüllt werden konnten. Das Format des Workshops macht sicherlich eh nicht so viel Sinn bei 80 oder mehr Personen, aber in diesem Fall hat der Vortragende auch wirklich kaum Praxis angesteuert. Leider. So wurde es eine ziemlich frontale Geschichte, die bei mir nur an wenigen Stellen Interesse geweckt hat. Zudem schien das ganze an vielen Stellen noch nicht komplett ausgereift zu sein. So wurde auf Fragen oft geantwortet: „Ja das geht, indem man ‚XYZ‘ verwendet …aber das ist alles eher kaputt.“ ..haha. Aber ich hab zumindest mitgenommen, dass die Container-Idee Phantasien wecken kann. Die Möglichkeiten scheinen sehr sehr vielfältig. Jetzt muss sich jeder nur noch das raussuchen, was zu ihm oder ihr passt und entsprechend kombinieren. Die Bewegung im Bereich Container scheint enorm, ich vermute ähnlich der von js-frameworks im Frontend. Alle stürzen sich da jetzt drauf und probieren aus und entwickeln usw. Sicher wird nur ein kleiner Teil von alledem überleben, aber ich denke das wird dann relevant sein.

Nightsession: Continuous Delivery in the Cloud (@jweiss)

Der Vortragende war von Amazon und wirkte auf mich ein wenig aufgeputscht, da er sehr viel und recht schnell gesprochen hat und dabei einiges an Energie aufgebracht hat. Das hat mir gefallen Das Ganze war sehr pragmatisch: alles automatisieren und dann ist das alles easy. Ich glaube, er brachte dann auch „immutable servers“ mit rein, d.h. er war der Ansicht, bei Updates an einem Server nicht auf den Kisten selbst rumzufrickeln, sondern das Teil geupdated neu daneben zu setzen und die alte Maschine zu killen. Dafür muss dann eben das komplette System das auch können, also z.b. das Filesystem wird immer in die Systeme reingemounted und ist nie Teil des Systems, da ja sonst Datenverluste nicht zu vermeiden wären usw.. Die These war hier also: wenn das alles von vorne bis hinten darauf angelegt ist so zu funktionieren, dann geht das auch alles.

Tag 2

Begrüßung

Wie zu erwarten, war das eher allgemeines Blabla. Es wurde versucht so ein bisschen „wir erleben hier einen Umbruch !!!“ Feeling aufkommen zu lassen. Plakatives wie „rethink-it“ war sehr zentral. Es wurde immer wieder betont wie cutting edge das Ganze doch sei. Ich glaube zwar, die Begriffe sind alle schon ein paar Jahre alt, aber da fühlten wir uns alle total hip. Ein wenig hat mich die Idee des „radikalen Umdenkens“ dann auch fasziniert und beschäftigt. Mehr dazu dann vielleicht im Fazit.

Innovation Dank devops (@jrirei, folien)

Der Redner war von Wooga und die waren mir schon ein Begriff hinsichtlich Innovation und des Experimentierens mit neuen Technologien und Paradigmen. Er zeigte anhand der Geschichte von Wooga und den Projekten auf, das fast in jedem Projekt massiv neue Technologien eingesetzt werden (Resultat auf Folie 65 hier: http://www.slideshare.net/wooga/innovation-dank-devops. Jeder Kreis ein Projekt). Zum einen, weil aus vergangenen Projekten Schlüsse gezogen wurden und zum anderen auch immer in der Hoffnung, etwas zu sehen/finden, das alle weiterbringt. Der Anteil an fail war dabei erstaunlich klein hatte ich den Eindruck.
Nun hat das alles aber auch sehr stark damit zu tun, wie Wooga funktioniert. Die bauen in jedem Projekt ein Spiel. Mindestens jedes x-te Spiel muss ein Hit sein, sonst ist Wooga kaputt. Das Ganze dann auf einem Markt mit monatlich 1000den anderen Spielen usw. die Projektteams tragen die volle Verantwortung für das Produkt (er verglich es mit kleinen Startups) und bauen es auch komplett selbst. Bis auf die Einbindung einer bi-api (und etwas anderem, dass ich vergesse habe) können die Teams machen was sie wollen. Immer mit dem Ziel vor Augen, dass das am Ende lukrativ ist. Es gibt keine Budgets. Anstelle der Kontrolle tritt hier also stark die (Selbst-)Verantwortung. Interessant fand ich den Umgang mit technischen Innovationen: wenn jemand irgendwann das Projekt wechseln will, muss er seinen Teil sauber übergeben können. Das heißt, er muss zum einen für ordentliche Doku sorgen und auch jemanden finden, der Lust hat, den Teil zu übernehmen. Wenn dort jemand eine Technologie einbringt, die kein anderer übernehmen will, bleibt die verantwortliche Person darauf sitzen. Ob und wie das dann genau abläuft ist nochmal eine andere Frage. Allerdings finde ich auch hier wieder spannend: der Versuch den „gesunden Menschenverstand“ und Vertrauen über klare Prozesse und Regulierungen zu stellen. In der Praxis ist sicher sehr wichtig, wo und wie Prozesse existieren und greifen und wo nicht.

Ich baue mir meinen Container selbst! (Erkan Yanar)

Kurzgefasst: Container sind „Pillepalle“. Das gibts alles schon lange, ist alles alt usw. ..naja. Der Sprecher hat praktisch die 3 Grundbausteie von gängigen Containern (Namespaces, Cgroups, chroot/pivot_root) gezeigt und praktisch mit den im Linux-Kernel vorhandenen Tools einen Container nachgebaut. Das war für mich als Nicht-Admin schon recht spannend. Allerdings zeigte sich für mich dann mal wieder: wenn die Tools kryptisch sind, ist das ein Problem. Erst seit z.b. Docker diesen ganzen Kernel-foo halbwegs einfach in Workflows und Tools gebracht hat, kam Bewegung in die Geschichte. Das ist zumindest mein Eindruck. Vor allem für entwickelnde Menschen ist es damit erst möglich, mit sowas zu arbeiten. Faszinierend auch hier wieder: am Ende ist das alles recht trivial. Es ist keine Magie und Wissenschaft, sondern simpelstes Zeug im Hintergrund. Aufgrund der Menge ist es dann aber doch nicht sofort verständlich. Gerade beim Thema Netzwerk usw. bin ich dann etwas ausgestiegen. Wenn komplexere Probleme auftauchen wie: „Ja das is noch nich ganz gelöst, kommt dann vielleicht in der nächsten Version“.
(Lustig war, dass er im praktischen Teil dann des Öfteren mal gefailed is und das dann immer wieder mit „Pillepalle“ kommentierte. Er wollte auch den Eindruck erwecken, dass jeder das können müsste. Wenn Fragen kamen, meinte er oft sowas wie: „hä? Na lies halt die man-page. Das steht doch alles irgendwo und ist voll trivial.“)

Keynote: How I finally stopped worrying and learnt to love Conway’s law (@boicy)

Das Keynote war ganz nett. Ich kann mich aber nicht mehr an so viel erinnern. Im Zentrum stand, wie zu vermuten, Conway’s law (http://de.wikipedia.org/wiki/Gesetz_von_Conway). In Kürze: Die Struktur der Organisation (sicherlich auch die Kultur) prägt die von ihr gebauten Systeme stark – auch nicht sonderlich neu, aber sicher immer mal wieder ganz interessant darüber nachzudenken, was das z.B. für uns hier bedeutet.

Go – Googles Sprache für skalierbare Systeme (Frank Müller)

Das war ein ziemlicher fail fand ich. Es ging zur Hälfte um ein Admin-Tool namens Juju. Dieses wurde mit „Go“ gebaut. Der „Go“-Teil war dann doch recht wirr und oberflächlich. Da ich bisher nur wenig „Go“ gelesen habe, waren die Beispiele auf den Folien dann auch etwas kryptisch. Was allerdings zu erwarten war: „Go“ ist nice für Nebenläufigkeit und das ist in der Sprache inhärent. Aber „Go“ wirkte auf mich an einigen Stellen auch recht altbacken und erinnerte mich etwas an js, wenn es hieß: das kann selbst nicht viel, aber man kann Vieles damit nachbauen (z.b. Klassen usw.). Allerdings verstand es der Sprecher an vielen Stellen nicht mir näherzubringen, warum die Sprache so ist, wie sie ist. Aber ich vermute, das es sicher nicht verkehrt ist mal „Go“ für serverseiteige Dinge auszutesten.

Sich selbst verstehen – der ELK-Stack im operativen Einsatz eines IT-Betriebs (@lxndrp)

Hier ging es darum, wie ein recht umfangreicher Elk-Stack aufgebaut wurde und wo es Probleme gab. Alles in allem nichts total Überraschendes. Es zeigt sich aber für mich, wenn Mensch sich mit dem Thema beschäftigt, dass die Meinungen im Detail recht stark auseinandergehen. Der eine sagt: „Nimm vor Logstash nicht Rabbitmq, sondern Redis, weil Redis viel perfomanter ist.“ Der andere sagt: „Redis suckt – nimm lieber Apache Kafka.“ Der Nächste geht dann wieder zurück zu Redis. Sicher hängt das auch stark von der Menge der zu verarbeitenden Daten ab. In diesem Talk ging es um Größenordnungen von 50-300 Gigabyte am Tag, glaube ich. Für mich war noch die Aussage spannend, keine time series data in Elk aufzunehmen, also so Dinge wie Statsd, usw. produzieren. Er meinte, Elk kann das nicht und das sei eine sehr schlechte Idee.

Agile Banking mit DevOps und AWS (@hellomichibye, folien)

Der Teil war entgegen meiner Erwartung ziemlich cool. Es wurde beschrieben, wie eine Bank ihre komplette Banking-Anwendung von 0 (jede 6 Monate ein Release eines Monolithen) hin zu 100 (komplett in der Amazon-Cloud mit Continous Delivery und Microservices usw.) gebracht hat. Und das Ganze scheinbar in recht kurzer Zeit. Spannend war hier vor allem, dass es die „Tullius Walden“ ging – eine Kernbank. Die haben ihr komplettes System in die Cloud gebracht. Rechtlich gibt es Vorlagen, wie Banken ihre IT zu bauen haben. Nach diesen ist das legitim – vor allem, weil Amazon der Bank zusichert, dass die Daten in dem deutschen Rechenzentrum bleiben. Wenn ich das richtig verstanden habe, war Amazon zu dem Zeitpunkt das einzige Unternehmen, welches das zusichern konnte. Die Leitung der Bank hat gesehen, dass die IT-Situation sehr problematisch war und hat daher diesen Schritt unterstützt. Nicht nur ich habe da große Augen bekommen. Es kam mehrfach die Nachfrage aus dem Publikum, wie genau die das geschafft haben, da scheinbar sehr viele das Problem haben, dass es große Angst vor der Cloud hinsichtlich Datenschutz gibt.
Die Leute konnten das einfach nicht glauben. Darüber hinaus war die radikale Umsetzung der kompletten Entwicklungssituation mit Hilfe von „aws“ beeindruckend. Die komplette Infrastruktur liegt z.b. als „json“ vor (http://aws.amazon.com/de/cloudformation/) und wird versioniert. Damit ist es dann eben auch möglich, Entwickelnden per Knopfdruck innerhalb von 10 Minuten eine komplette Testinfrastruktur hinzustellen, solange es benötigt wird. Danach wird sie wieder ausgeschaltet. Zusätzlich werden nachts (an sich logisch), wenn keiner arbeitet, die Dev-Teile in der Cloud einfach ausgemacht, um Geld zu sparen. Alles in allem ist das sehr spannend und kaum zu glauben – sollte es wirklich möglich sein, solch eine Anwendung und die Prozesse drumherum so radikal zu modernisieren? Vielleicht ist das ja dann auch bei anderen Projekten möglich. Leider habe ich nicht gehört, wie lange diese Umstellung gedauert hat. Es scheint aber überschaubar zu sein. Auch hier hatte ich wieder den Eindruck: wenn solch ein Thema pragmatisch angegangen wird, ist das durchaus möglich, weil die Technologien und Workflows vorhanden und dokumentiert sind. Das Credo des Vortragenden war ‚lieber 100% anstreben und dann nur 85% schaffen, als 10% anstreben und 10% schaffen‘. Naja das klingt auch irgendwie nett 🙂

Openspace

Hier konnte jeder etwas vortragen. Das war alles nicht sonderlich spannend. Einer von Redhat wollte unbedingt reden und hat gleich 3 Talks eingereicht. Davon bekam er dann aber nur einen Er hat dann versucht etwas Werbung zu machen und wurde danach von Teilen des Publikums etwas auseinandergenommen. Ich fand es unterhaltsam.

Tag 3

„Testing Infra as Code” – Infrastructure CI with Jenkins and Puppet (@harniman)

Hier halte ich mich kurz. Spannend fand ich hier (aber auch wieder logisch), den Anspruch der umfangreichen Tests der Systeme vor der Inbetriebnahme, sprich das Behandeln der Infrastruktur genauso wie die der Anwendung: automatische Integration + Tests hin zu Continuous Delivery. Das vorgestellte Workflow-Plugin von Jenkins ist mir bekannt. Leider ist die kommerzielle Variante um Details gegenüber der freien Variante erweitert, die wichtig sind. So z.B. auch die Möglichkeit, manuelle Schritte (z.B. einen „deploy“-Knopf) einzubauen. Ich nehme mit: Infrastruktur kann (sollte?) so behandelt werden wie Code. Gleicher Anspruch an Korrektheit/Qualität und Automatisierung.

How do you scale a logging infrastructure to accept a billion messages a day? (@stack72)

Der Redner war witzig. Es hat Spaß gemacht ihm zuzuhören. Zusammengefasst ist das Ganze ähnlich dem Elk-Talk vom Vortag. Hier aber: kein Redis sondern Apache Kafka und scheinbar auch „time series“ data in Elk. Zu dem Thema wollte ich nochmal nachfragen; auch, wenn es hier um ein deutlich größeres System geht, als wir es jemals einsetzen würden, sollte klar gestellt werden: es ist wichtig, die Daten zu haben und sie gut zu visualisieren. Dann weiß das Devops-Team vor den Kunden, wenn etwas im Argen ist.

Flyway – Database Migration made easy. (@axelfontaine)

Nett. Ich spiele schon länger mit dem Gedanken, Flyway bei bei einem Projekt mit einzubringen, da die DB-Migrationen derzeit nicht ganz vorteilhaft sind. Meine Angst vor „keinem Rollback“ konnte teilweise genommen werden. Die vorgestellte Strategie „expand + contract“ ist einleuchtend und scheint ok – auch wenn trigger involviert sind 😉

Keynote: DevOps: A Sharder’s Tale (@BethanyMacri)

Das habe ich persönlich gefeiert: nach zwei Tagen modernen Technologien und brandaktuellen Themen, kommt die Dame von etsy und berichtet genau das Gegenteil: ein fetter Lamp-Monolith. Man konnte das ‚WTF?!‘ im Publikum spüren. Der Trick ist denke ich: die radikale Agilität bezüglich Code Deployment. Jeder Commit geht direkt durch die CI und live – also wirklich Continous Deployment. Wenn ich es richtig verstanden habe, dauert es auch nur ca. 20-30 Minuten oder so vom Commit zum Deployment. Rollback gibt es nicht – nur nach vorn. Jeder kann (es gibt trotz allem Bereichs-Teams) an alle Teile der Anwendung ran. Dafür gibt es eine sehr ausgeprägte Post-Mortem Kultur. Vor allem: blameless; das ist scheinbar zentral: jeder Vorfall wird unter den Beteiligten (und allen, die teilnehmen wollen) besprochen, ohne Blame. Es geht eben nur darum: wie ist es passiert und was wir tun können, damit es nicht wieder vorkommt. Naja ich hatte am Ende das Gefühl zu verstehen, wie das bei denen funktionieren kann. Technisch scheint es mir aber nicht so, dass Etsy total happy ist mit der Struktur der Anwendung – das aber durch das besprochene Vorgehen abgefangen wird.

Flight Recorder: Mit Java-Werkzeugen den Dev/Ops Konflikt auflösen (@wolflook)

Oracle zeigte sich mal wieder von seiner besten Seite. Für mich war die Schnittstelle zur jvm und was für Daten da rausfallen, ganz interessant. Es ist in etwa das, was in der PHP-Welt xdebug + apc messen kann –  natürlich etwas anders, aber ähnlich. Der Redner hat dann immer wieder darauf hingewiesen, dass es das ja auch alles Open Source gäbe, aber das sei ja nicht viel Wert, weil die Entwickler nicht so ‚commited‘ seien wie die bezahlte Firma. Er stand da mit seiner crappy Windows-Clicki Software und klickte sich einen Wolf, um für eine Minute nen Mitschnitt zu machen und versucht voll die ‚Enterprise Experience‘ aufkommen zu lassen. Auf die Frage, was das denn koste, hat er dann am Thema vorbei geredet. Ich glaube das kam beim Publikum nicht so richtig gut an.

Diskussionspanel: DevOps – jetzt gleich oder erst morgen oder wie? (@prossbach @stack72 @BethanyMacri)

Tja, hier wurde nochmal versucht zu begreifen und zu fassen, worum’s jetzt eigentlich geht. Nix richtig Neues. Keiner weiß so genau was da jetzt vorgeht, aber es geht etwas Wichtiges vor. Es scheint also vielleicht wirklich angebracht die IT, die wir gewohnt sind, mal umzudenken.
Es ging noch darum, wonach die Firmen denn jetzt genau suchen, wenn neue Mitarbeiter gesucht werden usw.. Dann gab’s noch Meta-Talk zur Conf, der nich so spannend war.

Vielleicht noch erwähnenswert war eine Nachfrage, wie denn nun kleinere Unternehmen mit verschiedenen Kunden Devops-Prozesse umsetzen könnten. Die Idee hier war dann, vielleicht die besprochenen Prozesse in den Bereichen ein- und umzusetzen, in denen die Firma agiert: also z.b. bis zur Übergabe der Anwendung an den Kunden versuchen devops zu denken oder so. Das sei dann schon ein großer Schritt. Etwas schwammig und unklar blieb das dann aber auch.