Ist MACH die Zukunft der IT-Architektur? Erfahren Sie, warum Microservices, API-first, cloud-native SaaS und Headless die IT-Architekturprinzipien sind, auf die Sie setzen sollten.
Ein kompakter Überblick zur MACH-Bewegung, ihren wichtigsten Vorteilen und ihrem voraussichtlichen Einfluss auf CTOs
Die Erwartungen an Software Engineering haben sich im letzten Jahrzehnt grundlegend gewandelt – getrieben von der DevOps-Bewegung sowie dem Aufstieg von Cloud-Technologien und ihren mittlerweile allgegenwärtigen Anbietern. Der breite Wechsel ins Remote-Arbeiten hat es zusätzlich wichtig gemacht, Abhängigkeiten zwischen Engineers zu reduzieren – seit jeher der Hauptgrund für Verzögerungen in Softwareprojekten.
Laut einer aktuellen Studie sehen Tech-Verantwortliche MACH (microservices-based, API-first, cloud-native SaaS und Headless) als die "Zukunft der Architektur". 80 % wollen ihre Investitionen in diesem Bereich im kommenden Jahr und darüber hinaus ausbauen. Werfen wir einen Blick auf die Vorteile der IT-Architekturprinzipien Microservices, API-first, cloud-native SaaS und Headless:
Microservices
Die Microservices-Architektur geht davon aus, dass mehrere kleinere Software-Bausteine denselben Wert schaffen können wie ein großer monolithischer Block. Der eigentliche Gewinn beim Wechsel zu Microservices liegt jedoch in der Entkopplung der Engineering-Arbeit. Jeder Engineer kann sich auf seinen eigenen kleinen Baustein konzentrieren, statt unzählige Stunden in die Abstimmung an einem riesigen Softwareprojekt zu stecken.
DoiT International arbeitet vollständig remote. Unsere größeren Softwareprojekte in kleinere Bausteine zu zerlegen, die Teams mit minimalem Abstimmungsaufwand übernehmen können, hat daher klare Vorteile. Das ist alles andere als trivial – aber wenn Software-Mehrwert schneller denn je geliefert werden soll, führt kein Weg daran vorbei.
API-first
Eine API-first-Architektur ist beim Schritt zu Microservices praktisch Pflicht. Sie ermöglicht es kleinen oder sogar winzigen Engineering-Teams, Software-Bausteine zu entwickeln, die zu einem größeren Ganzen zusammenpassen – weil andere Teams die Arbeit über ein entkoppeltes, konsumorientiertes Modell nutzen können. Wer kein Software Engineer ist, kann sich das mit einer Schlauch-Analogie vorstellen: Ein Automotor hat eine Öffnung, in die der Kraftstoff fließt – egal, welche Art von Tank das Auto hat, solange der Schlauch zwischen Tank und Motor zu beidem passt. Genau so funktionieren APIs: Der Tank wird in einer Fabrik gefertigt, der Motor in einer anderen, und die einzig nötige Abstimmung besteht darin, den Durchmesser des Schlauchs zu dokumentieren.
Cloud-native Software-as-a-Service
Cloud-native Software-as-a-Service (SaaS) ist eine weitere zentrale Säule in der neuen, vollständig remoten Welt des Software Engineering. Der Wechsel zu Remote-Engineering hat Unternehmen gezwungen, "abgeschottete" Rechenzentren, die nur aus dem Büro heraus erreichbar waren, neu zu denken – und Software Engineers stattdessen das Arbeiten von überall zu ermöglichen. Sobald diese Grenze gefallen war, erkannten immer mehr Unternehmen mit Bedarf an Softwareentwicklung, dass sie keine eigenen Rechenzentren mehr betreiben müssen und die physische Infrastruktur ebenso gut einem Cloud-Anbieter überlassen können.
Eine Fabrik muss ihren Strom schließlich auch nicht selbst erzeugen, sondern bezieht ihn in der Regel von einem Energieversorger. Der beschleunigte Schritt in die Cloud hat es den Anbietern ermöglicht, in kurzer Zeit deutlich mehr Personal einzustellen und mehr Services bereitzustellen. Und da immer mehr IT-Technologien in der Cloud als "-as-a-Service"-Variante verfügbar sind, können Engineers viel schneller und günstiger als früher mit ihnen experimentieren.
Früher musste ein Engineer, der eine neue Datenbank ausprobieren wollte, erst jemanden finden, der die Hardware bestellt, jemand anderen, der sie im Rechenzentrum installiert, und noch einen weiteren, der Betriebssystem und Datenbank darauf aufsetzt. Erst nach Erhalt der Zugangsdaten konnte er die Datenbank testen. Heute geht das alles auf Knopfdruck. Die Cloud hat sich von der reinen Infrastrukturbereitstellung zur Plattform für jede Technologie per Klick weiterentwickelt – mit immer größerer Freiheit, die besten Tools für die jeweiligen Engineering-Anforderungen auszuwählen.
Headless
Headless passt hervorragend zu Microservices und API-first. Viele moderne Software-Angebote sind dank API-first-Backends "mehrköpfig". Während die komplexere Geschäftslogik in der Cloud läuft, sind die Daten, die sie nutzt oder erzeugt, über APIs verfügbar. So können weitere, entkoppelte Engineering-Teams unabhängig voneinander Erlebnisse für Web, Mobile oder Desktop entwickeln – mit nur minimaler Abstimmung zwischen Frontend- und Backend-Teams.
Dank der Fülle an cloud-native SaaS-Angeboten oder "Technologies-as-a-Service" lassen sich diese Frontend-Erlebnisse zusätzlich durch von Cloud-Anbietern verwaltete Standardtechnologien ergänzen.
Die Zukunft von MACH
DoiT ist ein cloud-first und vollständig remotes Unternehmen. Unsere gesamte Infrastruktur liegt in der Cloud, und das einzige physische Stück Infrastruktur sind die Laptops, mit denen unsere Engineers Cloud-Technologien nutzen und kleine Software-Bausteine entwickeln, die sich ins große Produkt des Unternehmens einfügen.
Vor einigen Jahren, als unser Produkt noch deutlich kleiner war, stützten wir uns stark auf SaaS-Technologien von Cloud-Anbietern. Nur so konnten wir unseren Kunden mit einem sehr kleinen Engineering-Team in kurzer Zeit enormen Mehrwert liefern. Mit dem Wachstum von Unternehmen und Engineering war es nur folgerichtig, zusätzliche Services als kleine Microservices anzulegen, die sich in das größere Produkt einfügen – statt alles zu einem riesigen monolithischen Klumpen zu verbinden.
Während wir immer wertvollere Erlebnisse für unsere Kunden entwickeln, lohnt es sich, konsequent auf MACH zu setzen und Engineers immer wieder daran zu erinnern, warum dieser Ansatz für uns als Unternehmen so wichtig ist. Irgendjemand wird stets vorschlagen, einen oder zwei Schritte zurückzugehen – etwa eine weitere Technologie einzuführen, die wir selbst betreiben müssen, oder einen weiteren Service mit enger Kopplung zwischen Front- und Backend ohne APIs zu bauen. Solche Schritte können uns nur ausbremsen. Wir setzen lieber auf kleine, häufige und wertvolle Releases und lassen uns nicht in Nicht-MACH-Ideen und -Konzepten verzetteln.
Unser Unternehmen ist derzeit kein Mitglied der MACH Alliance, begrüßt die Initiative aber ausdrücklich. Wenn diese Konzepte in der Branche populärer und stärker akzeptiert werden, kann das nur zu einem deutlich besseren Software-Erlebnis für alle führen.