Container Rechenzentren

„Containerisierte“ Datacenter – sind Container die Rettung für unternehmenseigene Rechenzentren?

Aus Sicht des IT Managements eines unternehmenseigenen Data Centers betrachtet der Artikel Container Lösungen, wie zum Beispiel Docker. Folgende Frage wird behandelt: „Wie sieht die Zukunft der unternehmenseigenen Rechenzentren im Spannungsfeld zwischen externen IT Providern (AWS, T-Systems, ProfitBricks, …) und dem agilen Development aus?“ Projekterfahrungen und Studienergebnisse fließen dabei ein. Dieser Beitrag ist kein „Me-too“-Artikel über die technischen Eigenschaften von Docker.

Ausgangssituation

Vor knapp zwei Jahren waren Container, darunter Docker, nur einigen Linux-Entwicklern ein Begriff. In der Zwischenzeit ist das Interesse an Container-Technik förmlich explodiert. Auch wenn dieser Beitrag ausdrücklich nicht technischer Natur ist, soll „Container“ definiert werden. Hierbei folgen wir gängigen Definitionen von Herstellern und technischen Experten.

„Der Sinn eines ultra-leichtgewichtigen Containers besteht nicht darin, für jedes Problem eine Lösung bereits vorinstalliert parat zu haben, sondern ein minimales, agiles Betriebssystem zu bieten, welches bedarfsgerecht die nötige Funktionalität nachladen kann.“*

Um die weitere Bedeutung und Implikationen abzuleiten, ist es hilfreich, dass wir uns die Beziehungshistorie zwischen Development und Data Center/ Operations anschauen.

Mauer zwischen Development und Operations

Die stetige Professionalisierung der IT brachte eine weitreichende Spezialisierung beider Bereiche mit sich. Auf- und ablauforganisatorisch entstanden funktionale Silos. Die wesentlichen Unterschiede der beiden Silos „Development“ und „Data Center/ Operations“ werden im Folgenden skizziert.

Die Anwendungsentwicklung hat direkten Endkundenkontakt und wird daran gemessen, wie „gut“ und vor allem wie schnell berechtigte Kundenanfragen umgesetzt werden. Die Ansprüche an Qualität und „Time to Market“ führten zu Methoden wie SCRUM, Continous Delivery und Contineous Integration. Die Anwendungsentwicklung ist heute vermehrt in der Rolle des Business Enabler geschlüpft. Unternehmen, die Anwendungen zu langsam oder mit einem niedrigen Qualitätsniveau einführen, riskieren, dass ihre Kunden zu einem Wettbewerber abwandern.

Im Kontrast dazu steht der Data Center/Operations Bereich eher emotional fern von Endkundenanforderungen. Gemessen wird Operation in den Kenngrößen Infrastrukturverfügbarkeit, Sicherheit und Stabilität. Die Bereitstellungszeit von produktionsnaher Infrastruktur ist eine weitere Kenngröße. Virtualisierungprojekte, Automatisierungstechniken und zahlreiche Projekte, oft herstellergetrieben, rationalisierten das Data Center. Unterstützung endkundenrelevanter Innovationsfähigkeit war, wenn überhaupt, ein Randthema.

Der Development Bereich war hoch agil und von endkundenwirksamem Innovationsdruck geprägt. Operations stand, um Verfügbarkeit, Sicherheit und Stabilität sicherzustellen, jeder neuen „Einmischung“ vom Development skeptisch bis ablehnend gegenüber.

Somit wurde jedes funktionale Silo für sich optimiert und nach eigenen Bedürfnissen gestaltet. Eine durchgehende Optimierung von Operations zu Development bis zum Endkunden hat bis heute nicht stattgefunden. Im Gegenteil: Zwischen Development und Operations wuchs eine hohe Mauer, in einigen Unternehmen zusätzlich mit Stacheldraht gesichert.

Welt der zwei Geschwindigkeiten

Diese Charakteristika führten zu einer Welt der zwei Geschwindigkeiten. Das Bild eines Formel 1 Autos beim „Burnout“ drängt sich auf, wo die Hinterräder (Development) in voller Geschwindigkeit qualmend durchdrehen, während sich die Vorderräder (Data Center/Operations) in Zeitlupentempo bewegen. Der Wagen kommt so gut wie nicht voran. So ähnlich ergeht es heute dem CIO. Dieser sitzt im Cockpit und muss sich überlegen, wie der Wagen beschleunigt werden kann – trotz der berechtigten Eigenschaften der beiden Bereiche.

Der Druck auf die Anwendungsentwicklung wird dermaßen hoch, dass agile Data Center/ Operations zwingend benötigt werden, um unternehmerisch handlungsfähig zu bleiben. Wenn dies intern nicht geht, dann eben extern. Die Hemmschwelle, konzernexterne IT – Leistungen einzukaufen, befindet sich im Sturzflug. Lesen Sie hierzu auch gerne den Blogartikel „Die interne IT traditioneller Finanzinstitute schafft sich ab.“

Problemstellung

Wie können in der geschilderte Situation Container, wie z.B. Docker, helfen? Container versprechen, das Bedürfnis der Entwicklung einer schnellen, autonomen Bereitstellung von virtualisierten Servern, mit einem minimalen Betriebssystem zu befriedigen. Unser Projekt, Erfahrungen und Studien ergaben folgende Beweggründe, sich mit Container zu beschäftigen (absteigend sortiert gemäß der Dringlichkeit):

  1. Schnellere Markteinführung von kundengewinnenden Innovationen
  2. Unabhängigkeit der Entwicklung von Operations – bzw. von deren Entscheidungswegen
  3. Bedürfnis von der Entwicklung technologisch das „Neuste“ auszuprobieren
  4. Entlastung von Operations und Verbesserung der Zusammenarbeit mit Development

Container-Vorhaben werden meistens von der Entwicklung initiiert und getrieben. Dabei bieten gerade Container auch für Data Center/Operation eine Chance die Bereitstellungszeiten zu verkürzen und mit externen Data Center-Wettbewerbern gleichzuziehen. Manifestiert wird Governance in dem Container (die bisher fehlende/versäumte) zwischen Entwicklung und Data Center/ Operations. „Treat Infrastructure as Code“ ist hier das Prinzip. Das Development möchte aufwendige, zeitintensive und vor allem ergebnisoffene Entscheidungswege bzgl. Entwickler-Infrastrukturanforderungen vermeiden.

Bildlich gesprochen gleicht der Container einer vordefinierten Rohrpost zwischen Development und Data Center/ Operations, welche durch ein Loch in der Mauer zwischen den beiden organisatorischen Silos geschossen wird. Nicht selten wird unter vier Augen vom Development geäußert, dass der Container/Docker nicht gebraucht würde, wenn denn nur die Bereitstellung von virtuellen Servern innerhalb von wenigen Stunden möglich wäre, mit Rootrechten ausgestattet, um die Entwicklungsumgebung aufzusetzen. Es besteht aber in die übergreifenden organisatorischen Abläufe kein Vertrauen. Zu oft wurde man enttäuscht oder in (Architektur-) Gremien der Data Center/ Operations in der endlosen Warteschleife gehalten.

Verbesserungspotenzial durch Container

An dieser Stelle möchte ich den Bezugsrahmen etwas weiter ziehen und die meist genannten Hindernisse (in %, 2381 befragte Unternehmen) in der gesamten DevOps Bewegung betrachten. So können Container und dessen Lösungspotenzial besser eingeschätzt werden.

DevOps-Einführung: Die größten Herausforderungen

Quelle: Delphix, Gleanster Research (2015): 2015 Annual State of DevOps – A global perspective on the Evolution of DevOps & a Benchmark for success

Containerdienste können demnach primär helfen, mit der Geschwindigkeit des agilen Developments Schritt zu halten. Ein Substitut für nachhaltige, lösungsorientierte Zusammenarbeit zwischen Development und Data Center/Operations oder des notwendigen kulturellen Changes sind Containerdienste sicherlich nicht. Aber vielleicht ist eine toolbasierte Lösung für beide Seiten besser vereinbar und verbindlicher als eine von Managementversäumnissen geprägte Governance. Zudem erscheinen Container für einige konzerneigene Data Center die letzte Möglichkeit, um „5 vor 12“ die Abwanderung des Developments an andere externe Data Center – Anbieter abzuwenden.

Vorläufiges Fazit

Wie kann das traditionelle Data Center mithalten, Geschwindigkeit aufnehmen und auch außerhalb des Betriebes von redundanter Infrastruktur in abgesicherten Rechenzentrums-Flächen mitspielen? Insbesondere in Unternehmungen, in denen eine hohe Innovationsrate vorliegt, also Eigenentwicklungen auf Basis von Web-Applications und Real-Time-Applications stattfinden, besteht Handlungsbedarf, um nicht in der Versenkung des austauschbaren Commodity Lieferanten mit einem dumpfen „Plooob“ zu verschwinden.

So wie vor 10 Jahren die Anwendungsentwicklung den Weg zum Business Enabler angetreten ist, steht die Leitung des Data Centers vor der Frage, welcher Pfad eingeschlagen werden soll. Die meisten Unternehmen der Kategorie „DevOps Leaders“ haben interessanterweise in agiles Data Management investiert (79%)1. Weitere Informationen hierzu finden Sie im “2015 Annual State of DevOps”.

Wie müsste nun das Data Center der Zukunft aussehen, um langfristig seine Existenz zu rechtfertigen? Die folgende Abbildung illustriert die wichtigsten Aspekte des Agilen Data Centers.

Agiles Rechenzentrum

Quelle: Sanjiv Singh

Damit  die oben illustrierte implizite Konvergenz etwas Positives bewirkt, sind nicht nur konvergente Technologien, sondern konvergentes Management plus konvergentes Know-how erforderlich.

Rechenzentrum

Quelle: Sanjiv Singh

Der erforderliche Transformationsweg muss schnell gestartet werden und konsequent gegangen werden. Den erkannten Weg gemeinsam, erkennbar und mit Konsequenz gehen ist die Lösung.

Und übrigens: IT-Manager müssen endlich aufhören, über bessere IT-Silos nachzudenken!

 

*Quelle: http://www.datacenter-insider.de/die-ultra-leichtgewichte-fuer-ein-containerisiertes-datacenter-a-509026/ (Stand: 28.01.2016)

0 Kommentare

Dein Kommentar

An Diskussion beteiligen?
Hinterlasse uns Deinen Kommentar!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.