Reimund

CTO, EMC Deutschland

DevOps „auf Speed“: So bauen Ihre Entwickler „Stateful“ Microservices fürs Unternehmen

In meinen „IT-Trends für 2016“ hatte ich die Prognose gewagt, dass 2016 zum Jahr der „Enterprise-grade-Container“ werden könnte – und dabei auf die Herausforderungen hingewiesen, die im Zusammenhang von Containern und Speicher-Technologien entstehen können.

Dazu erreichte mich kürzlich ein Hinweis aus unserem eigenen Hause. Und zwar von Sebastian Schmidt, Advisory Systems Engineer hier bei EMC und Fachmann für agile Softwareentwicklung. Der erklärte mir: Container und entsprechende Apps gewönnen vor allem im Zusammenhang mit der DevOps-„Philosophie“ (um mich mal bei Rob England zu bedienen) zunehmend an Bedeutung. Und weil die in immer mehr IT-Organisationen eine Rolle spiele, hätten einige Experten bereits Möglichkeiten entwickelt, die von mir beschriebenen Herausforderungen bei der Speicher-Ansprache zu überwinden.

Das wollte ich dann doch genauer wissen – und bat Sebastian, mir die Sache im Gespräch zu erläutern. Nachfolgend finden Sie eine Zusammenschrift des entsprechenden „Interviews“:

##

Also, Sebastian, noch mal von vorn: Warum hast du „DevOps“ ins Spiel gebracht?

Du weißt ja: Inzwischen kommt kaum ein Entwickler, der die veränderlichen Anforderungen „seiner“ Anwender wirklich erfüllen will, um agile Software-Entwicklung herum: Dabei werden Anwendungen in einem interaktiven Verfahren entwickelt, getestet, genutzt und fortlaufend verbessert – ohne großen bürokratischen Aufwand. Um bei alledem keine Zeit zwischen Entwicklung und Betrieb zu verlieren, setzen mehr und mehr Unternehmen auf „DevOps“, also die direkte Interaktion zwischen Entwicklung und Betrieb. Um diese Kultur zu fördern und die Prozesse zu optimieren setzen Unternehmen in vielen Fällen auf Automatisierung, über Software-APIs und mittels Technologien unter anderem für Paketierung, Bereitstellung und Betrieb (Build, Ship, and Run) wie zum Beispiel Docker – womit wir bei deinen Containern wären.

Aha – und welche besondere Rolle spielen die?

Dafür muss ich etwas ausholen. Also: DevOps-Anwendungen werden meist als Microservice-Dienste geliefert. Ein Microservice ist dabei eine kleinst mögliche unabhängig betreibbare Komponente der Applikation, beispielsweise die Warenkorbfunktionalität eines Webshops. Und für die Entwicklung dieser Dienste haben sich zwölf Regeln als „Best Practice“ durchgesetzt – die sogenannten „12 Factor“-Regeln. Diese unterstützen das einfachere Bereitstellen, Skalieren oder Upgraden von Apps sowie einige Extras wie beispielsweise Failover-Features, mit denen eine App Software- oder Infrastrukturausfälle überbrücken kann. Die Regeln sehen vor – und jetzt wird’s etwas technisch –, dass Anwendungen „stateless“ entwickelt werden. Das bedeutet, dass ihre Persistenz-Informationen in einer Anwendungs-unabhängigen Schicht gespeichert werden – entweder einem Objektspeicher oder einer Datenbank, häufig NoSQL…

Und die Container…?

…und die Container kommen ins Spiel, weil kein Entwickler jede neue Anwendung für jedes neue Betriebssystem vollständig neu schreiben will. Zusätzlich wird so das Problem der Packetierung gelöst, da der Entwickler selbst die Paketierung und das Deployment seiner Applikation in Code definieren kann. Ein Problem bleibt aber die „Persistenzschicht“, die der Entwickler nicht unbedingt adaptieren möchte, der Trend geht also zum „stateful“ Container in dem dann auch eine Datenbank betrieben werden kann. Genau deshalb bieten Werkzeuge wie Docker die Möglichkeit, Speicherlaufwerke über APIs oder Plugins anzusprechen. Und damit kann man theoretisch genau die Laufzeit-Persistenz erreichen, von dem du in deinem Blogpost geschrieben hattest. Das wäre für die gesamte DevOps-Dienstentwicklung ein echter Geschwindigkeits- und Ressourcenvorteil.

Verstehe. Aber du sagst ‚theoretisch‘ – worin besteht die praktische Schwierigkeit?

Die große Herausforderung besteht darin, mit der hohen Dynamik umzugehen, die in solchen Umgebungen herrscht. Damit die App im Container eine wirklich stabile Laufzeitpersistenz erreicht, müssen sämtliche Schnittstellen zusammengefasst und zentral gesteuert werden. Und das sind einige – jeweils für Container, Betriebssystem und Speicherinfrastruktur. Die vielen möglichen Varianten zu beherrschen, ist nicht gerade einfach.

Aber ihr habt es geschafft, oder?

Ja, wir und natürlich viele andere auch. Das besondere an unserer Architektur ist, dass sie den frei verfügbaren Software-defined-Storage-Layer von EMC ScaleIO nutzt; als Container haben wir Docker eingesetzt. Und wo du jetzt schon fragend guckst: Als Volume-Treiber verwenden wir Rex-Ray, auch eine EMC-Entwicklung. Zusätzlich bieten wir noch DVDI als Mesos Isolator-Modul, das nutzt Rex-Ray, um beliebigen Mesos-Diensten eine vollautomatisierte Kontrolle über die Persistenz zu geben – also nicht nur Docker…

Eigentlich wollte ich vor allem wissen, was Eure Architektur den Entwicklern bringt!

Achso… Na, sie ermöglicht zu allererst mal das Entwickeln von „stateful“-Microservices bzw. Containern mit persistenten Speicherlaufwerken, die auf einem zentralen Storage-System liegen. Das ist genau das, was du dir in deinem „Predictions“-Blogpost gewünscht hast. Man kann damit auch Speicherlaufwerke erstellen, entweder neu oder als Snapshot-Kopie, und die Laufwerke mounten, unmounten und zwischen Hosts übertragen. Das ermöglicht auch automatische Failover-Abläufe für Container und Persistenzlaufwerke, auch zwischen verschiedenen Hosts. Bei alledem ist die Architektur kompatibel zu Speicherdiensten wie AWS EC2 (EBS), OpenStack (Cinder), EMC ScaleIO, EMC Isilon, EMC XtremIO, EMC VMAX, der Google Compute Engine oder Virtual Box.

Hört sich gut an! Wo könnte ich mehr darüber erfahren?

Für alle, die sich grundsätzlich und umfassend über DevOps informieren möchten, empfehle ich natürlich die Roundtables, die EMC zum Thema organisiert – die nächsten finden bereits morgen und übermorgen statt: am 24. Februar in München und am 25. in Stuttgart.Wenn ich mich nicht täusche, ist eine Anmeldung bei beiden noch möglich. Zwei weitere folgen im zweiten Quartal in Frankfurt und Berlin. Wer sich speziell für die Architektur interessiert, die ich Dir beschrieben habe: Dazu habe ich mal einen Einseiter für das Java-Magazin erstellt, den Entwickler sich zum Beispiel hier herunterladen können:

Persistenz mit Stateful-Microservices für Continuous Deployment

##

P.S.: Allen, denen diese Mitschrift nicht genügen sollte, seien noch diese Weblinks ans Herz gelegt:

Anmeldung zum EMC-DevOps-Roundtable in München, 24.02.:

https://germany.emc.com/events/2016/q1/24-02-16-devops-munchen.htm

Anmeldung zum EMC-DevOps-Roundtable in Stuttgart, 25.02.:

https://germany.emc.com/events/2016/q1/25-02-16-devops-stuttgart.htm

Die Termine für die Roundtable in Frankfurt und in Berlin folgen.

DevOps Conference in Berlin vom 13.06 bis 16.06.2016:

http://devopsconference.de/de/

„12 Factor“-Regeln zur App-Entwicklung:

http://12factor.net/de/

Download des EMC-ScaleIO-SdS-Layers: http://www.emc.com/getScaleIO

Download Rex-Ray: https://www.github.com/emccode/rexay

Download DVDI: https://www.github.com/emccode/mesos-module-dvdi

EMC_Bild2