Service Mesh und API Gateway basieren auf ähnlichen Konzepten und ihre Aufgabengebiete überschneiden sich. Die Entscheidung für die passende Technologie macht das nicht einfacher. Es gibt auch die Möglichkeit API Gateway und Service Mesh zu kombinieren, dann stellt sich aber immer noch die Frage, wer welche Verantwortlichkeiten übernimmt.
Zwischen der Version 2 und der Version 3 hat sich bei OpenAPI einiges geändert. Die Version 3 ist modularer aufgebaut, übersichtlicher und bietet neue Features wie z.B. Links zwischen Ressourcen. In unserem Video Tutorial lernst du die neue Swagger Version an einem Beispiel Schritt für Schritt kennen.
Die Frage nach der optimalen Größe eines Microservice ist schwer zu beantworten. Vielleicht können wir uns der Frage nach der Größe über die minimale Größe eines Microservice annähern. Mit der minimalen Größe können wir die Frage zumindest nach einer Seite abgrenzen.
Micro kommt vom griechischen Mikros was so viel wie klein oder winzig bedeutet. In der Physik ist ein µ ein Millionstel. Das suggeriert, dass ein Mikroservice winzig klein ist. Offensichtlich ist eine Größe von einem Millionstel eines Monolithen zu klein. Micro ist daher etwas irreführend, klingt aber besser als Centi- oder Deziservices.
Die Eigenschaften der REST Architektur führen zwangsläufig zu datengetriebenen Schnittstellen anstatt passende Abstraktionen anzubieten. Dieser Blog Beitrag zeigt auf, dass REST APIs zum CRUD Antipattern neigen.
Für Web Services gab es Standards und Profile, die deren Verwendung ausreichend genau beschrieben. Nein, ich möchte nicht die Web Services zurück. Für REST gibt es keinen Standard. Wenn ich wissen möchte, wie ich ein API zu gestalten habe, dann schaue ich in die Dissertation von Fielding, in die HTTP Spezifikation und auf Stackoverflow nach. Diese Quellen werfen aber mehr Fragen auf, als sie beantworten. Daher gibt es unzählige API Stile Guides z.B. von Twitter, Adidas oder dem Weißen Haus, die diese Lücken füllen. Wer einen vollständigen und konsistenten Stile Guide im Unternehmen hat, kann sich glücklich schätzen. Die Anzahl der Guides und die Menge an notwenigen Richtlinien macht die Auswahl oder Erstellung eines Guides nicht einfacher. Allein, dass diese Guides gebraucht werden, zeigt wie komplex REST tatsächlich ist.
Fast alle öffentlichen Schnittstellen sind REST basierte APIs. Ein Grund für die weite Verbreitung von REST sind die geringen Hürden, die es für den Aufruf eines APIs zu überwinden gilt. Für einfache Aufrufe genügt ein Browser und Clients können in fast jeder Programmiersprache, selbst in Skriptsprachen wie Perl und PHP mit nur wenigen Zeilen Code verwirklicht werden. Einer der größten Vorteile von REST ist der einfache Einstieg selbst für Nicht-Informatiker.
Das Diagramm unten zeigt die Aufmerksamkeit, die REST und die Service orientierte Architektur bei Google in Form von Suchanfragen bekommen. Die Kurve für SOA ist ein typischer Verlauf des Gartner Hype Cycles. Innerhalb von 7 bis 10 Jahren steigt die Aufmerksamkeit zum Gipfel der überzogenen Erwartungen und fällt dann wieder ab um vielleicht noch ein Plateau der Produktivität zu erreichen. Der Verlauf der REST Kurve ist bemerkenswert: Der Anstieg hält bereits seit fast 20 Jahren an und ein Abbruch ist noch nicht in Sicht.