Nichts hat die Art und Weise, wie in der IT-Welt Software konzipiert und entwickelt wird in den letzten Jahren so sehr verändert wie Microservices. Heutige Anwendungen müssen in einem Cluster von mehreren Knoten funktionieren, dynamisch platzierbar, skalierbar und fehlertolerant sein.

Microservices wiederum bilden die Basis von Cloud Native Applikationen. Die einzelnen Microservices sind voneinander unabhängig und können auf mehreren Servern an verschiedenen Standorten laufen. Cloud Native Anwendungen nutzen diese lose gekoppelten Cloud Services. Bei Cloud Native handelt es sich um einen Ansatz, der gewährleisten soll, dass Anwendungen für die Cloud-Computing-Architektur entworfen und entwickelt werden. Die Besonderheiten der Cloud-Computing-Architektur sollen zum Vorteil der Anwendungen genutzt und alle Möglichkeiten voll ausgeschöpft werden. Für diese Art von Anwendungen wird oft die Abkürzung NCA verwendet, welche für Native Cloud Application steht.

Eine Native Cloud Application ist ein echtes Multitalent

Native Cloud Applications haben zahlreiche Vorteile. Sie sind weder an eine spezielle Hardware noch an bestimmte Betriebssysteme gebunden, lassen sich leicht skalieren, sind einfach zu deployen, und sie sind georedundant. „Redundanz“ heißt, dass mindestens eine zusätzliche Ressource als Back-up für den Notfall vorhanden ist. In der Kombination mit „Geo“ bedeutet es, dass diese Ressourcen zusätzlich räumlich voneinander getrennt sind. Nur so kann wirklich sichergestellt werden, dass auch bei schwerwiegenden technischen Problemen an dem einen Ort noch immer ein intaktes Back-up an einem anderen Ort verfügbar ist. Laut Bundesamt für Sicherheit in der Informationstechnik (BSI) sollten es sogar mindestens 200 km sein, um auch vor Naturkatastrophen gut geschützt zu sein.

Die vier zentralen Bestandteile der Entwicklung einer Native Cloud Application: DevOps, Continuous Delivery, Microservices und Container

Vier zentrale Bestandteile für die Entwicklung einer Native Cloud Application

• DevOps ist die Zusammenarbeit zwischen Entwicklung und Betrieb mit dem Ziel, den Auslieferungsprozess zu automatisieren.
• Continuous Delivery erlaubt die schnellere und zuverlässigere Auslieferung von Software mit weniger Risiken
• Microservices ist ein Architekturansatz, in dem eine Anwendung als Verbund von mehreren kleinen Services gebaut wird.
• Container bieten leichtgewichtige Virtualisierung. Sie sind schneller und effizienter als normale Virtualisierung. Container können miteinander verknüpft und gemeinsam orchestriert werden.

Diese vier Prinzipien erlauben es gemeinsam, schnell und risikoarm eine verteile Anwendung zu entwickeln, auf verteilter Infrastruktur auszuliefern und zu betreiben. Als Infrastruktur kann zum Beispiel Amazon Web Services oder Microsoft Azure genutzt werden.

Herausforderungen bei der Entwicklung und dem Betrieb von NCAs

Die Entwicklung einer Native Cloud Application bringt neue Herausforderungen mit sich, die ein Umdenken in der Entwicklung erfordern.

• Persistente Datenablage: Container lassen sich nur kaum zur Datenhaltung nutzen, da diese sehr flüchtig sind. Wird ein Container gelöscht oder abgebaut, sind die Daten auch weg. Persistente Daten sollten deshalb außerhalb der Microservices gehalten werden. Auf diese Daten kann dann mittels einer Service-Schnittstelle zugegriffen werden.
• Integration der Services: Verteilte Anwendungen bringen eine eigene Komplexität mit sich. So müssen die einzelnen Microservices über Server oder sogar Cloud-Provider hinweg miteinander integriert werden. Sie müssen sich gegenseitig finden und die Kommunikation soll fehlertolerant verlaufen.
• Monitoring: NCAs können aus mehreren hundert bis tausend einzelnen Microservices bestehen. Umso wichtiger ist es, alle im Blick zu behalten. So müssen Werte wie Auslastung und Antwortzeiten beobachtet werden, um die Stabilität des gesamten Produktes zu gewährleisten.
• Cloud Lock-in vermeiden: Durch die Einfachheit in ihrer Bedienung passiert es schnell, dass man sich von einem einzigen Cloud-Provider abhängig macht. Dessen sollte man sich bei der Planung bereits bewusst sein und so viele Industrie-Standards wie möglich anstelle von proprietären Lösungen nutzen.
• Bauen von Pipelines zum Ausliefern der NCAs: NCAs arbeiten typischerweise in der Cloud. Möglicherweise sogar bei mehreren Cloud-Providern. Das erschwert das Ausliefern von NCAs, da diese stark verteilt sind und miteinander integriert werden müssen. Zudem können unterschiedliche Microservices unterschiedliche Abhängigkeiten fordern. Es werden Pipelines benötigt, die die einzelnen Microservices dorthin und in der benötigten Redundanz deployen, wo sie gebraucht werden.

Vorteile einer Native Cloud Application

Mit all den Herausforderungen, um eine Native Cloud Application zu entwickeln und zu Betreiben stellt sich immer die Frage: Ist es den Aufwand wert? Was sind die Vorteile?

• Kosten: Wird die Anwendung auf einem Cloud-Anbieter betrieben, zahlt man nur das, was verbraucht. So können die Kosten für den Betrieb in nicht-aktiven Zeiten gesenkt werden.
• Skalierbarkeit: Native Cloud Applications sind durch ihre Microservice-Architektur stark skalierbar. So können einzelne Microservices bei Bedarf dupliziert werden.
• Kundennähe: NCAs können auf Servern weltweit betrieben werden. So müssen Anwender die Daten nicht über die ganze Welt verschicken und die Latenz sinkt.
• Life-Cycle: NCAs können schneller und mit weniger Aufwand und Kosten aktualisiert werden. Dadurch erhöht sich die Auslieferungsgeschwindigkeit und das Time-To-Market sinkt.
• Robustheit: NCAs können georedundant betrieben werden, wodurch Ausfälle bei lokalen technischen Problemen deutlich verringert werden.

Tools für Entwicklung und Betrieb einer Native Cloud Application

Die Cloud Native Computing Foundation ist eine neutrale Plattform für die meisten Open-Source-Projekte, die dabei helfen, die Herausforderungen und Probleme bei der Entwicklung und im Betrieb einer Native Cloud Application zu meistern. Darunter fällt das Orchestrierungstool Kubernetes, sowie das Monitoring-Tool Prometheus.

Die CNCF stellt eine Übersicht über alle Projekte, Tools und Provider zur Verfügung, die bei der Entwicklung, Auslieferung und Betrieb von NCAs helfen.

Was Softwarearchitekt:innen beachten müssen

Das Sicherstellen der ACID-Eigenschaften (Atomic, Consistency, Isolated, Durability) bei der Datenhaltung ist in hoch verteilten Anwendungen mit mehreren Datenbanken sehr schwierig bis unmöglich. In der Regel kann für eine gewisse Zeit auf Konsistenz der Daten verzichtet werden. In diesen Fällen sind Datenbanken mit BASE-Eigenschaften (Basically Available, Soft state, Eventual consistency) interessant, denn hier wird die Datenkonsistenz im Laufe der Zeit hergestellt. Ein gutes Beispiel ist Twitter, da auf dieser Plattform die Follower-Zahlen nicht in Echtzeit aktualisiert werden.

Softwarearchitekt:innen müssen entscheiden, für welche Daten Konsistenz benötigt wird und für welche nicht. Genauso müssen Sie darauf achten, die richtige Anzahl und Größe zu finden, da sie miteinander integriert werden. So sollte vermieden werden, aus reiner Bequemlichkeit neue Microservices zu implementieren. Microservices sollten immer nur eine Funktion erfüllen.

Je mehr Microservices es gibt, desto schwieriger und wichtiger wird es, diese zu beobachten. Wichtige Daten wie Durchlaufzeiten und Aufrufe pro Zeiteinheit können kritische Bereiche, Fehler und Flaschenhälse aufdecken. Monitoring-Lösungen wie der ELK-Stack helfen dabei, die verteilten Metriken zu sammeln, zentralisieren und visualisieren. So können auch Grenzwerte gesetzt werden, deren Überschreitung oder Unterschreitung einen Alarm auslösen. Diese Grenzwerte sollten aber auch immer wieder evaluiert und angepasst werden.

Best Practices bei der Entwicklung und Betrieb von Native Cloud Applications

Die Microservices einer NCA sollten sauber in zustandlose Services und zustandsbehaftete Services getrennt werden. Zustandslose Services können problemlos dupliziert und wieder abgebaut werden, ohne den Zustand der Anwendung zu ändern.

Microservices sollten nach Möglichkeit auch keine Anforderungen an das zu Grunde liegende System wie beispielsweise SSDs oder GPU haben. So lassen sie sich simpel in verschiedenen Umgebungen deployen.

Bei der Entwicklung der NCAs ist es wichtig, so viel wie möglich zu automatisieren. Das hilft, die vielen Microservices und die verteilte Natur einer solchen Anwendung beherrschbar zu machen. Infrastructure-as-Code automatisiert die Bereitstellung der Infrastruktur. Dieser Code kann und sollte auch mit versioniert werden. Das garantiert, dass jeder Service immer und in jeder Umgebung für ihn passend konfigurierte Infrastruktur besitzt.

Wenn dann ein weitverbreiteter Standard zur Kommunikation benutzt wird, wie etwa HTTP, können Microservices mit Technologien und Sprachen entwickelt werden, die am besten zur Aufgabe passen.

Fazit

Native Cloud Applications erlauben es den großen Internetgiganten wie Google und Twitter global ihre Services anzubieten, schnell Änderungen und neue Funktionen an die Nutzer:innen zu bringen. Herausforderungen, die sie mit sich bringen, lassen sich durch bereits etablierte Entwurfsmuster und Open Source Tools und Projekte ohne große Schwierigkeiten meistern. Die Hürden bei der Entwicklung und dem Betrieb einer Anwendung in der Cloud werden immer geringer, sodass heute jeder die Möglichkeit hat NCAs zu entwickeln und zu betreiben.

Training zu ‘Infrastruktur, Container und Cloud Native (CLOUDINFRA)‘

Unser 3-tägiges Training ‘Infrastruktur, Container und Cloud Native (CLOUDINFRA)‘ vermittelt das notwendige Wissen und die Fähigkeiten, um dynamische Cloud Native Architekturen konzipieren und implementieren zu können. Es werden zentrale Themen wie Container Application Design, Logging/Monitoring/Alerting, Container Native Storage, Möglichkeiten zur UI Integration sowie Container Manager vorgestellt. Wenn Sie die Zertifizierung zum Certified Professional for Software Architecture – Advanced Level (CPSA-A) nach dem iSAQB-Programm anstreben, erhalten Sie für dieses Training 20 Credit Points im Kompetenzbereich Technologie und 10 Credit Points im Kompetenzbereich Methodik.