Array ( [0] => facebook [1] => twitter [2] => google_plus )

Monolithische vs. Microservice Architektur

Posted on:27. April 2016

Author:Markus Köhler

Category:IT

Share: / /

Heute hatte ich Gelegenheit, mit einem Trainer für Laravel zu sprechen. Zur Diskussion stand die optimale Projektstruktur für moderne Software- bzw. Web-Projekte.

Da ich sowohl geschäftlich als auch privat zur Zeit an dem einen oder anderen Projekt mit Laravel arbeite, war es natürlich umso interessanter, wie ein Trainer die Situation sieht. Und er sieht sie differenziert:

In den meisten Fällen, also für von der Codebasis her kleine bis mittelgroße Projekte, empfiehlt der Trainer, monolithisch vorzugehen, d.h. Models, Views und Controller (MVC) in derselben Laravel-Instanz zu belassen. Diese kann man durch Unterordner strukturieren, bspw. app/Http/Controllers/Feature1/FirstController.php, resources/views/Feature1/FirstView.blade.php.

Dies sollte bei dieser Projektgröße auch der Performance nicht schaden, da Laravel per se durch diverse Caching-Mechanismen schon auf Speed ausgelegt ist. Es gibt allerdings durchaus ein paar gute Gründe, von der monolithischen Architektur abzuweichen:

  1. wenn abzusehen ist, dass das Projekt so exponentiell wächst, dass man das Frontend und das Backend (Daten, Service) auf verschiedenen Webservern betreiben will – entweder aus Performanz-Gründen oder zur Skalierung
  2. wenn die Daten, also der Service, beispielsweise auch von mobilen Apps, egal ob nativ oder hybrid, direkt angesprochen/abgefragt werden können soll
  3. wenn dieselbe Datenbasis von mehreren (Laravel) Apps gleichzeitig genutzt werden soll

Im dritten Fall muss man sich aber nicht gezwungenermaßen für eine Microservice-Architektur entscheiden. Eine weitere, bevorzugte Möglichkeit ist der Einsatz von Packages, also etwa über composer oder bower, die man sich je nach Bedarf in die Laravel-Installation inkludieren kann. Das setzt natürlich gewisse Kenntnis voraus, wie Packages für Laravel erstellt werden und auch Grundkenntnisse im Umgang mit Git, da solche Packages bspw. für composer meist über GitHub bereitgestellt werden.

Daher ist es meist anzuraten, erst einmal monolithisch zu starten, und zwar mit Features in Form von Packages. Sollte das Projekt soweit über sich hinaus wachsen, dass man die Datenschicht von der Frontend-Schicht trennen möchte, kann man sich aus den bereits erstellten Packages immer noch ganz schnell eine separate RESTful API zusammen-„composern“, beispielsweise per Lumen, Laravels Microservice-Framework.

Eine weitere empfehlenswerte Vorgehensweise ist TDD, Test-Driven Development. Das bedeutet, dass die Tests für die einzelnen Komponenten bzw. Packages bereits vor dem eigentlichen Quellcode geschrieben werden. Unter der Voraussetzung, dass die gewünschten Rückgabewerte eines Features bereits vor dessen Entwicklung feststehen, lässt sich so die Entwicklung entlang der Testergebnisse skalieren, zusätzlich wird eine bestmögliche Testabdeckung der Entwicklung erreicht.

TDD führt auch schon nahtlos zum nächsten Thema über, und zwar CI, Continuous Integration. Der bekannteste CI-Server ist „Jenkins CI“, der es ermöglicht, eine Codebasis automatisch bei jedem Commit bzw. Push an den Git-Server (Bitbucket/GitHub/…) auszuchecken, neue/geänderte Abhängigkeiten zu installieren, Umgebungsvariablen zu setzen, Unit-Tests auszuführen und vieles, vieles mehr. Somit kann man das Testing bzw. für Softwareprodukte auch das Erstellen der Bibliotheken und ausführbaren Dateien, (fast) komplett automatisieren. Wir leben nun einmal zweifellos im goldenen Zeitalter der Softwareentwicklung (englisch).

GD Star Rating
loading...

Kommentar verfassen

%d Bloggern gefällt das: