Es ist noch nicht so lange her, da wurde der Server-Teil einer Softwarelösung auf einem physischen Server installiert, der Client-Teil auf einem Desktop-PC. Dann kamen Virtualisierungstechniken, die für mehrere virtuelle Server auf einem physischen sorgten. Weiter ging es mit Thin-Clients, Citrix und Remote-Desktop. Nun steht uns mit der Cloud eine Entwicklung bevor, die dieses Prinzip noch weitertreibt: Die Software-Lösung ist nicht mehr (oder nicht mehr zwingend) auf (eigenen) virtuellen Servern installiert, sondern irgendwo in einem Rechenzentrum, der Mitarbeiter nutzt sie auf irgendeinem seiner Geräte, von irgendwo und vielleicht sogar als „Software-as-a-Service“.
Nicht nur Cloud-Apps betroffen
Eine Software-Lösung in dieser Art zu betreiben, ist nicht nur eine Herausforderung für die IT-Abteilung oder den Infrastruktur-Partner, sondern stellt auch neue Anforderungen an die Softwarelösung selber und somit an deren Hersteller. Cloud-Applikationen definieren sich aus meiner Sicht durch folgende Kriterien (nicht abschliessend):
- Verfügbarkeit: 7x24h, auf der ganzen Welt
- Skalierbarkeit: Machen sich Performance-Einbussen bemerkbar, müssen zusätzliche Ressourcen bereitgestellt werden können
- Flexibilität: Updates müssen einfach und schnell zur Verfügung gestellt werden können
Ein Beispiel einer «kleinen» solchen Applikation ist unser Tipp-Spiel. Wir betreiben das Tipp-Spiel auf der Infrastruktur von Microsoft Azure. Dort sind die Konfigurationsmöglichkeiten bzgl. der genannten Kriterien immens: Zusätzliche virtuelle Server oder Web-Endpunkte, um zu skalieren oder die Verfügbarkeit zu erhöhen, stärkere Server innerhalb von Minuten, um zusätzliche Last zu bewältigen oder die automatische Installation in dieser Infrastruktur, ausgelöst von unserer Test- oder der (internen) Entwicklungsumgebung.
Diese Vorteile auch ohne Cloud nutzen
Damit all dies möglich ist, müssen die einzelnen Teile der Applikation ihre Aufgabe selbständig ausführen und über klar definierte Schnittstellen kommunizieren. Ich spreche von Teilen wie:
- Datenbank-Systeme
- Server-Dienste
- API-Schnittstellen
- Webseiten/-Applikationen
- Desktop-Programme oder mobile Apps
Cloud-Applikationen setzen diese Aufteilung zwingend voraus. Doch wieso sollte man sie nicht auch als Vorteil und Chance für lokale (OnPremise) Applikationen nutzen, auch wenn das keine «richtigen» Cloud-Applikationen sind? Schliesslich soll auch intern die Verfügbarkeit und Skalierbarkeit möglichst hoch sein und die Updates möglichst wenig Aufwand und Ausfallzeit bedeuten.
Rein in einen (Docker-)Container
Hier kommt die «Containerisierung» ins Spiel. Was genau ein Container ist, wird in diesem Video gut erklärt (Englisch):
Die zu Beginn angesprochene Virtualisierung wird also noch weitergetrieben, in dem einige oder sogar alle Teile der Software-Lösung in verschiedenen Containern virtualisiert werden. Jeder Container definiert sich aus seinem Inhalt und seinen Schnittstellen zu anderen Containern. Ein DB-Container beinhaltet die Datenbank und ermöglicht den Zugriff über einen Port. Dasselbe gilt für die Server-Dienste (z.B. Windows-Services) oder ein Webserver, der ebenfalls innerhalb eines Containers läuft und die Webseite(n) bereitstellt. Jeder Container ist durch Konfigurationsdateien mit den anderen verknüpft (DB ist in Container A, der Webserver-Container weiss, dass er den Service in Container B erreicht). Eine solche Container-Technologie ist Docker. Beispiel-Konfigurationen solcher Docker-Container können im Internet heruntergeladen und für den eigenen Gebrauch angepasst werden. Wo diese Container genau ausgeführt werden und wie viele von denen es gibt, spielt keine Rolle mehr. Alle auf einem Test-Notebook, auf verschiedenen internen Servern oder verteilt in Cloud und lokal ist grundsätzlich egal.
Und warum wünsche ich mir das von meinem Software-Hersteller?
Wie erwähnt ermöglicht diese Architektur erhöhte Verfügbarkeit, Skalierbarkeit und Flexibilität. Der Hersteller liefert dir nur noch den Container-Inhalt (also die Teile der Applikation an sich, sog. «Container Images»). Wie und wo du diese Artefakte installierst bzw. betreibst wird nur noch über «selbstbeschreibende» Konfigurationsdateien festgehalten. Eine zusätzliche Test-Umgebung bereitstellen? Einfach Konfigurationsdateien der Produktiv-Umgebung kopieren, anpassen, starten, fertig. Da es Textdateien sind braucht es kein zusätzliches Programm. Ein weiterer Benefit dadurch: Sie können zusätzlich versioniert und die Installation/Verteilung vollständig automatisiert werden. Das Resultat ist klar: Weniger Installationsaufwand und weniger Ausfall bei Release-Wechseln und dadurch auch häufigere Updates.
Erfüllt Leuchter mir diesen Wunsch?
Ja gerne, wenn möglich :-). Melde dich in der Kommentarspalte, per Mail oder per Telefon, wenn du konkrete Informationen zu deiner Applikation wünschst.
