Microservices einfach nutzen mit der brudi Platform

Was sind diese Microservices, von denen brudi immer wieder schreibt, und weshalb sind sie die Zukunft? In diesem Artikel geben wir einen kleinen Einblick in die Geschichte von Microservices und wie diese Architektur zum Erfolgs-Katalysator für Unternehmen wurde, welche "continuous deployment"  (also fortlaufende Softwareauslieferung) praktizieren. Zum Schluss zeigen wir, wie die brudi Platform helfen kann, den Wechsel von Projekten zu Microservices mit fortlaufender Entwicklung und Auslieferung zu stemmen.

brudi Platform
Die brudi Plattform ist gebaut für serverlose Applikationen und Microservices. Sie bietet ein Kit an Cloud-Native Projekten, um den Softwareherstellungszyklus und dessen Management zu erleichtern.

Netflix und Microservices

Wir haben Netflix schon einmal als gutes Beispiel in meinem Agile-Artikel genannt. Neue Features werden in den Applikationen nahtlos eingeführt, die Qualität ist hoch und der Service immer erreichbar. Der fantastische Erfolg von Netflix und ihre Fähigkeit, mehr Funktionen schneller an die Nutzer auszuliefern, haben hellhörig gemacht. Viele Unternehmen wollen wissen, wie Netflix die Technologie nutzte, welche ihnen diesen enormen Vorsprung auf die Konkurrenz verschaffte.

Doch ein wenig Nachforschung zeigt, auch bei Netflix brauchte es eine Katastrophe, um aus der Asche gestärkt wieder auf zu erstehen. Der frühere Netflix Cloud Architekt, Adrian Cockcroft, entschied nach einem desaströsen Release mit einem fehlplatzierten Semikolon, die ganze Architektur von monolithischer Architektur auf Microservices umzustellen.

Wenn auf monolithischer Architektur neue Features entwickelt und getestet wurden, war es unglaublich mühsam, diese Änderungen auf der produktiven Instanz zu veröffentlichen:

Der Wechsel zu Microservices befähigte die Netflix-Entwickler, neue Features viel schneller und nahtlos an die Nutzer auszuliefern.

Microservices, Docker und Kubernetes

Docker Container und Microservices gehen Hand in Hand. In dem man die Microservices in dedizierten Containern laufen lässt, kann jeder Einzelne unabhängig aktualisiert oder verändert werden. Die Containerisierung entfernt das Risiko von Konflikten zwischen Programmiersprachen, Bibliotheken oder Frameworks. Da Docker Container bestens auf neue Systeme übertragbar sind und voneinander isoliert betrieben werden können, ist es ziemlich einfach, eine Microservice-Architektur mit Containern aufzubauen.

Die Logos von Docker und Kubernetes in architektonischem Zusammenhang.

Container orchestrieren

Irgendwann sind ganz viele Microservices in ebenso vielen Containern am laufen. Da macht es Sinn, diese zu managen oder im Jargon "orchestrieren", sodass sie als gemeinsame Applikation verwaltet werden. Dafür gibt es Orchestrierungs-Werkzeuge (Cluster Manager) wie Kubernetes, Docker Swarm und weitere.

Früher war die Wahl vom Cluster Manager noch eine komplizierte Entscheidung mit vielen Abhängigkeiten. Seit 2015 hat die Open-Source-Lösung Kubernetes das Rennen gemacht, wird von allen relevanten Cloud-Providern unterstützt und ist nach Linux und Docker die dritt-beliebteste Plattform der IT-Branche.

Die Moral von der Geschichte ist also, dass es für die meisten Projekte die konkurrenzfähig bleiben wollen, notwendig ist,  ihre Anwendungen um die Microservice-Architektur zu planen und sie in einem Kubernetes-Cluster laufen zu lassen – auch wenn es ein paar Firmen gibt, die andere Cluster-Manager nutzen.

Sind Microservices immer das Richtige?

Microservices sind nützlich, wenn Anwendungen skalierbar sein sollen und (plötzlich) tausende Anfragen abhandeln müssen. Am nützlichsten sind sie, wenn grosse Entwicklungsteams sich in kleinere Einheiten aufteilen, um parallel an verschiedenen Aspekten der Applikation zu arbeiten. Damit beschleunigen sie den Auslieferungsprozess wie eine Rakete.

Für kleine Teams war der Overhead durch die Orchestrierung oft zu abschreckend, um eine Microservice-Architektur zu nutzen. Die brudi Platform kann diesen Mehraufwand jedoch für dich übernehmen - mit oft benötigten Konfigurationen, welche mit graphischem Nutzeroberfläche sowie Command-Line-Tools einfach aufgesetzt und verwaltet werden können.

Denn auch für kleinere Teams sind Microservices notwendig, um Rechenlast zwischen mehreren Cluster und Datencenter zu verteilen. Aber ohne diesen Anspruch, etwa bei einer Website ohne Applikationen, kann man bei monolithischer Architektur bleiben.

Der Unterschied zwischen Homepages und Applikationen
Nicht jede Webseite, ist eine Homepage und nicht jede Applikation (kurz App) ist in einem Appstore zu finden. Dieser Artikel zeigt die Unterschiede dieser digitalen Produkte und welche unterschiedliche Expertisen benötigt werden.

Wie die brudi Platform Microservices und Kubernetes ergänzt

Obwohl Microservices vielen Organisationen geholfen haben, skalieren zu können und schneller Vorwärts zu kommen, hat die Komplexität, Microservices zu managen, zugenommen. Gerade wenn der Cluster Manager in einer Public Cloud lief.

Die brudi Platform minimiert die Komplexität – Microservices in Kubernetes auszuliefern oder up-to-date zu halten – in dem kontinuierliches Ausliefern, Cluster-Sichtbarkeit und Monitoring mitgeliefert werden. Infrastrukturaufgaben, die benötigt würden, wenn die Teams die Microservices manuell in Kubernetes ausliefern, werden von der brudi Platform übernommen. Und da die Platform als Software-as-a-Service (SaaS) konzipiert ist, bleibt mehr Zeit um den Geschäftswert des Produktes zu erhöhen, anstatt sich um Ops kümmern zu müssen.

Mit der brudi Platform können Entwickler fortlaufend neue Features entwickeln und diese kontinuierlich und in Echtzeit in ihre App ausliefern, ohne direkt mit Kubernetes interagieren zu müssen. Das ist nicht nur ein Sicherheitsaspekt, es ermöglicht auch verschiedenen Teams, an verschiedenen Microservices zu arbeiten – ohne Downtime. Vielleicht am wichtigsten ist jedoch, dass sich die Geschwindigkeit von Releases von Updates und neuen Features auf die Produktion massiv verbessert.

Einen Cluster aufsetzen mit brudi CLI

GitOps, brudi Platform & continuous delivery

Deklarative Infrastruktur ist mittlerweile die Norm und Kubernetes garantiert Updates fortlaufend und ohne Downtime. Somit wird es möglich, die gesamte CI/CD-Pipeline aus Git oder einem anderen Versionssystem zu initialisieren. Diese Methode von kontinuierlicher Auslieferung und Clustermanagement mit Git wird GitOps genannt.

Wie erwähnt bieten Microservices grosse Vorteile: Kontrolle zu schaffen und schnell ausliefern zu können - um schmerzfrei die Qualität der Produkte zu garantieren und in hoher Geschwindigkeit neue Features zu veröffentlichen. Mit GitOps ist auch eine stetig wachsendende digitale Landschaft kein Problem, die Komplexität des Cloudbetriebs erhöht sich dank GitOps in der brudi Platform nur marginal.

brudi Ops - Build. Test. Deliver
Cloud-Infrastrukturverwaltung, Überwachung, Benachrichtigung und vereinfachte Arbeitsabläufe für cloud-native Systeme. Das Schweizer Taschenmesser der brudi Platform bietet ein einheitliches Frontend für alle deine Infrastrukturwerkzeuge und Anwendungen.

Kein Lock-In mit der brudi Platform

Die brudi Platform lässt dich dein Versioning-Repository und deine CI-Tools nutzen. Auch bezüglich der Wahl des Cloud-Anbieters stehen die meisten Türen offen: Von Google über Amazon bis zu lokalen Schweizer Cloudanbieter – die brudi Platform läuft mit allen CSP.

Noch unsicher wie eine Applikation cloudifiziert werden kann? Interesse am umstellen von bestehenden Diensten auf Microservices? Mit der Microservice-Architektur-Beratung von brudi ist das Projekt auf der sicheren Seite.

brudi Cloud-Software Architektur
Ein grundlegendes Designsystem inklusive Cloud- und Betriebstrategieberatung ermöglicht das aufgleisen skalierbarer Projekte und Modernisierungen sowie Performanceoptimierungen in bestehenden Systemen.