Wer auf Reisen geht, informiert sich über Kultur, Orte und Klima des Landes, bevor er seine Koffer packt. Gleiches gilt für die Reisevorbereitungen in die Cloud. Für Software-Architekten ist hier ein Musterkatalog wichtiger als die Werbeprospekte der Cloud-Anbieter. Cloud Design Patterns helfen, bewährte Lösungen schon beim Entwurf der Dienste zu berücksichtigen und so typische Stolperfallen zu vermeiden.
Da es sich bei der Cloud, anders als bei der Software-Entwicklung, noch um eine recht neue Disziplin handelt, gibt es keinen einheitlichen Musterkatalog sondern viele Mustersammlungen. Dennoch bilden sich gerade durch die fortschreitende Containerisierung (CaaS), DevOps, Microservices und serverlose Funktionen (FaaS) einige immer wiederkehrende Muster heraus, die für den Bau von Cloud native-Anwendungen essentiell sind. Letztlich wird nicht nur ein einzelner Service gebaut, sondern ein verteiltes System-of-System designt. Darauf beruht letztlich der technische Erfolg des gesamten Internets.
Aus der Muster-Schneiderei
Neben den Enterprise Integration Patterns (Hohpe, Wolf) und den Stability Patterns (Nygard) sind vor allem die Microservices Patterns (von Chris Richardson) eine gute Anlaufstelle. Diese Muster lassen sich in die Bereiche Service-Discovery und Registry, Kommunikation (API Gateway), Deployment-Arten (Mehrinstanzen oder Einzelinstanzen pro Host, Serviceinstanz pro VM oder Container) und Datenhaltung (separate Datenbank pro Service) unterteilen.
Da Microservices heute meist in Containern laufen, muss auch beim Bau der Container (Immutability) einiges beachtet werden. Statt Stability oder Routing Patterns direkt in jedem Microservice einzubauen, bietet es sich an, sie in eigene Services auf Netzwerkebene auszulagern. Hier hat sich das Sidecar (Beiwagen) Pattern etabliert. Dabei geht es darum, Querschnittsdienste, wie Logging oder Authentifizierung, die keinen fachlichen, sondern einen technischen Charakter haben, in einem separaten Container anzubieten, der von den anderen Containern genutzt und mit diesen verbunden wird. Weitere relevante Muster sind Ambassador (Botschafter), Adapter, Initializer, Work, Observability und Custom Controller Patterns.
Brendan Burns hat im Jahr 2016 Container Design Patterns als erster in einem Vortrag beschrieben und in weiteren Artikeln und Büchern erläutert. Container Design Patterns basieren auf den allgemeinen Design-Prinzipien Separation of Concerns, Self Containment und Single Responsibility. Diese Prinzipien wurden um die Erfahrungen, die Brendan Burns als Leiter der Google Cloud Plattform und der daraus hervorgegangenen führenden Container-Management-Plattform Kubernetes gemacht hat und inzwischen bei Microsoft Azure fortführt, erweitert. Inzwischen sind sie auch in Kubernetes-Zusatzprodukte, wie zum Beispiel Istio, Vault, SPIFFE oder Envoy, umgesetzt.
Jenseits vom reinen „Lift-and-Shift“ gilt es beim Bau verteilter Anwendungen in der Cloud immer noch einige Klippen zu umschiffen und die bereits von Peter Deutsch vor mehreren Jahrzehnten formulierten acht Fallstricke zu vermeiden. Cloud Design Patterns helfen nicht nur beim Bau der Dienste, sondern auch beim Bereitstellen der dafür notwendigen Infrastruktur, um mehr Qualität, beispielsweise durch Flexibilität, Sicherheit und Robustheit, zu erbringen. Damit sind Unternehmen, wie mit einer Reiseapotheke, für die wichtigsten Fälle auf dem Weg in die Cloud vorbereitet.
Alle Beiträge dieser Blog-Serie zum Thema Cloud:
Teil 1 Darf es etwas weniger sein – wie man in der Cloud Kosten sparen kann
Teil 2 Wege in die Cloud: Die 6 R’s der Cloud-Migration
Teil 3 Designermuster für Cloud-Systeme – Design Patterns
Teil 4 AWS Cloud Adaption Framework
Weitere Beiträge:
Kubernetes – ein Betriebssystem für die Multi-Cloud
CNCF als Stiftung für die Cloud