Dieses Jahr habe ich Gelegenheit zur Teilnahme an der #osdc in Nürnberg.
Die OSCD (Open Source Datacenter Conference) ist eine Konferenz mit dem Thema “Einsatz von Open Source im Rechenzentrum”. Ist die im Herbst stattfindende OSMC (Open Source Monitoring Conference) hauptsächliche auf den Bereich Monitoring mit Icinga, Nagios, Shinken, etc. ausgerichtet, so werden mit der OSDC vor allem die Sysadmins aus dem Ops-Bereich angesprochen.
Dieses Jahr nimmt der Bereich “Devops and Methods” einen, zu Recht, großen Teil ein. Das Thema Devops ist ja schon seit geraumer Zeit in aller Munde. Meiner Meinung nach zu Recht. Allerdings wird das Thema, ähnlich wie der Hype um die Cloud, etwas überbewertet. Devops ist ist vielen Bereichen bereits seit langer Zeit Standard. Was sich momentan entwickelt, sind vor allem die Strukturen und Abläufe. Eine weitere Verzahnung von Operations und Development macht auf jeden Fall Sinn, da die Anforderungen an den Bereich Operations in den letzten Jahren deutlich gestiegen sind. Hat es früher noch gereicht, wenn die Sysadmins ein Basis-System zur Verfügung gestellt und bei Bedarf einen Dienst neu gestartet haben, so wird heute mehr als nur das verlangt.
Zusätzlich zur Bereitstellung des Systems müssen heute, falls mehr als nur ein, zwei Server administriert werden, unter anderem folgende Komponenten möglichst sinnig implementiert werden:

Zusätzlich dazu müssen in immer mehr Bereichen irgendwelche SLAs beachtet werden.
Jede Menge Holz also für einen Berufstyp, welcher früher den Charme eines lichtscheuen Kellerkindes hatte und haupsächlich von irgendwelchen Nerds erledigt wurde. Ich bin mir auch fast sicher, dass die momentane Entwicklung des “devops” nur eine Zwischenstation ist und sich die Sysadmins und Zukunft auf ganz neue Aufgaben einstellen müssen.

Wie ist mein Fazit zum heutigen Tag?

Der erste Vortrag von Kris Köhntopp zum Thema “8 rollouts a day” spiegelt ein Stück weit den Trend zu Continuous Integration wieder. Wie auch im Bereich Development heute schon üblich (aus jedem Commit wird automatisch ein Build gebaut), wird es in Zukunft eine ähnliche Technologie im Bereich der Systemadministration geben. Ob “8 rollouts a day” auch in jeder Umgebung funktionieren wird, wage ich zu bezweifeln. Ein guter Ansatz ist es auf jeden Fall. Meiner Meinung nach muss der Deployment-Weg so weit autoamtisiert werden, dass es keinem händischen Eingriff mehr bedarf. Auch muss es eine Abkehr von festen Release-Zyklen und Builds geben. Eine Version sollte der Einfachheit halber nur eine begrenzte Anzahl an Features beinhalten. Zum einen reduziert dies die Fehleranfälligkeit und Komplexität, zum anderen wird dadurch auch schnell eine kontinuierliche Verbesserung der Software sicht- und fühlbar.
Continuous Integration im Ops-Bereich ist für mich eine faszinierede Sache, über die ich in einer der nächsten Posts etwas genauer berichten werde.

Der zweite Vortrag von Oliver Renault zum Thema “Introduction to Eucalyptus” hat gezeigt, dass alle nur mit Wasser kochen und ähnlichen Technologie nutzen. Wer eine “Cloud-Solution” kennt, kann sich auf die anderen schnell einstellen.
Das Thema Cloud ist für mich sowieso ein sehr interessantes Thema. Die Interpretationsmöglichkeiten sind immens. Ich denke eher, dass sich die Technik in Richtung “Software As A Service (SaaS)” und “Infrastructure As A Service (IaaS)” etablieren wird. Anbieter X wird über eine Plattform tonnenweise Terrabytes zur Verfügung stellen, Anbieter Z über Loadbalancer und jede Menge VMs eine Webapp in einer Tomcat-Farm. Die Basis der Technik wird auf Loadbalancer, Virtualisierung und Skalierbarkeit in die Breite basieren. Interessant wird es im Bereich der Datenbanken werden. Der heutige Standard (RDBMS) ist ja bereits vor 5 Jahren an seine Grenzen gestoßen. Neue Technologien wie z.B. MongoDB oder Cassandra sind noch nicht weit genug verbreitet. In den meisten Fällen wird auch einfach das Wissen dazu fehlen. Heute wird versucht RDBMS über Kunstgriffe mit Clustering, mehr RAM, mehr Platten, also mehr IOPS und Sonderentwicklungen zu tunen. Für viele Bereiche durchaus ausreichend. Sobald aber eine extreme Skalierung in die Breite ins Spiel kommt, bei der immense Lese- und Schreibzugriffe passieren, ist die Technik am Ende. Man darf gespannt sein, was sich in diesem Bereich etabliert.

Der Vortrag über “CFEngine and the future of configuration management is knowledge” zielt da bereits in die richtige Richtung. Knowledge is Power. Vor allem im Bereich des Konfigurationsmangements muss ein umdenken stattfinden. In Bereichen in denen mehrere hundert Server administriert werden, können Änderungen nicht mehr per Hand erfolgen und müssen entsprechend dokumentiert werden. Auch das Wissen, warum etwas geändert wurde, muss festgehalten werden.

“Devops and Open Source” war irgendwie der Basis-Vortrag zu allen vorhergehenden Vorträgen und hat zumindest einen Ansatz der Zusammenarbeit und auch der Tools beleuchtet.

Richtig spannend und auch heiß duskutiert war der Vortrag von Jochen Lillich zum Thema “Operations mit Kanban“. Kanban ist ein ziemlich cooler und einfacher Ansatz um das hochdynamische Umfeld der Systemadministration in den Griff zu bekommen und eine verlässliche Planbarkeit zu gewährleisten. Kanban geht auf eine Initiative von Toyota zur Steigerung der Produktionskapazitäten zurück und beschreibt eigentlich nichts anderes als eine dokumentierte, messbare und kontrollierbare Steuerung einer Produktionskette. Übeträgt man dies nun auf den IT-Bereich, lassen sich viele Dinge übernehmen und umsetzen.
So lässt sich z.B. eine Wertschöpfungskette über die Bereich Backlog, Spezifikation, Development, Test, Operations bilden. In den einzelnen Bereichen wird festgelegt, wieviele Aufträge parallel bearbeitet werdne können. Sind diese abgearbeitet, werden die nächsten Aufträge von der vorhergehenden Stufe abgeholt (Pull-Prinzip). Dies soll verhindern, dass nicht einzelne Gruppierungen in der Wertschöpfungskette überlastet sind und werden. Eine Dokumentation des Ganzen erschließt zum einen eine Meßbarkeit der Vorgänge, zum anderen auch eine Transparenz die wiederum das dringend benötgite Vertrauen in die IT schafft. Wichtig an dieser Stelle ist allerdings, dass alle Teile diesem Vorgehen zustimmen und sich vor allem daran halten.
Jochen hat in seinem Vortrag ein Beispiel mit einem japanischen Garten geschildert. Dort bekommen die Besucher beim Eintritt eine Karte auf welcher nur der Satz steht, dass sie am Ausgang wieder abgegeben werden muss. Der Sinn dieser Karte ist, dass nur eine begrenzte Anzahl an Besuchern den Park besuchen kann. Sind die Karten aufgebraucht, geht nichts mehr. Dies soll den Ansatz von Kanban verdeutlichen. Es darf nur eine begrenzte Anzahl an Tasks zur selben Zeit in der definierten Queue vorhanden sein.
Übertragen auf das tägliche Geschäft, fiel mir die Tatsache ein, dass in vielen Fällen, anstatt die Besucher abzuweisen, sofort neue Tickets gedruckt werden würden. Man darf auch gespannt sein, wie sich diese Technik weiterentwickeln wird. Ich bin mir aber sicher, dass dies ein guter Ansatz ist, die tägliche Arbeit zu organisieren.
Aus den Diskussionen ging auch hervor, dass z.B. das Wasserfallmodell für die Systemadministration nur bedingt bis gar nicht geeignet ist. Das Wasserfallmodel beschreibt eigentlich die stufenweise Entstehung eines Produktes und greift auch dort meiner Meinung nach ein Stück weit daneben. In den wenigsten Unternehmen wird es heute noch so sein, dass genau eine Software entwickelt, getestet und ausgeliefert wird. Aus diesem Grund kann sich eine Kanban-artige Technik auch in der Entwicklung etablieren. Ob das dort heute oftmals verwendete Scrum der richtige Weg ist, wird sich auch noch herausstellen.

Alles in allem ein sehr interessanter und aufschlußreicher Tag. Danke an alle Vortragenden.