Kolumne: Stropek as a Service

Wie die Cloud einen überfälligen IT-Kulturwandel erzwingt
Kommentare

Als SaaS-Anbieter setzten wir in unserer Firma seit vielen Jahren ganz auf Cloud Computing. Da wir nicht nur eigene Produkte entwickeln und anbieten, sondern auch anderen Firmen helfen, SaaS-Lösungen zu bauen, kommt es regelmäßig vor, dass ich mit CTOs von großen Organisationen in Meetings sitze, bei denen es um Sinn oder Unsinn der Cloud geht.

Auch wenn der folgende Gesprächsverlauf erfunden ist, in ähnlicher Form habe ich ihn in den letzten Jahren dutzende Male geführt:

Ich: „Wir würden das Projekt gerne in der Public Cloud umsetzen.“
CTO: „Wir verwenden bei uns keine Public Cloud, wir haben ein eigenes, hoch entwickeltes Rechenzentrum.“
Ich: „In diesem Projekt stehen wir aber unter hohem Zeit- und Kostendruck. Wir glauben, dass die Public Cloud uns helfen würde, schneller und günstiger zum Ziel zu kommen.“
CTO: „Das glaube ich nicht. Unsere internen Kosten für Server sind viel niedriger als in der XYZ Cloud. Wir betreiben heute schon mehrere SQL-Server-Cluster und hunderte Windows-Server. Sagen Sie uns, was Sie für das Projekt brauchen, und unsere Administratoren stellen es zur Verfügung.“

Preislisten von Cloud-Anbietern werden jetzt hervorgeholt und es wird stolz darauf hingewiesen, dass die internen Kosten für einen virtuellen Windows-Server niedriger sind als in der Public Cloud. Vielleicht lassen sich ja sogar bereits bestehende Server verwenden, sodass keine neue Infrastruktur angeschafft werden muss. Und außerdem ist das mit dem Datenschutz sowieso immer schwierig.

Public Cloud & DevOps – die großen Unbekannten

An dieser Stelle ist klar, dass der fiktive CTO noch wenig Erfahrung mit den Konzepten der Public Cloud und DevOps hat. Er übersieht, dass Public-Cloud-Anbieter nicht einfach nur Infrastruktur vermieten. Zwei zusätzliche und wesentliche Eigenschaften kommen dazu: Automatisierung und Self Service.

Wie radikal diese beiden Dinge die Arbeit in Softwareentwicklungsprojekten verändern, lässt sich am fiktiven Beispiel von oben verdeutlichen. Nach dem Gespräch würde ich von der betroffenen IT-Abteilung wahrscheinlich Muster für Anforderungsdokumente erhalten, in denen ich Server Setup, Leistungsfähigkeit, geforderte SLAs etc. beschreiben müsste. Um sie auszufüllen, müsste ich mich bestenfalls durch firmenspezifische Richtlinien und Angebote durcharbeiten. Im schlechteren Fall gibt es diese nicht in schriftlicher Form und es würden etliche Meetings folgen, in denen die Anforderungen ausgehandelt werden. In diesem Prozess würde viel Zeit und Geld verlorengehen, ohne dem inhaltlichen Projektziel auch nur einen Schritt näher gekommen zu sein.

SaaS-Projekte brauchen Flexibilität

Softwareentwicklungsprojekte sind heute nicht weniger komplex als früher, im Gegenteil. Die Vielzahl an Plattformen, Programmiersprachen, Frameworks, Standards etc. gepaart mit hohen Ansprüchen der Anwender sowie Fachkräftemangel machen uns das Leben schwer. In vielen Fällen ist es nicht möglich, die Infrastrukturanforderungen in einem Projekt frühzeitig festzulegen. Dem fiktiven CTO von oben müssten wir antworten, dass wir weder Lust noch Zeit haben, irgendwelche Server zu spezifizieren. Wir brauchen einen gut dokumentierten Pool an IT-Ressourcen, aus dem wir uns selbst je nach Bedarf bedienen können. Wie sollen wir heute festlegen, welche Leistung wir brauchen, wenn wir weder den Verlauf der Benutzeranzahl noch deren genaues Verhalten antizipieren können? Stattdessen wollen wir möglichst rasch loslegen, bei Performanceproblemen elastisch skalieren und dann im Lauf der Zeit durch Optimierung anhand von Echtdaten Schritt für Schritt effizienter werden.

Kann unser CTO das bieten? Die wenigsten können es. IT-Abteilungen sind in der Regel sehr gut darin, Systeme mit gleichbleibenden Anforderungen auf Dauer kostenoptimiert zu betreiben. Die Flexibilität, die heutige SaaS-Projekte brauchen, ist ungewohnt. Die großen Public-Cloud-Anbieter wie Microsoft, Amazon oder Google wurden darauf optimiert.

Wir brauchen Automatisierung

Arbeitszeiten in Softwareentwicklungsprojekten sind flexibel, nicht selten „ungewöhnlich“. Manchmal geht am Tag einfach nichts weiter und der kreative Schub folgt am Abend. Wenn ein wichtiger Termin vor der Tür steht, verbringt man schon einmal ein Wochenende hinter dem Computer und lässt sich dafür während der Woche die Sonne auf den Bauch scheinen. Spezialisten sitzen manchmal am anderen Ende der Welt und man ist dadurch gezwungen, die Arbeitszeit zu verlegen. Was passiert aber, wenn wir mitten in der Nacht neue Server für einen Lasttest brauchen? An wen schicken wir dann das Anforderungsformular?

Wir brauchen APIs, mit denen wir uns die Ressourcen automatisiert holen und sie wieder zurückgeben können, damit unser Ergebnis gut skaliert ist und wir Testszenarien automatisieren können. Wir benötigen Self Service, damit keine wertvolle Zeit mit dem Warten auf manuelle Prozesse verloren geht. Diese Anforderungen sind nicht auf Server beschränkt, wir brauchen sie auch für das Netzwerk. Ein Load Balancer, der auf Basis der Systemlast dynamisch Clusterknoten hinzufügen und entfernen kann, sollte heute keine Ausnahme, sondern die Regel sein.

Meiner Erfahrung nach haben es viele etablierte IT-Abteilungen perfektioniert, Menschen bei Problemen mit IT zu unterstützen. Nur wenige legen genauso großen Wert darauf, den Entwicklungsteams Automatisierungs- und Self-Service-Schnittstellen zu bieten.

DevOps Docker Camp

Das neue DevOps Docker Camp mit Erkan Yanar

Lernen Sie die Konzepte von Docker und die darauf aufbauenden Infrastrukturen umfassend kennen. Bauen Sie Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf!

Wir brauchen Standards

Bei seinem Kostenvergleich übersieht unser CTO den Aufwand, den firmenspezifische IT-Prozesse nach sich ziehen. Neue Mitarbeiter verwenden viel Zeit darauf, Anforderungsformulare für IT-Infrastruktur zu verstehen, gegen veraltete Richtlinien zu kämpfen etc. „Nein, die Version XYZ unterstützen wir auf 64-Bit-Windows-Servern aktuell nicht, da gibt es noch kein Image“ – haben Sie solche Antworten auch schon einmal auf die Palme gebracht?

Die großen Public-Cloud-Dienste halten sich in der Regel an Industriestandards bzw. sind so weit verbreitet, dass sie den De-facto-Standard vorgeben. Es gibt jede Menge Entwickler, die mit den Angeboten und APIs vertraut sind. Sie müssen keine firmenspezifischen Erfindungen lernen, bevor sie mit der produktiven Arbeit beginnen können. Man hat eine Frage zu einem der großen Public-Cloud-Dienste? Das Internet ist voll mit Anleitungen, Foren, Videos etc. Kann unser CTO da mithalten? Meiner Erfahrung nach ist das selten der Fall.

Wir brauchen DevOps

Moderne SaaS-Lösungen liefern neue Funktionen nicht im Jahres- oder Quartalsrhythmus. Sie liefern wöchentlich, täglich, laufend. Dadurch werden Opportunitätskosten vermieden, die entstehen, wenn man die Kundenanforderungen nur mit Verspätung erfüllen kann. Es sinken auch die Support-Kosten, da Fehler nicht nur schnell im Code behoben werden, sondern der korrigierte Code auch rasch ausgerollt wird.

Dieser Entwicklungsrhythmus bedeutet für viele etablierte IT-Organisationen einen radikalen Kulturwandel. Er kann nur erreicht werden, indem Entwicklung und Betrieb nahtlos ineinandergreifen. Quellcodekontrolle, Build, Tests, Deployment, Monitoring – all diese Aspekte müssen automatisiert und verzahnt werden. Entwickler müssen die Konsequenzen ihrer Entscheidungen auf den Betrieb der Anwendung verstehen (und ausbaden). Administratoren verbringen einen großen Teil ihrer Zeit damit, Code zu schreiben (statt C# oder Java eben PowerShell oder Dockerfiles).

Kann unser CTO eine ähnlich integrierte Infrastruktur anbieten, wie zum Beispiel Microsoft mit Visual Studio Team Services und Azure? In den wenigsten Fällen habe ich das bei größeren, etablierten Firmen vorgefunden. Zumeist kämpft man mit manuellen Abläufen, Insellösungen oder veralteten Plattformen.

Private Cloud also unmöglich?

Gibt es zur Public Cloud also keine Alternative? Doch, natürlich gibt es sie. Größere Unternehmen, die auf private Cloud setzen wollen, müssen beginnen, die Prinzipien von Cloud Computing als Ganzes zu erkennen und umzusetzen. Nur weil viele Racks im Rechenzentrum stehen, ist das noch keine vollwertige Cloud. Produkte wie Azure Stack von Microsoft oder Docker erlauben es, die Funktionen der Public Cloud ins eigene Rechenzentrum zu übernehmen, ohne alles neu erfinden zu müssen.

Nichtsdestotrotz bin ich davon überzeugt, dass es in fast allen Unternehmen Projekte gibt, die in der Public Cloud besser aufgehoben sind als im eigenen Rechenzentrum. Die großen Cloud-Anbieter haben ihr Geschäft so perfektioniert, dass es schwierig ist, in Sachen Funktionalität und Preis zu konkurrieren. Man sollte sich die Frage stellen, wo man aufgrund strategischer Überlegungen gewillt ist, Einschränkungen und Kostennachteile in Kauf zu nehmen, um die eigene SaaS-Lösung auf den eigenen Servern zu betreiben. In allen anderen Fällen sollte die Public Cloud zumindest in Betracht gezogen werden.

Windows Developer

Windows DeveloperDieser Artikel ist im Windows Developer erschienen. Windows Developer informiert umfassend und herstellerneutral über neue Trends und Möglichkeiten der Software- und Systementwicklung rund um Microsoft-Technologien.

Natürlich können Sie den Windows Developer über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist der Windows Developer ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -