Ein bisschen Geschichte zu Microservices

Ja, ok, ist an sich ein alter Hut, aber hey, vielleicht kann ich ja noch ein paar interessante Punkte beisteuern. Ich fange erstmal mit dem klassischen „Pff, hab ich schon vor 100 Jahren gemacht“ Sprüchen des IT Opas an:

Microservices aus Sicht des Java EE Entwicklers

Für Java EE Entwickler ist das irgendwie alles erstmal total unspektakulär. Kleine, Domainorientierte Einheiten, die in sich geschlossen sind? Nannte man erst Components, die dann zu einer Applikation zusammengestöpselt wurde und später, als SOA aufkam, Services.

Die einzelnen Komponenten wurden in Einheiten (EARs) deployed. Die Registry heißt bei Java EE JNDI, worüber auch externe Services wie Datenbanken angebunden werden können. Monitoring, Verteilung auf mehrere Hardwarenodes, Paralellisierung, Messeging-Systeme, Log-Verwaltung – all das hat der Application Server geliefert. Jeder Hersteller hatte ein paar Extras eingebaut, die die Entwicklung vereinfacht und den Umstieg erschwert haben, bei einigen gab es das ganze auch gleich komplett mit Hardware.

Damals hatten Firmen noch Rechenzentren, in denen Tatsächlich etwas Stand und als Mitarbeiter von einem Startup war es normal, wenn man als Entwickler auch an Racks rumgeschraubt hat, was heute kein Mensch mehr nachvollziehen kann.

Die Kommunikation zwischen den Komponenten war üblicherweise Corba (IIOP) und später dann in der SOA Welt: SOAP.

Wolken

Die Unkalkulierbarkeit des Internets machte aber das Vorhalten von Rechnerressourcen für Peaks ziemlich unwirtschaftlich. Entweder man hatte schrecklich viel Hardware, die dann die meiste Zeit unnütz in der Gegend herumstand oder man konnte sprunghaften Anstieg der Nachfrage einfach nicht bedienen. Mit immer besser werdenden Virtualisierungen, und damit der Möglichkeit, Instanzen schnell zu Klonen, und zunehmend schnellerem Internet, war es somit nur logisch, dass die Internetriesen ihre überschüssigen Kapazitäten verkauften.

Ein Modell, ohne das es viele Startups nie gegeben hätte. Man konnte eine Idee implementieren ohne sich auf kostspielige Hardwarevorleistungen einzulassen.

Die Cloud Integration hat Java EE gehörig verschlafen – naja, nicht wirklich. Ambitionen in der Richtung gab es bereits bei Glassfish 3, ist aber bis heute nicht wirklich sinnhaft umgesetzt worden und steht damit erst wieder für Java EE 9 auf dem Plan. (Jaja, es gibt da Workarounds aber dazu ein anderes mal mehr.)

Microservice Infrastruktur

Statt eines EJB-Jars gibt es im Microservice Docker Container, das Pendant zu EAR wäre wohl ein POD, die Rolle das Java EE Containers übernimmt Kubernetes, Log Management macht meist Logstash, Metriken zB Prometheus, Security kann man mit Keycloak machen, WARs also das Frontend Beispielsweise mit Aglular2. Das ist für so ein bisschen WebShop schon mal ne ganze Menge Holz.

Wie soll man das denn vernünftig aufsetzen und verwalten? Ich meine, in der guten alten Zeit hab man sein Komponenten mit maven gebaut, in arAchiva veröffentlicht und dann im gleichen build, alle anderen Komponenten gealden, zu einem EAR verschnürt und gleich auf einen Testserver deployed. Für Microservices gibt es da natürlich auch was: zB. Fabric8. Und ja, das ist jetzt auch nicht so schlank für eine komplette Umgebung – aber zu Zeiten von J2EE (1.4)  war so ein AppServer auch ein ziemliches Dickschiff auf dem Notebook.

Also im Großen und Ganzen vom Konzept her erstmal nicht so revolutionär das alles. Statt IBM oder BEA hängt man halt jetzt an Amazon, Microsoft oder Google, statt für Rechenzentren zahlt man für Cloud Provider und statt Admin Abteilungen hat man halt DevOps. Bleiben zwei entscheidende Fragen: Warum sollte ich mir das antun? Und wenn ja, wie? Dazu dann im nächsten Beitrag mehr.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.