Eine widerstandsfähige und hochskalierbare Applications Cloud

So geht Business-Agilität heute

Walid Farag

© Shutterstock / Sergey Nivens

Business-Agilität bedeutet, schneller zu liefern, schneller zu lernen und dadurch rascher zu wachsen. IT-Operations sind ein integraler Bestandteil dieses anspruchsvollen Prozesses.

Eine ausfallsichere und hochskalierbare Cloud-Umgebung für Anwendungen ist die Grundlage moderner Rechenzentren. Allerdings ist die Cloud vom Gesamtkontext nicht isoliert: Am Anfang stehen zunächst die Business-Vision und -Ziele. In diesem Artikel versuchen wir folgende Fragen zu beantworten: Warum Business-Agilität? Und wie implementiert man sie reibungslos in DevOps-Organisationen?

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? As a follow-up to our previous cheat sheet featuring the most important commands and functions, DevOpsCon speaker Michael Hofmann has put together the 8 best practices you should keep in mind when using Istio.

Das Business durch Lean Startup schneller wachsen lassen

Das Grundprinzip von Lean Startup ist, dass jede Idee für die Unternehmensgründung als unbewiesene Hypothese betrachtet werden muss, die erst als sicher gilt, wenn sie empirisch validiert worden ist. Hypothesen, die widerlegt wurden, müssen durch neue ersetzt werden. Erst wenn alle erfolgskritischen Hypothesen validiert worden sind, kann das Startup in die nächste Phase übergehen. Dabei soll die Überprüfung möglichst schnell und kostengünstig erfolgen. (Quelle: Wikipedia)

Die Integration von Lean Startup erlaubt es, nur minimale Investments tätigen zu müssen, solange die Resultate noch nicht evaluiert sind. Das Ziel ist es, schnell herauszufinden, was funktioniert und was nicht.

Abb. 1: Lean Startup

Abb. 1: Lean Startup

Die Performance durch agile Entwicklungsstrategien verbessern

Agilität versetzt Unternehmen in die Lage, Ziele effektiv zu erreichen sowie schnell und reibungslos auf Marktveränderungen reagieren zu können. Hierbei kann man auf zwei einfache Prinzipien vertrauen:

  • Lieferung so oft wie möglich: Man findet schnell heraus, was funktioniert und was nicht. Auf diese Weise basieren die Entscheidungen nicht auf Annahmen sondern auf Daten. Die Software kann unter Umständen mehrfach am Tag geliefert werden. In anderen Fällen kann sie aber auch nur einmal alle zwei bis drei Wochen in Produktion gehen. In allen Fällen gilt: Damit das Deployment einfach bleibt, müssen kleine Releases/Packages/Services geliefert werden.
  • Entkopplung der Software-Komponenten. Dies versetzt einen in die Lage, verschiedene Teile eines Softwareprodukts unabhängig voneinander bereitzustellen.
Abb. 2: Bounded Contexts

Abb. 2: Bounded Contexts

Abbildung 1 präsentiert die High-Level-Architektur eines Internet-Shopping-Portals. Jede Subdomain (zum Beispiel Shipment oder Credit Worthiness) wird durch einen Software-Service repräsentiert. Verwandte Subdomains werden innnerhalb von Kontextgrenzen logisch gruppiert. Dies ist bei der späteren Planung und Zuordnung der verantwortlichen Entwicklungsteams hilfreich.

Die Services sind entkoppelt und werden unabhängig voneinander entwickelt und bereitgestellt. Dadurch sind die Entwicklerteams in der Lage, autonom zu arbeiten. Die Abhängigkeit zwischen ihnen nimmt ab, gleichzeitig steigt die Entwicklungsgeschwindigkeit.

Unterschiedliche Gruppen sollten mit der Koordination der Entwicklung des Interfaces und der Interaktion zwischen Subdomains betraut werden. Da die Services unabhängig voneinander entwickelt werden, muss es ein klares System von semantischer Versionierung geben.

Die Herausforderungen klassischer IT-Operations

Eine dynamische und flexible IT ist der Schlüssel zum Erfolg des gesamten Unternehmens. Allerdings könnten die Herausforderungen der traditionellen Softwareentwicklung und IT-Operations den reibungslosen Ablauf von Entwicklungs- und Operationsprozessen behindern.

Einige Faktoren sind:

  • Deployment und Konfiguration
  • Qualität und Performance
  • Erwartungen an die Verfügbarkeit
  • Nutzung der Infrastruktur
  • Monitoring

Diese Herausforderungen nehmen konstant zu – insbesondere wenn die Anzahl der Applikationen zunimmt und deren Komplexität und Abhängigkeit wächst. Die nächste Generation von IT-Operations braucht einen neuen Ansatz für die Applikationsentwicklung und Operations.

Das Deployment mit DevOps-Strategien beschleunigen

DevOps ist eine Verschmelzung der Begriffe Development (englisch für Entwicklung) und Operations (englisch für Betrieb). DevOps ist eine Softwareentwicklungs-Methode, welche die Kommunikation, Kollaboration, Integration, Automatisierung und die Kooperation von Softwareentwicklern und anderen IT-Fachkräften betont (Quelle: Wikipedia).

Daher ist die Bedeutung von DevOps auch in traditionellen Organisationen gewachsen. Die Methode bietet Entwicklern eine großartige Möglichkeit, gründlich darüber nachzudenken, wie die Applikation im Rahmen von Operations läuft. Ebenso versteht der Bereich IT-Operations die Voraussetzungen und das Design der Applikation deutlich besser.

Was DevOps noch fehlt ist eine Plattform, auf der alle zusammenarbeiten können – unabhängig davon, an welcher Stelle des Software-Lebenszyklus sie sich befinden.

Unser Ziel

Wir haben es uns zur Aufgabe gemacht, die Agilität von Unternehmen reibungsloser zu gestalten. Unsere IT-Operations-Strategie ist es, die Perfomance zu verbessern und Infrastruktur-Kosten einzusparen – ohne dabei die IT-Sicherheit zu schmälern.

Zum Glück stehen uns viele Optionen zur Auswahl, um unser Ziel zu erreichen. Hier sind einige von ihnen – wir werden sie im weiteren Verlauf des Artikels näher betrachten:

  • Standard Delivery Unit
  • Optimierung der Nutzung der Infrastruktur
  • Automatisierung von Deployment und Konfiguration
  • Dynamische Service Discovery
  • Elastic Monitoring
  • Self Service-Modus

Ich bezeichne IT-Operations mit den oben genannten Möglichkeiten gerne als „Modern Datacenter“. Ich hörte diesen Begriff einmal von Mitchell Hashimoto, dem Kopf hinter leistungsstarken Open-Source-Produkten wie zum Beispiel Consul (ein Service-Discovery- und Konfigurations-Tool).

Ein Modern Datacenter verfügt über eine robuste und hochskalierbare Applications Cloud. Eine solche Cloud stellt einen Katalysator für jede moderne IT- und DevOps-Organisation dar.

Das Modern Datacenter

Der nächste Teil des Artikels erörtert, wie man die oben genannten Möglichkeiten mithilfe bewährter Technologien – die auch von Internet-Giganten genutzt werden – umsetzt.

Docker

Docker ist eine erstaunliche Technologie. Sie versetzt einen in die Lage, eine gesamte Applikation samt Konfiguration in einen Container zu packen. Ähnlich wie bei den Containern eines Containerschiffs müssen die IT-Operations-Teams nicht wissen, was sich in ihrem Inneren befindet. Im Gegenteil müssen sie nur deren Äußeres kennen: So zum Beispiel den CPU- und Speicherbedarf der Containeranwendung.

Abb. 3: Container Konzept

Abb. 3: Container Konzept

Die Applikation in einen Container zu packen, vereinfacht und beschleunigt die Entwicklung. Der Technologie-Stack der Applikation ist für IT-Operations nicht mehr relevant. Java-, PHP-, MySQL- und Perl-Applikationen werden einfach innerhalb des Containers bereitgestellt. Es liegt in der Verantwortung der Entwickler, vorkonfigurierte Docker-Images zu liefern, die später als Container laufen.

IT-Operations-Teams haben die Aufgabe, Standard-Deployment-Skripte zu schreiben, die für alle Container (Applikationen) valide sind. Das Skript startet die Container – das ist alles!

Ein weiteres wichtiges Feature ist die Isolation. Applikationen, die in Containern laufen, sind von anderen Containern isoliert. Verschiedene Applikationen können dann die gleichen Ports benutzen. Auf diese Weise kann man Zeit bei der Konfiguration einsparen und menschliche Fehler minimieren. Es versetzt einen außerdem in die Lage, verschiedenen Versionen der Applikationen zur selben Zeit laufen zu lassen oder zwischen ihnen zu wechseln.

Docker-Layer

Abb. 4: Docker Ebenen

Abb. 4: Docker Ebenen

Docker bietet noch ein weiteres nettes Feature: Ein Docker-Image wird physikalisch als Layer gespeichert. Zum Beispiel kannst man ein Image mit einem Betriebssystem wie Ubuntu oder Red Hat erstellen. Dieser Layer kann wiederverwendet werden. Ein weiterer Layer kann obendrauf installiert werden – so zum Beispiel ein Applikations-, Web- oder Mail-Server. In diesem Fall wird der Layer des Betriebssystems nicht modifiziert. Der obere Layer liegt einfach darüber.

Wenn man einen Docker-Container von einem Docker-Image laufen lässt, wird der Container auf einem neuen Layer gestartet. Auf diesem werden die Logdateien und die Run-Time-Daten gesichert. Die Images darunter bleiben unverändert. Sollte der Container aus irgendeinem Grund nicht ordentlich funktionieren, muss man ihn nur stoppen, löschen und auf Basis des Originalzustands einen neuen Container starten.

Dieses Feature verspricht einen schnellen, konsistenten und standardisierten Wiederherstellungsprozess – mit Sicherheit aber spart es Zeit in der Produktion.

Mesos

Mesos ist ein großartiges Tool, das Ressourcen wie CPUs oder Speicher von physikalischen oder virtuellen Maschinen abstrahiert (Quelle: Apache Mesos).

Abb. 5: Mesos wandelt Server-Fleets in Ressourcen um

Abb. 5: Mesos wandelt Server-Fleets in Ressourcen um

Mesos versetzt einen in die Lage, eine Vielzahl von Servern (virtuelle und physikalische Maschinen) in einen Ressourcen-Pool zu verwandeln. Unabhängig davon, ob sie im eigenen Rechenzentrum oder in einer Public Cloud laufen, können IT-Operations die Applikationen über Mesos starten.

Durch die von Mesos gelieferte Abstraktion werden für Anwendungen keine dedizierten Maschinen mehr benötigt.

Zudem unterstützt Mesos auch Docker. So kann man beispielsweise bestimmen, dass eine Container-Applikation automatisch dort in der Cloud startet, wo die benötigten Ressourcen vorhanden sind.

Wenn eine Maschine oder ein Rack abstürzt, können die Applikationen in anderen Maschinen automatisch neu gestartet werden.

Eine kurze Zusammenfassung der Vorteile von Mesos:

  • IT-Operations müssen sich nicht länger mit einzelnen Maschinen, sondern nur mit Ressourcen auseinandersetzen
  • Standardisierte Installations-Templates (Master und Slave). Es sind keine speziellen Installationsverfahren mehr nötig
  • Schnelle Installation und Konfiguration
  • Widerstandsfähigkeit (Elastizität)
  • Infrastrukturskalierbarkeit Out-of-the-box (einfach neue Mesos-Slaves hinzufügen)

Marathon

Marathon ist ein Apache-Mesos-Framework für lang laufende Applikationen. Wenn man Mesos als Kernel eines Rechenzentrums verwendet, ist Marathon der „init“- oder „upstart“-Deamon. Marathon bietet eine REST API zum Starten, Stoppen und Skalieren von Applikationen. Wie Mesos kann Marathon ebenfalls mehrere Kopien gleichzeitig verwalten. Der Zustand der laufenden Tasks wird in der Mesos-State-Abstraktion gespeichert (Quelle: Apache Marathon).

Abb. 6: Marathon betreibt Apps durch Mesos

Abb. 6: Marathon betreibt Apps durch Mesos

Marathon bietet die folgenden Vorteile:

  • Automatisiertes Hochfahren in der Cloud
  • Applikations-Skalierbarkeit
  • Applikations-Fehlertoleranz Out-of-the-box
  • Rolling Upgrades

Consul

Hunderte oder gar tausende voneinander abhängige Applikationen in der Cloud laufen zu lassen, ist eine große Herausforderung – vor allem in Bezug auf die Konfiguration, das Monitoring und die Pflege.

Consul ist ein Tool für die Discovery und die Konfiguration der Services einer Infrastruktur.

Abb. 7: Service-Erforschung mit Consul

Abb. 7: Service Discovery mit Consul

Wenn zum Beispiel ein Datenbankserver in der Cloud durch Marathon oder Mesos gestartet wird, registriert Consul seine Location. Daraufhin kann sich ein Web-Service oder ein Portal auf einfache Art und Weise mit seiner Datenbank verbinden – und zwar durch die Konfiguration der Location des Datenbankservers während der Laufzeit.

Consul bietet noch viele weitere Vorteile:

  • Service-Discovery und Key/Value-Store für dynamische Konfigurationen
  • Dynamisches Monitoring
  • Multi-Rechenzentren-Support
  • RESTful API
  • DNS-Interface

Elastic Monitoring

Aufgrund des Levels an Komplexität und Automatisierung ist es nicht sinnvoll, sich auf klassische Monitoring- und Troubleshooting-Methoden und -Werkzeuge zu verlassen.

Elastic Search ist eine Sammlung innovativer und skalierbarer Produkte, welche die Möglichkeit bieten, die Logdateien einer Applikation zu transportieren und zu filtern. Natürlich ist dieser Vorgang voll konfigurierbar, das DevOps-Team kann also entscheiden, was wie überwacht werden soll.

Abb. 8: Monitoring mit Elastic Search

Abb. 8: Monitoring mit Elastic Search

Mit Logstash werden alle Logs an einen zentralen Service gesendet. Daraufhin werden die Logs gesichert und indexiert. Dieser Schritt ist essentiell, um nach verwandten und komplexen Events und Ereignissen im Rechenzentrum zu suchen.

Elastic Search bietet eine konfigurierbares User Interface namens Kibana. Im Unterschied zu klassischen Vorgehensweisen kann das DevOps-Team auf diese Weise Events besser überwachen und nach Lösungen suchen.

Elastic Search unterstützt Out-of-the-box die folgenden Features:

  • Verteilte Volltext-Suchmaschine
  • Skalierbare Architektur
  • Multimandantenfähig
  • RESTful-Web-Interface

Sicherheit: Bedrohungs- und Verteidigungs-Modelle

Als Informationssicherheit bezeichnet man Eigenschaften von informationsverarbeitenden und -lagernden (technischen oder nicht-technischen) Systemen, die die Schutzziele Vertraulichkeit, Verfügbarkeit und Integrität sicherstellen. Informationssicherheit dient dem Schutz vor Gefahren bzw. Bedrohungen, der Vermeidung von wirtschaftlichen Schäden und der Minimierung von Risiken (Quelle: Wikipedia).

Die Ziele, die wir erreichen wollen, sind:

  • Vertraulichkeit
  • Integrität (Erhalt und Sicherung der Fehlerfreiheit und Vollständigkeit von Daten über ihren gesamten Lebenszyklus hinweg). Dies bedeutet, dass die Daten nicht auf nichtautorisierte oder unerkannte Weise modifiziert werden können.

Der Versuch, mögliche Angriffe zu definieren und ausfindig zu machen, ist von Situation zu Situation verschieden. Es gibt also keine Patentlösung. Das DevOps-Team muss daher die Sicherheitsmaßnahmen auf das jeweilige Bedrohungsmodell zuschneiden.

Wir konzentrieren uns auf die genannten Tools und die folgenden möglichen Gefahren:

  • Nicht-Clustermitglieder greifen auf Daten zu
  • Manipulation des Clusterzustands
  • Fälschung der Service-Registrierung
  • Denial-of-Service gegen einen Cluster (Node/Agent)

Die oben genannten Tools bieten Out-of-the-box spezifische, konfigurationsbasierte Abwehrlösungen. Sie zielen auf:

  • Vertraulichkeit durch Verschlüsselung
  • Authentifizierung durch Schlüssel/Zertifikat für jeden Node/Agent
  • Autorisierung durch Zugriffssteuerungslisten

Hinzu kommt, dass klassische Sicherheitszonen (Admin, Private und Public) noch andere Abwehrmaßnahmen gegen Sicherheitsbedrohungen bieten.

Rollen in DevOps-Teams der nächsten Generation

Diese Architektur unterstützt einen weiteren Faktor, der die Agilität fördert. Infrastrukturteams werden sich auf die Installation und Wartung der in diesem Artikel beschriebenen Plattform konzentrieren. Sie erstellen APIs für Entwicklerteams.

Die Entwickler kümmern sich um die Details der Applikation. Darüber hinaus können sie die Applikationen selbstständig bereitstellen, zum Laufen bringen und überwachen. Entwicklerteams sind dann für das reibungslose Funktionieren ihrer Applikation verantwortlich.

Diese klare Einteilung der unterschiedlichen Aufgabengebiete sollte für eine noch höhere Geschwindigkeit, bessere Qualität und niedrigere Kosten sorgen.

Orchestrierung und Skalierung von Agilität

Im Laufe der Jahre bin ich zu dem Entschluss gekommen, dass die Business-Agilität nur mittels eines 360-Grad-Konzepts richtig umgesetzt werden kann. Die Unternehmen müssen mit der IT synchronisiert werden, damit Business-Vision und -Ziele schneller und sicherer erreicht werden können.

Abb. 9: Agilität skalieren mit autonomen Teams und Cloud-Ready-Architektur

Abb. 9: Agilität skalieren mit autonomen Teams und Cloud-Ready-Architektur

Agilität ist nicht nur eine Methodologie wie zum Beispiel Scrum, LeSS (Large Scale Scrum) oder Kanaban. Es ist vielmehr eine Ansammlung von Werten, Prinzipien und Praktiken. Im vorliegenden Artikel haben wir uns auf den Support durch eine Cloud-Ready-Architektur konzentriert. Sie versetzt uns in die Lage, Agilität zu orchestrieren und zu skalieren – Abbildung 9 verdeutlicht diese Idee.

Aufmacherbild: Young pretty businesswoman via Shutterstock / Urheberrecht: Sergey Nivens

Verwandte Themen:

Geschrieben von
Walid Farag
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: