Modernes DevOps: Business und IT verdrahten

So verstehen wir modernes DevOps

Sebastian Meyen

Die DevOpsCon 2016 findet vom 5. bis 8. Dezember in München statt. Mit welchem Verständnis von DevOps die Konferenz auftritt und die Themenkomplexe Continuous Delivery, Microservices, Cloud, Container und Unternehmenskultur zusammen denkt, erklärt Program-Chair Sebastian Meyen in diesem Artikel.

Modernes DevOps: Business und IT verdrahten

Eine gesunde Abstimmung zwischen Teams, die getrennt voneinander arbeiten, aber in gemeinsame Geschäftsprozesse involviert sind, ist selten einfach. Daher schlug 2009 eine Gruppe um den Belgier Patrick Debois den Begriff DevOps vor — als Ansatz, das Problem auf der Ebene von Softwareentwicklern (Devs) und Administatoren (Ops) zu lösen. Seit diesen Anfängen hat sich die DevOps-Bewegung deutlich weiter entwickelt und die Grundbegriffe der IT sowie deren Rolle in den Unternehmen fundamental verändert.

Die Business-Treiber für DevOps

Bestand das ursprüngliche Problem darin, die Prozesse in herkömmlichen IT-Settings – klassischer On-Premise-Server, getrennte Dev- und Ops-Abteilungen – geschmeidiger zu gestalten, hat die DevOps-Bewegung ihr wichtigstes Betätigungsfeld mittlerweile dort, wo es um konsequente Digitalisierung und hohen Innovationsdruck geht.

Nicht wenige Branchen sehen sich, getrieben durch das Internet, wachsendem Veränderungsdruck gegenüber. Während die einen noch verzagt auf den Verlust ihrer angestammten Märkte reagieren, machen sich die anderen auf in eine offene, immer schwieriger planbare Zukunft. Konsequente Digitalisierung und eine Hochleistungs-IT sind hier die wichtigste Voraussetzung — wie nicht zuletzt die bekannten Internet-Companies à la Netflix, Spotify und Uber demonstrieren.

Welches genau die Business-Treiber für eine DevOps-Kultur sind, möchte ich an dieser Stelle in einer (sicherlich unvollständigen) Schlagwortliste andeuten:

  • Globalisierungseffekte sorgen heute in praktisch allen Branchen für einen verschärften Wettbewerb.
  • Das Internet respräsentiert weit mehr als nur einen modernen Marketing- und Vertriebskanal für traditionelle Geschäftsmodelle; es hat das Potenzial, sämtliche klassischen Geschäftsmodelle umzukrempeln, diese obsolet zu machen oder zu modifizieren.
  • Disruption bedeutet nicht die Ausnahme, sondern wird in praktisch allen Märkten zur Regel. Deshalb entwickelt sich die Innovationsfähigkeit eines Unternehmens zu dessen wichtigsten Erfolgsfaktor.
  • Entsprechend können Märkte nicht mehr als stabil wahrgenommen werden und langfristige Planungen werden obsolet; iterative Strategien und häufige Kurskorrekturen werden dagegen essentiell.

Fünf Faktoren für DevOps

Modernes DevOps bringt nicht nur Devs und Ops zusammen, sondern verfolgt das ehrgeizige Ziel, Business und IT über Team- und Systemgrenzen hinweg zu integrieren. Diesen Zusammenhang wollen wir auf unserer DevOpsCon, die vom 5. bis zum 8. Dezember stattfindet, mit erfahrenen Speakern aus aller Welt erörtern.

Ich werde im Folgenden versuchen, die wichtigsten Strömungen, deren Zusammenfließen einen nachhaltigen Wandel in Richtung DevOps bewirken kann, zu beschreiben. Damit liefere ich zugleich auch eine Darstellung der Überlegungen, die uns – im Wesentlichen Peter Roßbach und mich — bei der Gestaltung des Programms der DevOps Conference geleitet haben.

Wollen wir herkömmliche Systeme und Organisationen nicht nur graduell verbessern, sondern einen weitergehenden Wandel anstoßen, dann müssen wir folgende Faktoren in den Mittelpunkt stellen:

  1. Continous Delivery
  2. Microservices
  3. Cloud-Plattformen
  4. Container-Technologie
  5. Unternehmenskultur

Lassen Sie uns im Folgenden auf die fünf Punkte eingehen und ihre gegenseitigen Wechselbeziehungen beleuchten.

Continuous Delivery

Continuous Delivery — die Automatisierung sämtlicher Aspekte des Deployments — spielt für Internet-Unternehmen schon seit langem eine bedeutende Rolle. Sie interessieren sich für die Möglichkeit, Bugfixes, Modifikationen oder auch neue Features so schnell wie möglich in Produktion zu bringen, ohne dafür hohe Risiken für das Gesamtsystem in Kauf nehmen zu müssen.

Solche Unternehmen bringen neue Software-Releases typischerweise nicht halbjährlich in Produktion, auch nicht monatlich oder etwa täglich, sondern mehrmals pro Tag! Warum aber sind für solche Teams die häufigen kleinen Releases besser als seltene große? Weil ein großes Backlog erst gar nicht entstehen kann. Unerledigte Aufgaben? Passen nicht zum Mindset der Continuous-Delivery-Verfechter. Wichtige Usability-Änderungen oder Performance-Verbesserungen warten nicht bis zum nächsten großen Release, sondern werden umgehend in Produktion gebracht. Und falls man Gründe hat, sie kurz darauf abermals zu modifizieren, dann werden auch diese Modifikationen rasch und ohne Verzögerung umgesetzt.

Daraus ergibt sich eine Kultur, die zu gut durchdachten Experimenten einlädt, die allen Beteiligten (und nicht nur den Applikationsentwicklern) Mut macht, einmal etwas auszuprobieren, weil man weiß, dass sich Kurskorrekturen, sofern neue Erkenntnisse diese nahelegen, zügig durchführen lassen.

Continuous Delivery übt dabei auf die Entwickler einen „sanften Zwang“ aus, ihre Software im Hinblick auf ein reibungsloses Deployment zu bauen. Wer nicht nur für die Applikation in einer Testumgebung, sondern auch für deren Überführung ins reale Leben verantwortlich ist, wird bei Architektur und technischen Details, die fürs Deployment wichtig sind, ggf. überlegter vorgehen.

Microservices

Microservices sind mit dem Ziel angetreten, die Komplexität in Softwaresystemen zu verringern. Durch ein „Zuschneiden“ der Software in kleinere „Happen“ lasse sich die inhärente Komplexität verringern, so die Theorie. Damit steht dieser Ansatz ganz in der Tradition der vielen Vorschläge zur Modularisierung von Software, an denen die IT-Geschichte so reich ist (von Objektorientierung über Komponentenorientierung bis hin zu SOA oder der Modularisierung à la OSGi und Jigsaw).

Die oftmals für Komplexitätsprobleme verantwortlichen Abhängigkeiten zwischen Systemteilen werden zwar eliminiert, lassen sich bei Microservices aber im Sinne von APIs lösen: Wenn ich meinen Service ändere, bin ich allen „Nachbar-Services“ gegenüber verpflichtet, mein API konsistent zu halten. Dieses wichtige Ziel muss ich bei all meinen Entwicklungs- und Deployment-Tätigkeiten im Blick behalten, und falls ich einmal gezwungen bin, meine Schnittstellen zu verändern, dann ist es einfacher, alle Betroffenen „Nachbar-Services“ explizit darüber in Kenntnis zu setzen und eine kooperative Planung des Wechsels zu initiieren.

Dass bei einem Microservices-Ansatz kein interner Zwang zur einheitlichen Technologie besteht (der eine Service in Java geschrieben, der andere in Ruby-on-Rails, der dritte in Go in der Cloud …), wird von vielen Experten ebenfalls als Vorteil erachtet; dieser Aspekt soll hier aber nur erwähnt werden, weil er für die DevOps-Perspektive nicht von zentraler Bedeutung ist.

Wichtig zu erwähnen ist, dass Microservices keinesfalls allein als neues Architekturmuster betrachtet werden sollten, das bestehende Architekturen ablöst, um bessere technische Ergebnisse zu erzielen. Microservices implizieren vielmehr einen (neuen) Ansatz für Technologie und Organisation gleichermaßen!

Microservices ergeben Sinn, wenn man daran interessiert ist, gewisse Dinge über die Technologie hinaus anders zu machen, als dies in traditionellen Unternehmens-Umgebungen praktiziert wird. Dazu gehören:

  1. Autonome selbst organisierende Teams, die je für einen (Micro-)Service die volle Verantwortung tragen.
  2. Der Zuschnitt dieser Services erfolgt nicht nach technischen Gesichtspunkten, sondern primär nach fachlichen (was die überaus große Popularität von Domain-Driven Design im Microservices-Kontext erklärt).
  3. Zur Verantwortung der Microservice-Teams gehört auch das bekannte „You build it, you run it“ von Werner Vogels (CEO von Amazon Web Services), d.h. eine Zuständigkeit nicht nur für die Applikationsentwicklung, sondern für den gesamten Lebenszyklus im Sinne von Deployment, Monitoring, Bugfixing, Optimierung, Weiterentwicklung, usw.
  4. Zudem sind solche Microservice-Teams nicht selten crossfunktional aufgestellt – d.h. zusätzlich zu den Applikationsentwicklern sind eventuell auch Operations- / Plattform-Experten an Bord, nicht selten auch Domänen-Experten (Fachleute), Marketiers oder Designer.

Nur solche Organisationen, die mit der Idee von Microservices nicht nur eine technische Neuerung, sondern auch ein Businessziel verfolgen, werden langfristig an Microservices ihre Freude haben.

Cloud

Moderne Cloud-Plattformen sind weit mehr als nur eine Möglichkeit, Applikationen in öffentliche Rechenzentren zu übertragen. Sie bieten vielmehr eine Fülle technischer Services, die unsere herkömmliche Art, Software zu bauen und einzusetzen, in Frage stellen.

Wie macht sich dieses Cloud-Paradigma in der Praxis bemerkbar? Eine Anwendung zu deployen ist in klassischen Umgebungen mit einem stattlichen Aufwand verbunden: Ein Betriebssystem muss gewählt und installiert werden, hinzu kommen Applikationsserver, Datenbank, Benutzer- und Rechtevergabe, Firewallkonfigurion, Tuning, Hardening (Security) und vieles andere mehr. Dazu gilt es, unterschiedliche Versionsstände, Kompatibilitäten und Abhängigkeiten zu managen. Und schließlich folgt die eigentliche Anwendung, die ihrerseits konfiguriert und der gegebenen Produktionsumgebung angepasst werden muss.

Moderne Cloud-Umgebungen, wie etwa Amazon Web Services, Microsoft Azure oder Google Cloud Platform, vereinfachen diesen Prozess deutlich und lassen komplizierte Infrastruktur-Vorbereitungen der klassischen On-Premise-Welt nahezu trivial erscheinen. Datenhaltung, Nutzer- und Zugangsmanagement (Identity), Netzwerke, Management und Monitoring, Skalierung sind in solchen Umgebungen als Services vorhanden, die nur aufgerufen werden müssen und in Sekunden bereit stehen.

Container

Container-Technologien, durch Docker populär geworden, lösen ein lange existierendes Problem der Softwarewelt auf eine ziemlich elegante Weise: Wie lässt sich Software, die in dem einen Systemkontext funktioniert, auf einfache Weise in einem anderen Systemkontext zum Laufen bringen?

Container abstrahieren eine Software von Faktoren wie Betriebssystem-Versionen, Library-Konflikten oder Netzwerk-Topologien, sodass eine „Verschiebung“ einer App von einem Testsystem ins Produktivsystem mit weitaus weniger „Schmerzen“ verbunden ist als bisher.

Was unterscheidet Docker oder CoreOS (um auch die Container-Alternative, die es zu Docker gibt, erwähnt zu haben) dann von herkömmlicher Virtualisierung? Klassische Virtualisierungs-Systeme packen neben der Applikation auch das zugehörige Betriebssystem und weitere Komponenten in ein Paket. Laufen auf einem Rechner z.B. drei Virtualisierungs-Instanzen, muss dieser Rechner zusätzlich zu seinem primären insgesamt drei Betriebssysteme betreiben.

Bei Docker und CoreOS werden nur die Anwendungen plus ausgewählte Bibliotheken virtualisiert, während auf die Dienste des System-Kernel gemeinsam zugegriffen wird. Das führt nicht zuletzt dazu, dass die Startup-Zeit einer klassischen VMware-Instanz eher in Minuten beschrieben wird, während es sich bei Docker um Sekunden im einstelligen Bereich handelt. Diese Eigenschaften von Docker laden geradezu dazu ein, komplexe Anwendungen im Sinne von Microservices in kleinere Portionen aufzuteilen.

Unternehmenskultur

Keiner der genannten Ansätze bricht nun für sich genommen eine Revolution der IT vom Zaun; im Konzert ergeben sie gemeinsam jedoch eine durchaus neue Musik.

Continuous Delivery öffnet Unternehmen neue gedankliche Räume, ihr digitales Business zu gestalten. Die IT kann im Lichte automatisierter hochfrequenter Releases als bewegliches und formbares Medium betrachtet werden und repräsentiert nicht mehr dieses starre Korsett, welches nur unter Einsatz hoher Kosten änderbar war.

Microservices erleichtern solch automatisierte Deployments, weil sie den Umfang und die Komplexität der zu deployenden Artefakte erheblich reduzieren. Zudem unterstützen sie Unternehmen dabei, sich auf ihre Business-Ziele zu fokussieren, indem sie nicht die in der Vergangenheit definierte Software-Infrastruktur über den Zuschnitt und den Fokus von Abteilungen entscheiden lassen, sondern inhaltlich sinnvolle Ziele / Services in den Mittelpunkt stellen.

Crossfunktionale Microservice-Teams versprechen zudem auch, die klassischen Trennungen zwischen Fachabteilung / Marketing / Design / Entwicklung / Operations aufzuheben und somit unterschiedliche Stakeholder zu einer lebendigen interdisziplinären Zusammenarbeit im Sinne des gemeinsamen Produkterfolgs zu ermutigen. Wenn solchermaßen aufgestellte Teams im agilen Geist eine effiziente Kommunikationskultur ohne hemmende Hierarchien pflegen, dann wird auch eine iterative Entwicklung von Produkten entlang der (schwankenden) Kundenbedürfnisse möglich. Eine agile Infrastruktur im Sinne von DevOps kann dann eine ebenso iterative IT bereit stellen.

Bei so einem iterativen Business helfen auf technischer Ebene die Cloud-Plattformen als rein softwarebasierende Infrastruktur sowie die Docker-Container. Sie machen Deployments oder Änderungen an der Infrastruktur zu einem Kinderspiel und haben das Potenzial, das angestammte Image der IT als „Spaßbremse“ bei der Geschäftsentwicklung aus der Welt zu schaffen.

Was ist DevOpsSchlussbemerkung

Nach unserem Verständnis wird modernes DevOps erst unter Berücksichtigung der in diesem Artikel dargestellten Aspekte wirklich wirkungsvoll. Über die gewählten Themen – Continuous Delivery, Microservices, Clouds, Docker, plus Unternehmenskultur — lässt sich möglicherweise kontrovers diskutieren; und gewiss lassen sich weitere Themen nennen, die hier nicht oder nur am Rande erwähnt wurden und deren Bedeutung ebenfalls groß ist.

Auch ist wichtig zu erwähnen, dass nicht zwingend alle Zutaten notwendig sind, um sich im Sinne eines „echten“ DevOps aufzustellen. Ich habe schon von wahren Continuous-Delivery-Wundern gehört, die auf einem einzigen Mega-Monolithen (anstatt auf Microservices) basieren, oder von klugen Microservices-Ansätzen, die ganz ohne Clouds oder Container zurecht kommen …

„Echtes DevOps“ gibt es außerdem so wenig wie es eine verbindliche Definition von DevOps gibt. Dass mit DevOps eine Bewegung beschrieben ist, die uns dazu auffordert, unsere grundlegenden Vorstellungen von IT zu überdenken, soll an dieser Stelle genügen (und natürlich auf unserer DevOpsCon diskutiert werden, die nicht zufällig das Motto „Rethink IT“ mit sich trägt).

Ich freue mich auf die vielen Sessions, Keynotes und Workshops dazu, auf jede Menge spannender Impulse und erhellende Gespräche. Unsere Sprecher verfügen allesamt über handfeste Erfahrungen aus DevOps-Umgebungen, sei es als Infrastruktur-Experte, als Applikationsentwickler in der Cloud, als Transformations-Berater für Unternehmen.

Treffe ich auch Sie auf der DevOpsCon?

 

 

Verwandte Themen:

Geschrieben von
Sebastian Meyen
Sebastian Meyen
Sebastian Meyen ist Chefredakteur des Java Magazins sowie des Eclipse Magazins. Außerdem trägt er die Verantwortung für Programm und Konzept sämtlicher JAX-Konferenzen weltweit. Er begleitet so die Java-Community journalistisch schon fast seit ihren Anfängen. Bevor er zur Software & Support Media GmbH kam, studierte er Philosophie in Frankfurt.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: