Microservice as a Pattern
by Gregor Elke
- Hallo und Willkommen!
- Danke fürs kommen!
- Als erstes möchte ich mich vorstellen
Gregor Elke
@greelgorke
Ich bin Gregor Elke
Im Internet, vor allem auf twitter und github bin ich @greelgorke
JavaScript - Node.js
Leichtgewichtige Architekturen
Reactive Apps
- ich bin IT-Berater und Entwickler bei der codecentric
wir haben einen Stand, zwischendurch kann man mich dort auch treffen
- bei der codecentric verfolge ich vor allem die Themen JavaScript und speziell Node.js,
- ich interessiere mich für leichtgewichtige, verteilte Softwarearchitekturen
und reactive Anwendungen.
meetup.com/node-hh
- daneben organisiere ich die Hamburger Node.js User Group
- wer Interesse hat, kann uns über meetup.com finden.
Agenda
- Was sind µServices
- Essenz als Muster
- früh Entscheiden - spät Umsetzen
- Hilfe der Altvorderen
- Aber heute geht es hier eher weniger um Node.js sondern um Microservices als Muster.
Und darum, wie man dieses Muster so einsetzt, dass es uns hilft, ohne unbedingt Services zu bauen
- Wer ist hier wegen
dem Track JavaScript? Oder Node.js? Etwas davon habe ich auch.
Wegen Microservice?
- es wird von allem etwas geben, aber vor allem:
Disclaimer!
alter Wein in neuen Flaschen voraus!
- Einiges an altem Wein in neuen Flaschen.
- Ja Flaschen! Wir haben 2014, nicht wahr :) ?
Alter Wein ist O.K.
- Aber das ist OK.
- Alter Wein ist meistens ein guter
Das Auge trinkt mit
- Und das Auge trinkt bekanntlich mit
Es ist, was wir tun
- Und das ist eh das, was die meisten von uns jeden tag machen:
- Alten Wein in neue Flaschen abfüllen.
Was sind µServices?
- Was sind eigentlich Microservices?
- nun es gibt keine einheitliche Definition, aber viele Meinungen.
- Lasst mich euch einen kurzen unkommentierten Eindruck gewähren:
Just SOA
2-Pizza-Teams
An architectural style
An App in 10-100 LoC
An independent component that can be rewritten in one week.
µServices sind
- SOA, aber anders
- klein, aber nicht wegen der Größe
- ein Stil, und bald ein Muster
- diese Aussagen stimmen alle irgendwo und irgendwie
- Es wird noch viel geredet und geschrieben, ich bin auch hier.
- aber für mich ist interessanter zu sehen: was kann ich damit tun
- wie kann ich es einsetzen.
- ich versuche mich jetzt zuerst an einer unvollständigen Abgrenzung zu klassischer SOA
- weil ich es für hilfreich halte um zu verstehen, warum µServices überhaupt einen eigenen Namen tragen.
µServices vs. Services
Fokus
Integration vs. Dekomposition
- µServices haben grundsätzlich eine andere Zielsetzung als ein klassischer WebService nach SOA
- in klassischem SOA versuchen wir monolithische Applikationen in eine Systemlandschaft zu integrieren
- oftmals kapselt ein klassischer SOA-Service eine Systemkomponente mit einem definierten Set technischer Verantwortlichkeiten
- z.B. ein DataStore, eine BI Unit, ein Discovery Service etc.
- Das Ziel ist, einzelne Dienste in einem Gesamtprozess systemweit verfügbar zu machen.
- Strukturierung der Systemlandschaft steht im Fokus.
- Ein Microservice hat dagegen das Ziel der Entkopplung der Applikationskomponenten.
- Dabei wird die Anwendung in Komponenten zerlegt, die unabhängig von einander lauffähig sind.
- Es geht hierbei nicht um Wiederverwendung. Im Gegenteil. Selbst wenn die Komponenten technisch entkoppelt sind,
sind sie es logisch nicht. die Gesamtanwendung würde ohne einzelne dieser µServices zwar lauffähig sein, aber nicht unbedingt Ihren zweck erfüllen
was aber ok ist.
- Der Fokus der µServices liegt in der Reduktion der Komplexität der einzelnen Komponenten
- Die These hierbei ist: kleine, entkoppelte Komponenten lassen sich schneller entwickeln, leichter warten und problemloser ersetzen
- Dieser Unterschied im Fokus ist wichtig.
µServices vs. Services
Einteilung
Stories vs. Abteilungen
- Wie bereits erwähnt streben SOA-Architekturen eine Integration an. Dabei wird oft infrastrukturell gedacht und oftmals vorhandenen Dienste als Boxen angesehen
- Die Einteilung der einzelnen Services wird dabei an den Grenzen dieser Boxen gezogen.
- Der Fachliche Besitzer der Box, der oftmals eine Abteilung ist, spielt eine wichtige Rolle.
- Das Ergebnis ist dann oft ein Netzwerk aus in sich monolithischen Gebilden, eine Silo Area.
- Ein µService dagegen hat als Primäraufgabe, die Komplexität der Komponenten zu reduzieren und die Komponenten voneinander zu entkoppeln.
- Dies wird oftmals dadurch erreicht, dass ein µService jeweils eine Fachliche Anforderung im Sinne einer agilen UserStory oder eines Use Cases abbildet
- Dabei wird eine Komponentengröße nicht in physischen Metriken wie LoC oder Classes gemessen
- Sondern in kognitiven bzw. organisatorischen wie z.B.
"handhabbar durch ein kleines Team" oder "Begreifbar mit wenigen Seiten Code".
- die 100 LoC Regel zielt eben auch auf das Kognitive ab. Kurzer Code ist einfacher zu verstehen.
- Die Verantwortung für ein Microservice hat das Entwicklerteam allein.
- Nach Conways Law spiegeln Systemarchitekturen die Organisationen, die sie bauen.
- µService-basierte Architekturen sind sehr flexibel, so sind es auch die Organisation, die sie erschaffen
- weil die Verantwortlichkeiten sehr feingranular auf Teams und nicht Abteilungen verteilt sind. Und kleine Teams sind anpassungsfähiger als Abteilungen.
- Daher kann das Streben nach µService-Architektur auch eure Organisation verändern.
- Als Leitlinien für die einteilung, das schneiden der Services, halte ich übrigens die Prinzipien SR und SoC für sehr wichtig.
- Wenn wir unsere Applikationen so scheiden entstehen Services, die sehr kleine Verantwortlichkeiten haben z.B. Ausliefern semi-statischer Inhalte,
Nutzerauthentifizierung, Ausliefern eines Suchergebnisses.
- Dann haben diese Komponenten nur wenige Endpoints, oftmals nur einen, und hängen von nur wenigen weiteren Services ab, und lassen sich
besser und einfacher isolieren.
µServices vs. Services
Kommunikation
MQ vs ESB
- Als dritten Aspekt hier möchte ich die Kommunikationsmuster erwähnen.
- wer denkt bei SOA an ESB? SOAP? XML?
- das sind oft mittel der Wahl in klassischen SOA Landschaften. RESTful ist immer noch sehr neu.
- µServices nutzen, und sie müssen es Aufgrund ihrer Größe und ihrem Fokus, leichtgewichtigere Formen.
- REST und verstärkt Message Queues, mit JSON-formatierten Nachrichten.
- µServices kommunizieren meistens asynchron
- Gemeinsam jedoch haben beide Servicearten, dass sie einen Kontrakt haben, der die Schnittstellen und das Nachrichtenformat definiert.
µServices vs. Monolithen
- Entkopplung
- Autonomie
- Async
- Messaging
- die µServices sind jedoch nicht der "Natürliche Feind" von WebServices oder SOA, sondern von monolithischen Architekturen
Wir können µServices in klassische SOA-Landschaften integrieren
- Mit µServices versucht man jedoch die Schwächen in der Entwicklung monolithischer Anwendungen zu beseitigen.
- Anstatt einzelne Funktionalität immer wieder neu in eine monolithische Plattform zu integrieren, können µServices entkoppelt vom Rest des Systems entwickelt und ausgerollt werden.
- Sie können jederzeit angepasst und in beliebiger Sprache neu geschrieben werden.
- Sie können unabhängig vom Rest der Applikation beobachtet und skaliert werden.
- ein kleines Team ist in der Lage direkt dafür Verantwortung zu tragen, das dieses Teilsystem lebt.
µServices vs. Monolithen
- Infrastruktur
- Entwicklungsprozesse
- Tools
- Latenz und Partition
- Doch wie man sich denken kann, ist das Gras hier nur teilweise grüner, auch µServices kommen mit einem Preisschild
- Das wichtigste ist: Die Komplexität der einzelnen Komponenten wird zum Preis der Kompexität der Infrastruktur reduziert
Statt ein Paket in ein AppServer zu deployen, muss man nun mehrere Kleinstapplikationen verwalten, überwachen, ausrollen und skalieren
Das stellt ganz andere Anforderungen an den Betrieb, und man kommt um das Thema DevOps eigentlich nicht herum
- Die Entwicklungsprozesse spielen eine entscheidende Rolle. µServices kamen zuerst dort auf, wo kleine Teams
zu weiten Teilen autonom und entkoppelt agieren. Teams verantworten den gesamten Lebenszyklus eines Services, von Konzeption bis Betrieb.
Womit wir wieder bei DevOps sind.
- Ein berechtigter Einwand gegen µServices, ist die mangelhafte Toolunterstütztung. Kaum ein modernes Tool unterstützt debugging von verteilten Systemen.
Unsere IDEs sind auf Monolithen oder nur wenige Services ausgelegt. Doch die Tool-Unterstützung ist nur eine Frage der Zeit, wie ich glaube.
Und manches, was wir im Monolithen debuggen würden, müssen wir bei µServices nicht mehr, weil sie so einfach sind.
- Die Latenz dagegen, wird immer bleiben. Die Laufzeit-Charakteristik eines im-prozess-Methodenaufrufs ist sicherlich sehr anders
als ein asynchroner Nachrichtenaustausch über Entfernung.
Eine Netzwerkverbindung kann viel eher kaputtgehen und zu Fehlern führen. Man muss ständig mit einem Fehlschlag rechnen.
- Erstaunlicherweise ist genau diese Einschränkung, die zum positiven Effekt führt, dass µService-Basierte Anwendungen
in der Regel resistenter gegen Ausfälle sind. Wir rechnen mit dem Schlimmsten und sorgen vor.
- Und durch asynchrone Kommunikation machen wir keine Annahmen darüber wie schnell eine Antwort kommt.
Erst wenn Latenz wirklich wichtig wird, müssen wir aktiv werden und optimieren.
Mehr zu µServices
http://microservices.io
- Mehr zu Microservices als Stil und die Varianten dessen möchte ich hier nicht sagen. Details könnt ihr z.B. auf dieser
Webseite finden. Sie bildet einen guten Einstieg.
Muster
- gleichbleibende Struktur
- erlaubt gleichförmige Wiederholung
- kann in verschiedenen Instanzen erkannt werden
- Bonus: benennt ein Konzept
- Stattdessen möchte ich µServices als Muster betrachten.
- was macht ein Muster aus, was muss es haben um als solches zu gelten?
- Ein Muster ist eine Struktur, eine Blaupause, die fest ist, entweder via Standarditisierung oder Konvention
- Es wird als Grundlage für Reproduktion genutzt
- Man kann durch Anwendung bestimmter Taxonomien Muster in scheinbar unterschiedlichen Instanzen wieder erkennen
- Und weil wir alle Design Patterns kennen, oder auch nur davon gehört haben, schätzen wir die gemeinsame und konsistente Namensgebung,
die Muster mit sich bringen.
- dem Microservice Begriff fehlt allerdings noch die Struktur, es gibt noch keine allgemein akzeptierte.
µService als Muster
- viele Spielarten, wenig Konsens
- gemeinsamer Nenner
- alter Wein, neue Flaschen
- Node.js flavor
- Wir könnten nun versuchen alle möglichen Spielarten zu untersuchen und alle Gemeinsamkeiten herausstellen und Konsens zu finden.
- Oder wir versuchen den kleinsten gemeinsamen Nenner zu finden und daraus ein Muster abzuleiten.
- Ich glaube das zweite führt eher zu Brauchbarem, und das habe ich versucht.
- Es gibt inzwischen einige Versuche den Begriff zu greifen, durch namhafte Akteure und weniger bekannte Anwender.
Ich konzentrierte mich auf nur wenige.
- Und zusätzlich dazu bin ich überzeugt, dass die aktuellen µServices ganz sicher alte Paradigmen Muster und Prinzipien wiederverwerten.
- Wir versuchen sozusagen, den alten Wein zu erkennen und diesen in die neue Flasche zu füllen.
- Und da ich aus der Node.js Ecke komme, habe ich ein Prise Node Gewürz hinzugenommen.
Unix Philosophy
Schreibe Computerprogramme so, dass sie- nur eine Aufgabe erledigen und diese gut machen.
- sie zusammenarbeiten.
- Textströme verarbeiten, denn das ist eine universelle Schnittstelle.
- Die Unix Philosophie ist schon recht alt, und gilt als eine der Erfolgsmodelle.
- Wer schon mal auch nur eine Pipe benutzt hat, hat von dieser Philosophie profitiert.
- Unix Programme sind kleine Werkzeuge die meist mit Standardinput und output arbeiten und sich mit Pipes kombinieren lassen
- Unix Pipes kann man als primitive Nachrichtenkanäle ansehen, Unix Domain Sockets sind Nachrichtenquellen und Nachrichtenempfänger.
Node Modules
Schreibe Module so, dass sie- nur eine Aufgabe erledigen und diese gut machen.
- sie zusammenarbeiten.
- Events verarbeiten, denn das ist eine universelle Schnittstelle.
- Streams sind ein Strom gleichartiger Nachrichten
- Die Unix Philosophie erfährt weitreichende Adaption in der Node.js Community, aber es gibt natürlich Unterschiede
- Node.js bringt gleich drei Arten von Interfaces mit. doch wir brauchen nur eines hier: Streams.
- Node.js nutzt Unix Domain Sockets für IPC und ein prozess-orientiertes Model für Parallelisierung.
- Aus dieser Konsequenz ergibt sich, dass man relativ einfach Prozesse unterschiedlich lokalisieren kann, mal auf der selben Maschine,
mal am anderen Ende der Welt.
µServices sind Node.js Module? Echt?
- Isoliert und Autonom in Prozessen
- Eine Aufgabe bzw. Verantwortlichkeit
- Events-basiert, somit asynchron
- Mit Streams als Schnittstellen, austauschbar
- lapidar gesagt: Microservices sind Node.js Module in jeweils eigenem Prozess
- zu einfach um wahr zu sein?
- Möglich.
OK! Node.js eignet sich wohl gut um µServices zu bauen.
Aber wo ist hier das Muster?
- Zumindest ist es für mich ein Hinweis, dass Node.js eine gute Plattform sein kann um µServices zu entwickeln.
- Doch wo ist hier das anwendbare Muster?
- Lasst uns die Aussage von eben umformulieren: Node.js Module bestimmter Ausprägung sind Microservices im selben Prozess!
module.exports = function( readable, resolve ){
var out = resolve('otherMicroClient')()
readable.on('readable', function( message ){
var res = doSomething(message)
out.write(makeMessage(res))
})
}
- Wenn ich ein Modul so entwickle, dass
- es seine Abhängigkeiten abstrakt hinter Streams gekapselt erwartet
- grundsätzlich Asynchronität voraussetzt
- und keine sonstigen Annahmen über die Umgebung trifft
kann ich sehr spät entscheiden, ob ich eine Microservice-basierte Architektur anwenden will oder nicht.
- Meine Module schreibe ich somit immer so, als ob es Microservices sind, wie eben definiert.
- Wie könnte nun der Code aussehen, der den Service letztlich einbindet?
var myMicro = require('myMicro')
var microIn = new PassThrough({objectMode:true})
myMicro(microIn, resolveFunc)
http.createServer(function(req,res){
createMessageFromHTTP(req, function(message){
microIn.write(message)
})
})
- In-Prozess Beispiel mit HTTP input.
var myMicro = require('myMicro')
var microIn = require('someMQClient')()
myMicro(microIn, resolveFunc)
- Oder mit MQ-input.
var myMicro = require('myMicro')
var microIn = require('someMQClient')()
myMicro(process.stdin, resolveFunc)
- Eigener Prozess Beispiel mit STDIN input.
Muss ich das selbst schreiben?
- node-seneca
- dnode
- (express)
- roll your own
- wie Service letztlich eingebunden ist, verkommt so zu einem Implementierungsdetail, das man in ein Tool wegkapseln kann.
- Erst hier, beginnt µService als Muster für mich sinn zu machen.
- Es gibt auf NPM bereits Module, die einem dieses Vorgehen erleichtern können
- Die, die Einbindung sogar teilweise zu einem Konfiguratinsdetail machen.
- z.B. nodezoo ist eine Microservice-basierte Anwendung entwickelt mit Seneca.
- in Seneca wurde ein etwas anderer Implementierungsansatz gewählt, statt mit Streams wird hier mit einem RPC Ansatz gearbeitet
- doch von der Idee her ist hier ähnlich: abstrahiere Peripherie definiere deine services als ein set von event-handlern
- dnode ist RPC über Streams. Auch hier lassen sich schnell Microservices einbinden. dnode brint ein eigenes Protokoll mit.
- Expressjs mounted apps, sind ein weiterer Ansatz, wenn man bei HTPP und REST bleiben will.
- Doch zugegeben, es gibt noch einiges zu tun.
Alter Wein zur Hilfe!
- Doch was uns noch weiter helfen kann, ist wenn wir anfangen unser neues Muster zu übersetzen
- Hier nur zwei Beispiele:
µService ~ Aktor
- Akka
- Scala.js
- Eine Logikeinheit mit einer MessageQueue davor? Das klingt wie Aktoren!
- Akka ist ein sehr weit entwickeltes Framework für Aktoren, der die späte Entscheidung über die Topographie meiner Servicelandschaft
durch Konfiguration ermöglicht.
- Es ist ein JVM Framework
- Mit Scala.js gibt es eine portierung für JavaScript.
µService ~ Interactor
- Boundaries ~ Streams
- Totale Entkopplung
- Eine einheit, die ihre sämtliche Peripherie abstrahiert, die Abhängigkeiten entkoppelt und sich auf ein Use Case konzentriert?
- Oncle Bob hat uns von Interactoren, Boundaries und Gateways erzählt.
- Und weil es Oncle Bob war, haben ihm einige zugehört. Und was draus gemacht. Es lohnt sich hier nachzuforschen.
µService ist ein Denkmuster
- hier ist der Knick in meiner Linse. Microservices sind für mich in erster Linie eine Denkschule
- Wie teile ich mein Produkt in Dienste ein? Wie strukturiere ich meine Organisation, wie gehe ich mit Kommunikation,
Änderungen, Support, Betrieb etcetcetc um.
Bonusrunde - Contra Ping Pong!
"aber Gregor, was ist mit?"
- Bonusrunde! Lasst uns den ernst etwas fahren lassen
- Das spiel ist einfach: einer ruft ein aber raus, "aber Gregor, was ist mit?" und ich versuche mich nicht allzu blamieren
und darauf einzugehen.
Was lernte ich daraus?
- Alter Wein schmeckt
- Neue Flaschen helfen
- Mustererkennung ist wichtig
- Muster übertragen und anwenden auch
- Manchmal muss man Conway's Law umkehren.
- nun zum Schluss will ich persönlich werden
- Die ganze Mühe sich durch den Dschungel der Microservices durchzuarbeiten hat sich für mich ausgezahlt
- Ich bin immer noch kein Microservice Experte, aber ich habe gelernt sie für mich einzuordnen
- Ich habe gesehen, wie sehr wir von der Arbeit unserer Vordenker aus der grauen Vorzeit profitieren und dass es
sich immer lohnt zurückzuschauen
- Doch gleichzeitig finde ich, dass es sich lohnt alte Erkenntnisse in neue Kleider, bzw alten Wein in neue Flaschen zu packen
- Es hilft neue Brücken in die Gegenwart zu bauen und abstrakten Konzepten anwendbare Substanz zu verleihen.
- Und manches mal hilft es althergebrachte Muster infrage zu stellen.
- Wenn wir lernen welche Muster und Konzepte es gibt, und wie wir sie in neuem Gewand wiederfinden, können wir Neues
besser und schneller Verstehen.
- Am ende können wir so von getaner Arbeit profitieren. Das ist wahre Wiederverwendung in der Software Entwicklung
- Und fast noch wichtiger für mich: Es hilft dabei sich selbst und die Organisation deren Teil ich bin, zu verändern.
Ratschlag
- lernt was vor euch war
- lernt es einzuordnen
- lernt es zu transformieren
- lernt es infrage zu stellen
- Ich hoffe ich konnte euch etwas mitgeben. Wenn sonst nichts dabei ist
- dann ist das was ich aus dem ganzen zog, und was ich euch ans Herz legen möchte
Danke!
- Danke schön!