Gerade im Bereich der Line-of-Business-Anwendungen, die die kaufmännischen und organisatorischen Prozesse von Unternehmen und Behörden unterstützen, ist nach wie vor zu beobachten, dass die Cloud ein eher untergeordnetes Thema ist und weiterhin stark auf eigene Rechenzentren mit vollen Zugriff auf die Server gesetzt wird. Insofern ist auch die Entwicklung für die Cloud für viele noch kein ganz akutes Thema.

Wir beschäftigen uns mittlerweile seit 2011 mit der Entwicklung von Software für die Cloud und haben seitdem unsere Web-Anwendungen in die Microsoft Azure-Cloud umgezogen. Ganz klar ist: die Cloud erfindet nicht alles neu; vielmehr rückt sie Bereiche in den Fokus, die bei der Entwicklung von on-premise-Anwendungen gerne außer Acht gelassen werden. Bezieht man diese Aspekte jedoch bei der Entwicklung ein, so wird man mit einer Anwendung belohnt, die in vielen Bereichen wesentlich besser handzuhaben und deutlich zukunftssicherer ist.

Infrastruktur wird für Entwickler wichtiger

Wer sich schon einmal auf eine Zertifizierung für die Cloud-Entwicklung vorbereitet hat, der macht unweigerlich die Beobachtung, dass der Großteil des vermittelten Wissens im Infrastruktur-Bereich angesiedelt ist. Ganz im Sinne des DevOps-Mindsets werden bei Cloud-Projekten Infrastruktur-Entscheidungen frühzeitig getroffen, idealerweise aber so, dass eine spätere Anpassung einfach möglich ist.

In on-premise-Projekten ist die Haltung „Wir entwickeln jetzt einmal und teilen dem Operations-Team am Schluss mit, was wir brauchen.“ Leider noch viel zu oft anzutreffen. Zugleich haben die Entwickler mitunter die Hoheit über die Testserver und passen diese während der Entwicklungszeit nach Gutdünken an. Dies führt gegen Projektende oft zu starken Kopfschmerzen, weil während der Entwicklungszeit Infrastruktur-Entscheidungen getroffen wurden, die das Operations-Team – aus guten Gründen – nicht mittragen kann.

In einem Cloud-Projekt hingegen sind die Optionen je nach gewähltem Modell bereits während der Entwicklungszeit deutlich eingeschränkt. Hat man bei Infrastructure-as-a-Service (IaaS) noch weitreichende Möglichkeiten, so sind diese bei Platform-as-a-Service (PaaS) und noch stärker bei Software-as-a-Service (SaaS) auf einen klar standardisierten Satz eingeschränkt.

In einer On-Premise-Umgebung ist das Operations-Team die Instanz, die die Entwickler durch Knowhow unterstützen kann, die Leitlinien bereits während der Entwicklungsphase einzuhalten. Das Operations-Team braucht eine feste Stimme und sollte idealerweise bereits die Deployments auf den Testumgebungen vornehmen. Alle Änderungen auf diesen Systemen sollten mit dem Operations-Team abgeklärt sein, um Überraschungen vorzubeugen. Dies geht Hand-in-Hand mit der DevOps-Philosophie, nach der die Kombination von Dev und Ops in einem Team den Grundstein für schnelle, zuverlässige und häufige Deployments legt.

Cattle not pets und die Auswirkung auf Deployments

Im Bereich Cloud und DevOps wird oft von der Metapher Cattle not pets, zu deutsch „Vieh nicht Haustiere“ gesprochen. Diese bringt einen wesentlichen Unterschied zwischen on-premise-Rechenzentren und der Cloud bildlich auf den Punkt: jeder kennt diese Umgebungen, in denen Server über Jahre laufen und zu festen Mitgliedern des Entwicklungsteams werden. Über die Jahre werden sie immer wieder durch liebevolle, persönlich vorgenommene und auf den einzelnen Server und dessen Bedürfnisse optimierte Streicheleinheiten bei Laune gehalten. Alles funktioniert zwar im Großen und Ganzen, aber keiner kann mehr sagen, welcher Server welchen Zustand aufweist und ob dieser der gleiche ist wie der der restlichen Server in der Farm.

Der Verlust eines derartigen Servers führt zu einer großen Krise und das Aufsetzen eines neuen Servers, der genauso gut läuft, ist ein langer, wenig standardisierter Weg. Es kommt keinem Teammitglied in den Sinn, den Server aus vermeintlich unwichtigen Gründen wie einer neuen Betriebssystemgeneration neu aufzusetzen oder zusätzlich einen weiteren Server in Betrieb zu nehmen. So veraltet die Umgebung Schritt für Schritt, bis die Anwendung im Extremfall nicht mehr auf modernen Umgebungen lauffähig ist.

Der ganze Umgang ähnelt dem mit einem liebgewonnenen Haustier, das als Familienmitglied akzeptiert ist und zu dem eine starke emotionale Bindung besteht. Der Begriff Cattle hingegen beschreibt den Umgang eines Bauern mit seiner Viehherde. Auch dieser ist (besonders in Abgrenzung zur Massentierhaltung) respektvoll, aber eher professionell geprägt – schließlich verdient der Bauer seinen Lebensunterhalt mit der Herde. Das Aufnehmen eines neuen Tieres in die Herde ist ein eingespielter Prozess. Ebenso ist es kein herausragendes Ereignis, wenn ein Tier die Herde – aus welchen Gründen auch immer – verlässt.

In Cloud-Projekten ist es allen Beteiligten von vorne herein klar, dass die darunterliegende Hardware, dass sich Betriebssysteme und viele weitere Umgebungsvariablen ändern können – und das mitunter auch aufgrund von Entscheidungen, die der Cloud-Provider trifft und nicht man selbst. Das Aufsetzen neuer Umgebungen ist also daily business, das durch Scripts und Automatisierung einfach von statten geht.

Auch in on-premise-Projekten sollten diese Vorgänge so stark wie möglich automatisiert und auch immer wieder geübt werden. Der Aufwand, der hierdurch entsteht wird zwar oft gescheut. Bei genauerer Betrachtung liegt aber auf der Hand, dass der Nutzen, der durch häufige Deployments und dadurch die Möglichkeit zu früherem Feedback weitaus größer ist. Auch ist klar, dass dem Chaos, das andernfalls durch einen Systemausfall entsteht, gleichzeitig durch derartige Vorkehrungen entgegengewirkt werden kann.

Skalierbarkeit ist wichtig

Eine der großen Stärken der Cloud ist die bessere Skalierbarkeit der Anwendungen. Dieses Thema wird in on-premise-Umgebungen oft vernachlässigt, weil man sich zu sehr darauf verlässt, dass die Infrastruktur der Anwendung über die Zeit konstant bleibt. Neben dem offensichtlichen Vorteil, dass den Anwendern durch Skalierbarkeit eine bessere Performance des Systems geboten werden kann, verführt das Vernachlässigen der Skalierbarkeit jedoch auch zu schlechten Entscheidungen im Bereich der Anwendungsarchitektur.

So werden mitunter ungeeignete Caching-Mechanismen genutzt oder viel zu viele Daten in Session-Variablen abgelegt, weil die Implementierung einfacher ist und in einer Einzelserver-Umgebung funktioniert. Damit macht man das Wachstum der Anwendung jedoch unnötig kompliziert und verliert ganz deutlich an Flexibilität. Der Aufwand zur Planung der Skalierbarkeit ist oft nicht besonders hoch, wird aber ohne weiteres von dem übertroffen, wenn die Skalierbarkeit nachträglich eingezogen werden muss. Deshalb sollte die Skalierbarkeit auch in on-premise-Projekten von Anfang an eine Rolle spielen. So sind auch diese flexibel genug für weiteres Wachstum und größere Umgebungen.

Detaillierte Betrachtung der Persistenz

In on-premise-Projekten sind Fragen zur Datenpersistenz oft auf die eingesetzte Datenbank beschränkt. Zu selbstverständlich ist, dass die Server ein Dateisystem mitbringen, auf dem Daten dauerhaft abgelegt werden können. Die geringe Aufmerksamkeit, die diese Fragen erhalten, führt oft dazu, dass Daten allzu sorglos im Dateisystem abgelegt werden. Es muss keine neue Infrastrukturkomponente aufgesetzt werden und so kann jeder Entwickler Daten ablegen wo er oder sie es für richtig hält. Dies führt zu Wildwuchs und mit ausreichender Laufzeit des Projekts oft dazu, dass keiner mehr weiß, welche Dateisystemstrukturen eingerichtet werden müssen. Kommt dann noch hinzu, dass auf den Testumgebungen zu freigebig mit Administratorrechten gearbeitet wird, ist der Nährboden für schwierige Deployments bereitet.

Im Gegensatz dazu sind in der Cloud die Compute-Bereiche, in denen eine Anwendung ausgeführt wird und deren Infrastruktur sich immer wieder ändern kann und die Storage-Bereiche klar getrennt. Daten, die im Compute-Bereich abgelegt sind, sind in der Regel flüchtig. Daher werden die Persistenz-Entscheidungen wesentlich bewusster getroffen.

Dies betrifft nicht nur die klassischen Anwendungsdaten, sondern beispielsweise auch die Logs, die zur Fehleranalyse dienen. Bewusste Entscheidungen können natürlich auch dazu führen, dass Daten wirklich nur temporär benötigt werden und dass deren Verlust daher vom System kompensiert wird.

Während on-premise die Möglichkeiten sich oft im Bereich Datenbank und Dateisystem abspielen, so gibt es in der Cloud außerdem wesentlich mehr Optionen, die ins Auge gefasst werden können. Allein aus der Betrachtung dieser Optionen kann man wesentliche Schlüsse für on-premise-Anwendungen ziehen und Hinterfragen, ob Datenbank und Dateisystem wirklich die einzigen Möglichkeiten sind. Viele der Cloud-Möglichkeiten können auch on-premise eingesetzt werden und beispielsweise die Performance erhöhen.

Für Ressourcen gilt: Sharing is caring

Während on-premise-Anwendungen oft auf dedizierter Hardware laufen, ist in der Cloud das Teilen von Hardware gang und gäbe. Auch aus Kostengründen ist es sinnvoll, Cloud-Anwendungen möglichst ressourcenschonend umzusetzen, so dass möglichst kleine Instanzen bzw. Modelle genutzt werden können. Hardware, die es nach Specs mit gängigen on-premise-Server aufnehmen kann, ist in der Cloud nun mal nicht günstig.

Oft ist gerade bei neu angeschaffter Hardware in on-premise-Projekten eine relativ geringe Sensibilität für sparsamen Ressourceneinsatz festzustellen, weil man ja den neuesten Server mit so-und-so-vielen Cores und beeindruckendem RAM zur Verfügung hat. Sparsamkeit ist jedoch dann von Vorteil, wenn eine Anwendung Probleme im Bereich der Skalierbarkeit hat und die vertikale Skalierung auf einem Server die einzige Option ist. Je sparsamer eine Anwendung ist, desto mehr Benutzeranfragen können pro Server bedient werden.

Das betrifft beispielsweise Bereiche wie den Umgang mit dem Arbeitsspeicher, aber auch die Betrachtung, welche Aktionen innerhalb eines Requests ausgeführt werden. Unter Umständen ist es sinnvoll, einige Aktionen auszulagern und so dafür zu sorgen, dass die Request-Laufzeiten kurz sind. Auch können clientseitig ausgeführte Berechnungen dafür sorgen, dass die Last am Server zurückgeht und die Benutzer die Anwendung als sehr flüssig erleben.

Zusammenfassung

In der folgenden Liste haben wir die wichtigsten Punkte noch einmal zusammengestellt:

• Beziehen Sie das Operations-Team frühzeitig in alle Entscheidungen ein, die das Deployment und die Systemvoraussetzungen betreffen.

• Behandeln Sie Server als Cattle und weniger als Pets. Wie wäre es, in der nächsten Iteration eine neue Testumgebung aufzusetzen und den Vorgang in diesem Atemzug gleich zu automatisieren?

• Denken Sie heute schon daran, dass Ihre Anwendung wachsen kann und rücken Sie die Skalierbarkeit in den Fokus.

• Verschaffen Sie sich ein Bild darüber, welche Daten für Ihre Anwendung persistent notwendig sind. Welche Alternativen gibt es? Wie kommt die Anwendung damit zurecht, wenn Daten fehlen?

• Achten Sie auf sparsame Verwendung der Ressourcen und lagern Sie langlaufende Operationen in Hintergrundprozesse aus.

Es gibt also einiges im Bereich der Cloud-Entwicklung, das auch bei der Entwicklung von on-premise-Anwendungen von Bedeutung ist. Deshalb ist es für Entwickler wichtig, sich auch dann mit der Cloud-Entwicklung auseinanderzusetzen, wenn der Umzug der Anwendung noch in weiter Ferne ist. Starten können Sie zum Beispiel ganz einfach auf der Azure-Website, die jede Menge Ressourcen zur Entwicklung von Cloudanwendungen bereithält.

---