Durch die Ankunft von neuen, optimierten Möglichkeiten im Umfeld der Kollaboration und Produktivität in der Cloud ist auch eine neue Art der Entwicklung von Applikationen notwendig geworden. Eine, mit der man seine Anwendungen mit der, für diese neue Welt der Hybrid-Umgebungen notwendigen Flexibilität und Portabilität ausrüsten kann. Dieser neue Ansatz zur Applikationsentwicklung heißt Cloud-Native Architektur.
Trotz der Bezeichnung geht es in diesem Ansatz nicht alleine darum, Applikationen in der Cloud lauffähig zu gestalten. In Wirklichkeit ist das Gegenteil der Fall: es geht darum, Applikationen in jeder beliebigen Umgebung (also nicht nur in der Cloud, sondern auch on-premises und an virtuellen Maschinen) betreiben zu können, und bei Bedarf diese auch Flexibel zwischen den unterschiedlichen Umgebungen verschieben zu können. Dieser Ansatz erfordert eine ganz neue Denkweise in der Entwicklung, im Deployment und in der laufenden Verwaltung der Applikationen.
In dem „traditionellen“ Ansatz wurden Applikationen für Langlebigkeit und Stabilität konzipiert. Obwohl diese weiterhin essenzielle Eigenschaften einer modernen Anwendung sind, sind solche sogenannten monolithischen Applikationen längst nicht flexibel genug. Denn in einer cloud-betriebenen Geschäftswelt reichen Langlebigkeit und Stabilität nicht mehr aus: Applikationen müssen rasch auf den Markt gebracht werden, die Funktionen dieser müssen voneinander abgrenzbar und wiederverwendbar sein und Prozesse müssen zum höchstmöglichsten Grad automatisiert werden.
Um das Ziel, Cloud-Native zu werden zu erreichen, muss man die genutzten Tools und auch die Prozesse im gesamten Unternehmen unter die Lupe nehmen und neu denken. Die Änderungen betreffen also nicht nur das interne Entwicklerteam.
Im traditionellen Entwicklungsansatz wird eine Software, wie etwa ein Webshop so programmiert, dass Funktionen, z.B. Katalog, Bestellkorb, Zahlungsabwicklung und „Watchlist“ alle in einem, quasi als Paket programmiert und deployed werden. Wenn aber der gleiche Webshop auf Basis der Cloud-Native-Methodik entwickelt wird, werden all diese Funktionen jeweils als alleinstehende Services programmiert, die untereinander mittels APIs oder Messaging kommunizieren können.
Anschließend können diese Microservices – oder eben auch Prozesse oder ganze Anwendungen – in Containers verpackt werden. Das macht es möglich, einzelne Updates oder Bugfixes zu Funktionen einzeln ausrollen zu können, ohne dass dabei die anderen Funktionen der Applikationen betroffen sind. Außerdem werden solche Komponenten dadurch einfach wiederverwendbar und können in anderen Applikationen einfach wieder zum Einsatz gebracht werden.
Container sind praktisch überall ausführbar. Dies vereinfacht die Bereitstellung und den Betrieb auf virtuellen Maschinen, in Bare-Metal-Umgebungen via Docker oder auf Kubernetes-Clustern, im lokalen Rechenzentrum oder auch in der Public Cloud.
Wenn man cloud-native Prozesse auch im eigenen Unternehmen anwenden möchte, müssen nicht nur das Entwicklerteam, sondern auch IT-Operations, Qualitätsmanagement und auch die IT-Security-Abteilung darin involviert werden. Denn bei diesem Ansatz gehört die Praxis, in der Teams verteilt und isoliert voneinander arbeiten abgeschafft, und es muss eine DevOps-Kultur adaptiert werden. Das heißt, dass Development, Operations, QM und Security in enger Abstimmung und mit integrierten Prozessschritten arbeiten. Dies ist erforderlich, sodass auch entsprechende Automatisierungsmaßnahmen zur Optimierung des Applikation-Lifecycles umgesetzt werden können.
Eine dieser ist die Automatisierung von Integration- und Deployment-Prozessen. Die Delivery-Pipeline einer cloud-native Anwendung kann durch Continuous Integration/Continuous Deployment vollständig automatisiert werden. Das heißt, dass jede vom Entwicklerteam implementierte Änderung im Source-Code automatisch von der Development- in die Testumgebung verschoben, dort für eventuelle Fehler überprüft und bei fehlerfreiem Code automatisch zum produktiven Einsatz gebracht wird. Dies verkürzt Rollout-Prozesse und erspart Mitarbeitern wertvolle Zeit.
Auch in der Skalierung von Cloud-Native-Anwendungen werden neue, effektivere Methoden eingesetzt: statt vertikales Skalieren werden solche Applikationen bei erhöhtem Nutzungsbedarf horizontal skaliert. Das bedeutet, statt die Kapazität einzelner Nodes durch Hardwareverbesserungen zu erhöhen, werden hier zusätzliche Nodes gestartet, die der gewünschten Funktion bessere Verfügbarkeit gewährleisten. Ein großer Vorteil der Methodik ist es, Verfügbarkeit im laufenden Betrieb optimieren zu können.
Die zwei bekanntesten Automatisierungsplattformen für Container-Management sind Kubernetes und OpenShift, wobei Kubernetes eine Open-Source-Option darstellt und in vielen verschiedenen Distributionen auffindbar ist. OpenShift ist hingegen eine, für Enterprise-Anforderungen optimierte Lösung von Red Hat mit erweiterten Verwaltungs- und Sicherheitskapazitäten.
Die Umstellung auf eine Cloud-Native-Strategie erfordert Offenheit und Kollaboration seitens Ihrer Mitarbeiter: die Tools und Prozesse, die zum Einsatz gebracht werden, müssen von jedem akzeptiert und verstanden sein. Es muss klar definiert und kommuniziert werden, welche Vorteile und Verbesserungen mit dem neuen Ansatz angestrebt und wie diese erreicht werden. Um die allgemeine Akzeptanz Ihrer Mitarbeiter zu erhöhen, ist ein umfangreicher Change-Prozess im Unternehmen empfehlenswert, der auch Workshops und Trainings für die Mitarbeiter enthält.
Die oben beschriebenen Maßnahmen werden in den meisten Fällen Schritt für Schritt eingeführt, sodass diese den Alltagsbetrieb des Unternehmens nicht spürbar beeinflussen und dass Mitarbeiter sich zwischenzeitlich auch das notwendige Knowhow dieser Tools und Prozesse aneignen können.
Mehr Fragen und Antworten rund um die Cloud im Blog.
