Neue Technologien und neue Teams – ein fundamentaler Wandel in der IT

Innovation der Startup-Szene – auch für Enterprises

Eberhard Wolff
©Shutterstock/Skovoroda

Viele Start-ups haben IT-basierte Geschäftsmodelle und stellen daher sehr hohe Anforderungen an ihre IT. Gleichzeitig haben sie nur ein geringes Budget. Unter diesen Voraussetzungen entstehen neue IT-Ansätze. So hat der Fotodienst Instagram 10 Millionen Nutzer und 100 Millionen Fotos mit nur drei Mitarbeitern für Entwicklung und Betrieb betreut. Die IT-Welt in Enterprises sieht aber ganz anders aus. Welche Ansätze werden genutzt, und was lässt sich auch im Enterprise verwenden?

Grundlage ist zunächst die Cloud. Als Definition dieses Ansatzes hat sich mittlerweile [1] durchgesetzt. Im Mittelpunkt steht das Konzept, alles als Service anzubieten. Diese Services können Nutzer selbstständig durch ein Portal buchen. Die Services werden dann vollautomatisch zur Verfügung gestellt. Genauso arbeiten Cloud-Anbieter, wie Amazon oder Google: Server oder Datenbanken können über ein Portal gebucht werden und stehen dann für den Nutzer bereit.

Cloud

Für Start-ups ist die Nutzung solcher Public Clouds nützlich. Mittlerweile kommt wohl kaum eine Start-up ohne die Dienste von Amazon aus. So steht ohne eigenes Investment eine Umgebung bereit, die weltweit ihre Dienste anbietet und auch redundanten Betrieb in mehreren getrennten Rechenzentren ermöglicht. Außerdem können Anwendungen sehr einfach skalieren, weil jederzeit neue Server hinzugebucht werden können. Gerade für Start-ups ist das ein signifikanter Vorteil, da sie vorab kaum abschätzen können, wie viele Nutzer sie haben werden und die Nutzerzahlen ständig steigen.

Für Enterprises ist die Nutzung von Public Clouds hingegen aus Gründen des Datenschutzes oder anderer rechtlicher Einschränkungen oft nicht möglich. Außerdem haben sie meistens schon viel Geld in eigene Rechenzentren investiert. Daher ist die Nutzung der Public Cloud in Enterprises oft nicht nur unmöglich, sondern viele Vorteile können gar nicht ausgenutzt werden.

An dieser Stelle ein Hinweis zu dem Kostenvorteil einer Public Cloud: Viele gehen davon aus, dass Cloud-Anbieter große Infrastrukturen betreiben und so kostengünstiger sein können. Vor allem für den Betrieb mit vielen Lastspitzen ergeben sich tatsächlich Kostenvorteile, weil nicht überdimensionierte Server vorgehalten werden müssen, sondern gegebenenfalls hinzugebucht werden können. Aber auch Hosting-Anbieter bieten Rechner und andere Infrastruktur preiswert an – nur eben nicht so, dass die Rechner innerhalb von Minuten zur Verfügung stehen und auch wieder heruntergefahren werden können. Zumindest in Bezug auf die Kosten können solche Angebote oft günstiger sein – und der Betrieb vieler IT-Lösungen ist ja sowieso an spezialisierte Anbieter ausgelagert. Public Cloud ist vor allem auch dann kostengünstiger, wenn es zu Lastspitzen kommt.

Der nächste Schritt nach Virtualisierung

Wenn aber in vielen Fällen die Public Cloud keine Option ist – warum sollten sich Enterprises überhaupt für solche Technologien interessieren? Ein wesentliches Problem bei vielen klassischen IT-Infrastrukturen ist, dass die Bereitstellung neuer Server ein langwieriger und komplexer Prozess ist. Es sind Bestellvorgänge und Genehmigungen notwendig sowie manuelle Schritte. Das ist oft auch dann der Fall, wenn Virtualisierung genutzt wird. Da hier keine physische Hardware genutzt wird, wäre ein neuer Server dann oft eigentlich nur ein Mausklick. Dieser technische Vorteil wird aber nicht ausgenutzt, da die Prozesse nicht mithalten.

Wenn die virtuelle Umgebung durch ein Self-Service-Portal ergänzt wird, kann ein Nutzer selbst Ressourcen wie Server oder Festplatten buchen. Dadurch hat er denselben Komfort wie in der Public Cloud, nutzt aber Ressourcen aus dem Rechenzentrum. Das ist ein sinnvoller nächster Schritt nach der Virtualisierung: Ursprünglich war die Motivation für die Virtualisierung eine Konsolidierung physischer Server hin zu virtuellen Servern. Dabei konnte Hardware eingespart werden, da Server typischerweise nicht immer voll ausgelastet sind und so die physische Hardware mehr virtuelle Hardware anbieten konnte.

Mithilfe eines Self-Service-Portals wird ein weiterer Vorteil ermöglicht: Neue Ressourcen können viel schneller und flexibler zur Verfügung gestellt werden. Solche Lösungen sind auch für die Softwareentwicklung nützlich:

  • Testumgebungen können viel schneller und einfacher aufgebaut werden. Idealerweise ist dann schon die richtige Softwareversion installiert.
  • Bei Performancetests kommt hinzu, dass größer dimensionierte Server oder eine größere Anzahl Server leicht genutzt werden können – sie müssen nur durch das Portal vom Nutzer angefordert oder umkonfiguriert werden. Das ist eine Sache von Minuten. So kann sich das Team schrittweise dem idealen Sizing annähern.
  • Wenn Testumgebungen schneller aufgebaut werden können, gilt das natürlich auch für Staging-Umgebungen und schließlich die Produktionsumgebung.

So kann die Entwicklung beschleunigt werden, da die Wartezeiten für die Bereitstellung von Servern entfallen. Und außerdem können in der Produktion Snapshots von Servern erstellt werden, die dann analysiert oder beispielsweise für Tests verwendet werden können.

Aber die Cloud hat noch viel mehr zu bieten. Wer auf die Angebote von Amazon schaut, wird feststellen, dass es dort nicht nur Speicher, Festplatten und Server zu mieten gibt. Das Angebot umfasst auch relationale Datenbanken, NoSQL-Datenbanken oder Messaging-Lösungen. Der Aufbau einer Website für Fotos wird so möglich: Die Fotos können auf Amazon S3 gespeichert werden. Dazu kommt dann noch Code, um die Fotos in Galerien darzustellen, Benutzer zu verwalten usw. Genauso ist Instagram entwickelt worden. Die wesentlichen Bausteine sind von der Cloud geliefert worden. So konnten die technischen Herausforderungen recht einfach gelöst werden.

Industrialisierung?

Die Cloud bietet also sehr mächtige Komponenten an, die in eigenen Anwendungen verwendet werden können. Diese Komponenten wie Datenbanken oder Speicher haben schon lange bewiesen, dass sie universell nutzbar sind. Die Cloud macht nur den Zugriff einfacher, um so eine höhere Produktivität zu erlauben. Solche Komponenten können auch im eigenen Rechenzentrum eingerichtet werden, sodass dieser Vorteil allen Unternehmen auch für sicherheitskritische Anwendungen offen steht.

Continuous Delivery

Neben Self-Service-Portalen können die beschriebenen virtuellen Umgebungen natürlich auch durch entsprechenden Code aufgebaut werden – die Interaktion durch den Menschen wird lediglich durch einen Aufruf ersetzt („Infrastructure as Code“). Damit können klassische Probleme anders angegangen werden: Die Produktionseinführung von Software ist ein schwieriger und komplexer Prozess. Meistens benötigt er auch sehr viel Zeit, und er ist auch fehleranfällig. Oft wird die Einführung eines neuen Releases auf das Wochenende verlegt, weil dann die Anwendungen nur wenig genutzt werden. Und dann sitzt das Team Sonntagabend zusammen und versucht, die Software irgendwie zum Laufen zu bringen.

Schon in [2] wurden einige Prinzipien aufgestellt: Wenn etwas nur unzureichend funktioniert, sollte es öfter getan werden – und vor allem frühzeitig, damit die Probleme schnell gelöst werden können. Ein weiteres Prinzip ist die Empfehlung, möglichst keine manuellen Prozesse zu nutzen.

Wer diese Prinzipien auf das Problem der Produktionseinführung anwendet, kommt auf die Idee der Continuous Delivery: Software soll möglichst oft und automatisiert in Produktion gebracht werden. Dadurch sollen die Herausforderungen in diesem Bereich besser gemeistert werden [3].

Dabei wird eine Pipeline etabliert, durch die Software geschickt wird, bis sie in Produktion ist. Ziel dieses Ansatzes ist es, die Pipeline explizit darzustellen und in einem nächsten Schritt dann auch zu optimieren:

  • Der erste Schritt ist der Commit: Ein Entwickler hat eine Änderung am Code vorgenommen und stellt die Änderung den anderen Teammitgliedern zur Verfügung. Dazu wird der Code kompiliert und durch die vom Entwickler geschriebenen Unit Tests getestet. Das Ergebnis ist eine installierbare Anwendung.
  • Bei den automatisierten Akzeptanztests werden die benutzerdefinierten Anforderungen getestet. Das kann beispielsweise auf Ebene des GUI stattfinden. Eine Alternative ist, direkt den Code zu testen, und zu sehen, ob er die erwarteten Werte zurückgibt. Dazu sind Ansätze wie Behavior-driven Design [4] nützlich. Dabei werden die Anforderungen der Benutzer in natürlicher Sprache festgehalten und dann die Anforderungen als Tests ausgeführt. Da dazu keine Programmiersprache, sondern natürliche Sprache genutzt wird, können Domänenexperten oder Kunden nachvollziehen, ob die Anforderungen korrekt erfasst sind. Durch das Einhalten bestimmter Konventionen können die Tests automatisiert ausgeführt werden.
  • Neben den funktionalen Anforderungen müssen natürlich auch die nicht-funktionalen Anforderungen überprüft werden. Dazu sind automatisierte Tests notwendig, die mit realistischen Szenarien und Daten die Anwendung bezüglich Performance testen. Dazu kann an unterschiedlichen Ebenen angesetzt werden: Die Benutzeroberfläche, eine öffentliche Programmierschnittstelle oder interne, spezifische Schnittstellen können genutzt werden, um das Verhalten der Anwendung auszutesten. Dazu muss dann auch ein produktionsähnliches System zur Verfügung stehen. Es muss nicht genauso leistungsfähig sein wie das Produktionssystem, aber zuverlässige Vorhersagen über das Verhalten der Anwendung im Produktionsumfeld erlauben.
  • Neben den automatisierten Ansätzen müssen auch Tester auf das System zugreifen. Dazu dient der Schritt des manuellen Testens. In diesem Schritt wird vor allem explorativ herausgefunden, wie das System sich bei den neu implementierten Features verhält. Die Tests für diesen Bereich können (noch) nicht automatisiert werden, da es um ganz neue Features geht. Durch die Automatisierung der anderen Schritte stehen für diesen Schritt genügend Ressourcen zur Verfügung.
  • Am Ende steht die Produktionseinführung. Dabei wird die Anwendung automatisiert auf der Produktionsumgebung installiert. Zur weiteren Risikominimierung kann es getrennt als neues System installiert werden. Das arbeitet zunächst im Hintergrund und übernimmt dann irgendwann tatsächlich die Aufgaben.

Aufmacherbild: Start up business concept von Shutterstock / Urheberrecht: Skovoroda

[ header = Innovation der Start-up-Szene – auch für Enterprises – Teil 2 ]

Für verschiedene Schritte müssen Testumgebungen aufgebaut werden. Der Aufbau dieser Umgebungen muss automatisch erfolgen, wenn die Pipeline wirklich optimiert werden soll. Daher ist der automatisierte Aufbau von Umgebungen ein wesentliches Element für Continuous Delivery.

Start-ups profitieren sehr von Continuous Deployment: Neue Features können schnell in Produktion gebracht werden. Dadurch wird eine bessere Time-to-Market erreicht, was vor allem für den intensiven Wettbewerb, dem Start-ups ausgesetzt sind, ein Vorteil ist. Start-ups können solche Ansätze außerdem von Anfang an nutzen und so schrittweise die notwendige Infrastruktur aufbauen.

Bei Enterprises ist die Situation anders: Teilweise ist eine so hohe Geschwindigkeit nicht sinnvoll, weil das Geschäft sowieso nur ein Release pro Quartal benötigt. Oder es gibt eine so gewachsene IT-Struktur, dass so eine hohe Geschwindigkeit nicht erreicht werden kann. Alte Host-Systeme können die notwendige Flexibilität oft nicht bieten. Und auch die Daten in den Datenbanken können nur schwer auf neue Versionen konvertiert werden.

Continuous Deployment hat für Enterprises andere Vorteile: Das manuelle Testen und das manuelle Einrichten von Testumgebungen sind schwierig, komplex und fehleranfällig. Gerade in diesem Bereich können Continuous-Delivery-Prinzipien gewinnbringend genutzt werden.

Aber auch sonst gibt es einige Vorteile. Software wirklich in Produktion zu bringen, ist oft sehr stressig. Bei der Produktionseinführung können Fehler auftreten, die teilweise erhebliche Konsequenzen haben – und sich am Ende auf relativ kleine Unterschiede zwischen verschiedenen Servern oder auf unterschiedliche Konfiguration der Test- und Produktionsumgebung zurückführen lassen. Continuous Delivery setzt dem eine exakte Reproduzierbarkeit durch Automatisierung entgegen. Das Deployment der Anwendung ist vor dem Produktionsstart schon mehrmals getestet worden – beim Aufbau der verschiedenen Testumgebungen. Der Aufbau der Produktionsumgebung ist nur noch ein weiterer Durchlauf durch dieselbe Pipeline und dank der Automatisierung auch reproduzierbar.

Wenn dennoch öfter in Produktion deployt wird, ergibt sich sogar ein noch geringeres Risiko. Das erscheint paradox, denn Releases nur selten in Produktion zu bringen, ist ja gerade eine Strategie, um das Risiko zu minimieren: Wenn etwas weniger häufig gemacht wird, kann es auch nur weniger oft schiefgehen.

Aber das Gegenteil ist der Fall: Wenn nur selten neue Versionen in Produktion gegeben werden, ist jedes Release eine umfassende Änderung mit entsprechend hohem Risiko. Weit geringer ist das Risiko, wenn die Software öfter in Produktion gebracht würde, sodass weniger Änderungen in jedem neuen Release enthalten sind. Das gilt aber natürlich nur, wenn die Prozesse für die Produktionseinführung weitgehend automatisiert und reproduzierbar sind. Da das aber oft nicht der Fall ist, nutzen viele Organisationen einen solchen Ansatz nicht.

Für den Einsatz im Enterprise ist der Begriff „Continuous Delivery“ also fast irreführend: Es geht nicht unbedingt darum, jedes Release in Produktion zu bringen und schon gar nicht um einen vollständig automatisierten Prozess. Vielmehr ist das Ziel eine Optimierung und Automatisierung, da wo es sinnvoll ist. Und vor allem wird die Auslieferung in Produktion in den Prozess einbezogen. Dieser Schritt ist sehr wichtig und wird in den klassischen Prozessansätzen meistens nicht weiter betrachtet. Wie Abbildung 1 zeigt, schließt Continuous Delivery den Kreis bei agilen Ansätzen: Während agile Prozesse auf Analyse und Implementierung fokussieren, fügt Continuous Delivery die Installation der Anwendung hinzu und ermöglicht so, dass Feedback aus der Produktion wieder in den Prozess einfließen kann.

Abb. 1: Agile Softwareentwicklung und Continuous Delivery

DevOps

Aber wer kann Ansätze wie Continuous Delivery überhaupt umsetzen? Klassisch gibt es in IT-Abteilungen eine Trennung zwischen Betrieb und Entwicklung. Diese Abteilungen haben unterschiedliche Ziele: Die Entwicklung muss neue Features implementieren, während der Betrieb vor allem Verfügbarkeit und Performance im Blick hat. Dadurch ergeben sich Konflikte: Der Betrieb würde Software am liebsten nie ändern, um so vollständige Stabilität zu erreichen. Das kollidiert mit den Zielen der Entwicklung.

Aber am Ende will der Kunde ein stabiles System und neue Features. Dieses Ziel kann nur von Entwicklung und Betrieb gemeinsam erreicht werden. So zeichnet sich eine Evolution zu einer stärkeren Kollaboration ab. Aus dieser Kollaboration ist der Begriff DevOps entstanden: Er steht für eine enge Zusammenarbeit zwischen Entwicklung (Dev) und Betrieb (Ops).

Ein weiterer Grund für diese Evolution sind die Änderungen in der Technologie: Server werden durch ein Self-Service-Portal erzeugt – ohne manuelles Eingreifen. Das Deployment der Anwendung kann dank Continuous Delivery automatisch erfolgen. Der Betrieb wird solche Dienste zur Verfügung stellen. Dafür muss der Betrieb Automatisierungen entwickeln. Man spricht von „Infrastructure as Code“, um auszudrücken, dass auch die Infrastruktur letztendlich nur noch durch den entsprechenden Code erzeugt wird. Das ist aber eigentlich eher Entwicklung. Natürlich ist das Wissen des Betriebs immer noch unbedingt notwendig: Das Ergebnis von Continuous Delivery soll eine produktionstaugliche Umgebung sein. So etwas kann keine Entwicklungsabteilung aufbauen, weil Wissen, beispielsweise um Monitoring oder Auswertung von Log-Files usw., fehlt.

Die beiden Bereiche haben jeweils eigene Expertise: Die Entwicklung kennt sich mit der Anwendungslogik, der Persistenz und dem Datenzugriff aus. Der Betriebsbereich hingegen kann mit Monitoring ungewöhnliche Zustände der Systeme identifizieren und Alarme auslösen.

Das kann die Basis für weitere Kollaborationen neben Continuous Deployment sein: So kann die Entwicklung spezialisierte Werkzeuge für die Analyse der Anwendungen entwickeln. Umgekehrt kann der Betrieb der Entwicklung die Möglichkeit geben, die vorhandene Monitoring- und Alarminfrastruktur für spezifische Metriken zu nutzen. Oder die Entwicklung kann in die Anwendung Feature Toggles einbauen, mit dem Features deaktiviert werden können. So kann der Betrieb bei Problemen bestimmte Teile der Anwendung ausschalten, um einen vollständigen Ausfall zu vermeiden.

Bei DevOps sind die Teams dann nicht nach Betrieb und Entwicklung getrennt, sondern nach fachlichen Bereichen. Bei einer E-Commerce-Website können das der Einkaufswagen oder die Produktsuche sein.

Bei Start-ups ist der Weg zu DevOps vorgezeichnet: Zumindest am Anfang müssen sowieso die Techniker beide Rollen übernehmen, sodass die enge Kollaboration sich natürlich ergeben kann. Wenn dann schrittweise Teams für die fachlichen Teams entstehen, ist so eine Skalierung des Ansatzes sehr einfach möglich. Der Ansatz funktioniert auch für große IT-Organisationen. Amazon beispielsweise arbeite schon lange nach diesem Ansatz.

Im Enterprise liegen die Dinge etwas anders: Klassisch sind die beiden Bereiche geteilt – ganz im Sinne der Spezialisierung und Arbeitsteilung. Auf jeden Fall ist jedoch mindestens für die Produktionseinführung eine enge Kollaboration zwischen Betrieb und Entwicklung notwendig. Aber ansonsten sind die beiden Abteilungen sehr unterschiedlich: Die Entwicklung arbeitet an Projekten und implementiert neue Features. Der Betrieb hingegen muss die Kosten reduzieren und die Systeme am Laufen halten. Projekte sind kaum üblich. Diese Aufteilung ist universell und eine erhebliche Barriere, da die Organisation nur schwer geändert werden kann. Am Ende steht aber die Orientierung der IT an fachlichen Diensten, die auch Kunden verstehen, und damit eine wesentlich bessere Kundenorientierung. Außerdem erzwingen schon Continuous Delivery und Cloud Änderungen, da sich die Tätigkeiten von Entwicklung und Betrieb angleichen.

Abb. 2: Zusammenhang zwischen den Techniken

Fazit

Die verschiedenen Technologien hängen zusammen (Abb. 2): Durch Cloud und Virtualisierung wird Continuous Delivery möglich, weil nur so die benötigten Server ausreichend schnell aufgesetzt werden können. Continuous Delivery wiederum ist eine wichtige Praktik für DevOps, und durch Cloud ändern sich die Tätigkeiten des Betriebs, sodass die Evolution zu DevOps weiter beschleunigt wird. Am Ende werden Enterprises in Zukunft eine automatisierte Infrastruktur nutzen – auf Basis von Virtualisierung im eigenen Rechenzentrum oder vielleicht auch in der Public Cloud. Auf dieser Basis kann die Produktionsstellung von Software optimiert werden. Dadurch gleichen sich Betrieb und Entwicklung schon an – und am Ende stehen dann echte DevOps-Teams.

Geschrieben von
Eberhard Wolff
Eberhard Wolff
Eberhard Wolff ist Fellow bei innoQ und arbeitet seit mehr als fünfzehn Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u.a. zu Continuous Delivery und Microservices und trägt regelmäßig als Sprecher auf internationalen Konferenz vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Continuous Delivery, DevOps, Microservices und NoSQL.
Kommentare

Schreibe einen Kommentar

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