© Ekaphon maneechot/Shutterstock.com
Richtig skalieren: Einfach nur mehr reicht nicht

Entwicklung und Betrieb skalierbarer Architektur


Nachdem im ersten Teil des Artikels anhand von fünf Prinzipien vorgestellt wurde, wie sich strukturelle Engpässe innerhalb einer Architektur umgehen lassen (Business Technology 2.2014 [1]), beleuchtet dieser zweite Teil, welche Prinzipien für den Entwicklungsprozess und den Betrieb einer skalierbaren Architektur hilfreich sein können.

Im ersten Beitrag wurden vor allem Ansätze zur horizontalen Skalierung betrachtet. Auf Hardwareebene verspricht das Hinzufügen von Standardkomponenten im Idealfall eine proportional zu den Lastanforderungen passende Kostenentwicklung. Zusätzlich wird eine Skalierung im laufenden Betrieb ermöglicht. In den Prinzipien 1 bis 5 wurden dazu passende gesamtarchitektonische Ansätze vorgestellt, u. a. die Lastverteilung durch Sharding [1], die Zerlegung des Systems in funktional getrennte Dienste oder die Verwendung eines asynchronen, eventgetriebenen Programmiermodells. Was bedeuten diese Entscheidungen für den Entwicklungsprozess und den Betrieb?

Horizontal skalierende Systeme benötigen für jeden Skalierungsschritt infrastrukturelle Ressourcen. Aus Effizienzgründen kommt dabei einer elastischen Ressourcenbereitstellung im Bedarfsfall eine steigende Bedeutung zu, gegenüber einem reinen Vorhalten von Überkapazität.

Das Einspielen neuer Softwarereleases kann bei einem System mit hohen Anforderungen an die Skalierbarkeit ebenfalls eine Herausforderung darstellen. Je nach Anwendungsfall und damit verknüpften Verfügbarkeitsanforderungen können Wartungsfenster zu selten oder Schwachlastphasen zu kurz für eine Aktualisierung des gesamten Systems sein. Gleichzeitig ist bei horizontaler Skalierung eine steigende Anzahl an Dienstinstanzen zu aktualisieren. Diese bei gleichbleibender Personaldecke zu pflegen, ist eine weitere typische Herausforderung.

Im Zusammenhang mit einer an die Geschäftserfordernisse angepassten Reaktionsgeschwindigkeit werden Mechanismen notwendig, um das System kosteneffizient zu skalieren, die an die Stelle eines reaktiven Kapazitätsmanagements und dem Vorhalten von hohen Überkapazitäten treten (Abb. 1).

Die im Folgenden beschriebenen Prinzipien zeigen Lösungsoptionen für die dargestellten Herausforderungen auf und können unabhängig voneinander oder aufeinander aufbauend genutzt werden.

neudert_skalierbar_1.tif_fmt1.jpgAbb. 1: Vorhalten von Kapazität erzeugt Kosten ohne Nutzen

Prinzip 6: Wahl einer geeigneten Betriebsplattform

Ein besonderes Augenmerk gilt der Auswahl einer geeigneten Betriebsplattform. Diese sollte den heutigen und zukünftigen Anforderungen genügen und insbesondere bei Aufwand und Kosten möglichst linear skalieren. Die Möglichkeit der elastischen Zuteilung von Compute-, Network- und Storage-Ressourcen ist hierbei von zentraler Bedeutung. Die angestrebte Lösung sollte eine Steuerungsfunktionalität über die reine Compute-Ebene hinaus anbieten, selbst wenn diese nicht sofort in vollem Umfang genutzt wird, da der Zeitraum für Auswahl und Migration einer Betriebsplattform typischerweise den Veränderungshorizont der Geschäftsanforderungen übersteigt.

Ein Großteil der heute verfügbaren Systeme und Lösungen bietet bereits die Möglichkeit einer automatisierbaren Ansteuerung. Dabei reicht die Bandbreite von der Kickstart-Installation bereits verbauter Standby-Hardware über einfache Virtualisierungslösungen, die per Skripte gesteuert werden bis zu Cloud-Computing-Plattformen, die zur Ansteuerung der Ressourcen und Auswertung der Zustände über eine zentrale API-Schnittstelle verfügen.

Nach der mittlerweile als Standard etablierten Virtualisierung der Compute-Ressourcen stellt insbesondere die Automatisierung von Netzwerkkomponenten wie Firewalls und Load Balancern einen der nächsten Schritte dar, um Bereitstellungszeiten zu verkürzen. Weiterhin werden dadurch die Abstimmungen mit dem Betriebsdienstleiter für Standardänderungen vereinfacht bzw. entfallen ganz.

Bei der Auswahl einer geeigneten Plattform sind außerdem die Anforderungen hinsichtlich Datenschutz und -sicherheit zu berücksichtigen. Sie bestimmen maßgeblich, ob entweder eine dediziert betriebene physische Umgebung mit einfacher Virtualisierung (bzw. eine Private Cloud), eine mit anderen Kunden gemeinsam genutzte Public Cloud oder mit der Hybrid Cloud ein Mischmodell gewählt wird.

Alle angeführten Modelle erfordern mindestens eine Auseinandersetzung mit dem Betriebssystem und den darauf betriebenen Softwareablaufumgebungen, sodass dieses Know-how idealerweise intern vorgehalten wird. Einen Schritt weiter geht der Platform-as-a-Service-(PaaS-)Ansatz, bei dem der Betriebsdienstleister eine standardisierte Softwareablaufumgebung zur Verfügung stellt. Hierbei kann sich die IT primär auf die eigentliche Softwareentwicklung konzentrieren. Dies setzt allerdings die Vereinbarkeit mit der einhergehenden Homogenisierung der Betriebsplattform voraus und schränkt die Wahlmöglichkeiten auf die am Markt als PaaS-Lösungen angebotenen Softwareablaufumgebungen ein.

Prinzip 7: Festlegen einer passenden Delivery-Strategie

Ein weiterer Baustein, um eine bedarfs...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang