Transcript

Independent Systems Architecture

Best Practices f├╝r Microservices

Lucas Dohmen redet mit Eberhard Wolff ├╝ber die Independent Systems Architecture (ISA) Prinzipien, eine Reihe von Ans├Ątzen, um Microservice-Systeme aufzubauen. Dabei geht es nicht nur um die Architektur, sondern auch um die Entwicklung und den Betrieb. Alle Materialien stehen unter einer Creative-Commons-Lizenz auf Github bereit und k├Ânnen so frei wiederverwendet werden.

Back to episode

Transcript

Lucas Dohmen: Hallo und herzlich Willkommen zu einer neuen Folge des INNOQ-Podcasts. Heute habe ich zu Gast Eberhard. Hallo, Eberhard!

Eberhard Wolff: Hallo, Lucas, hi!

Lucas Dohmen: Wir wollen heute ├╝ber die independent system architecture sprechen, auch kurz ISA genannt, und dazu habe ich mir Eberhard eingeladen. Aber bevor wir damit loslegen: Eberhard, wer bist du und was machst du bei INNOQ?

Eberhard Wolff: Ich bin Fellow bei INNOQ. Meine Schwerpunkte sind Consulting-Sachen, Trainings und B├╝cher schreiben, Artikel schreiben, solche Geschichten. Weniger Projektarbeit.

Lucas Dohmen: Alles klar. Und was ist ISA und wozu braucht man das?

Eberhard Wolff: ISA ist ein Ergebnis davon, dass man da drau├čen sehr viel von Microservices spricht und irgendwie gar nicht so klar ist, was eigentlich Microservices genau sind oder was so das Minimum dessen ist, was man ben├Âtigt, um eine Architektur wirklich eine Microservices-Architektur zu nennen. Und das ist das, was wir mit den ISA-Prinzipien versucht haben, mal aufzuschreiben. Das ist ein Ergebnis von sehr vielen internen Diskussionen, die wir auf INNOQ-Events gef├╝hrt haben, aber dann auch noch an anderen Stellen. Mit denen sind wir dann irgendwann losgegangen und haben gesagt: Okay, das hier sind die Prinzipien, die wir als Minimum einer echten Microservices-Architektur ansehen.

Lucas Dohmen: Und ist die Idee jetzt so, dass das alle Sachen umschlie├čt, die ihr schon als Microservices gesehen habt, oder w├╝rdet ihr auch explizit sagen, ihr habt Sachen gesehen, die Leute als Microservice bezeichnen, die ihr aber nicht als Microservice bezeichnen w├╝rdet?

Eberhard Wolff: Das ist ja genau der Grund, warum wir diese ISA-Prinzipzien gemacht haben, um eben zu sagen: Okay, es gibt sicher Leute, die Systeme bauen, die sich Microservices nennen, aber wir glauben, dass das eigentlich sozusagen der falsche Ansatz ist oder irgendwie an bestimmten Stellen falsch gemacht wird oder nicht ausreichend ist. Und das ist genau der Grund, warum wir jetzt ISA-Prinzipien aufgestellt haben und auch einen neuen Begriff daf├╝r gew├Ąhlt haben, um zu sagen: Okay, du kannst das Microservices nennen, aber du kannst es nicht ISA-Prinzipien nennen, weil das nun ein Begriff ist, der klar definiert ist und da gibt es die Webseite und auf der Webseite steht das alles. Das ist so die Idee dahinter.

Lucas Dohmen: Alles klar. Auf der Webseite geht es direkt um den Begriff der Modularisierung. Erst mal: Was verstehst du darunter und welche Rolle spielt das bei der ISA?

Eberhard Wolff: Module sind ja ein sehr altes Konzept. Das ist die Idee, dass ich Software aufteile in verschiedene Module, die ich getrennt entwickeln kann und damit erreicht man zweierlei, durch diesen Begriff. Das eine, was man dadurch erreicht, ist, dass man sich auf diese lange Historie beziehen kann. Man kann jetzt irgendwie sagen: Okay, wir haben Module, das hei├čt low cohesion/high coupling. Also, dass diese Module intern sehr stark zusammenh├Ąngen, aber zwischen den Modulen eine lose Kopplung ist. Das sind Dinge, die sich sozusagen von selbst verstehen, weil es eben Module sind. Oder das Geheimnisprinzip: Dass der Zugriff nur ├╝ber eine klar definierte Schnittstelle kommt. Und das ist einer der Punkte, dass man dadurch in dieser langen Historie steht und bestimmte Dinge einfach ├╝bernehmen kann. Und der andere Punkt ist, dass man damit auch klar sagt, in welchem Mitwettbewerb man steht: Man steht eben im Mitwettbewerb zu anderen Modularisierungsmechanismen, die Systeme aufteilen in packages, namespaces oder wei├č der Teufel was, und dadurch positioniert sich das zun├Ąchst einmal relativ klar.

Lucas Dohmen: Okay. Also du hast jetzt auch schon gesagt, es gibt auch andere M├Âglichkeiten zu modularisieren. Was ist der Vorteil daran, jedem Modul seinen eigenen Prozess oder VM oder Container zu geben?

Eberhard Wolff: Dass ich mich dadurch sehr viel st├Ąrker entkoppeln kann. Normalerweise verstehen wir unter Entkopplung, dass ich eine ├änderung in einem einzigen Modul mache und die anderen Module davon unber├╝hrt sind. Wenn ich jetzt sage, dass ich Module als Docker-Container beispielsweise ausf├╝hre, so wie das die ISA-Prinzipzien tun, dann habe ich eine viel st├Ąrkere Entkopplung, weil ich zum Beispiel diese Module auch getrennt deployen kann. Ich kann jetzt eben einen Docker-Container nehmen und den getrennt von allen anderen in Produktion bringen, prinzipiell. Wenn einer von denen ausf├Ąllt, dann fallen die anderen nicht sofort mit aus. Ich schreibe einen memory leak: Bei dem Docker-Container f├Ąllt halt der Docker-Container aus. Bei einem System, bei dem ich alle diese Module gemeinsam deploye, wird wahrscheinlich das gesamte System ausfallen. Sicherheit: Wenn ich zwischen den Docker-Containern Firewalls habe, dann kann ich von dem einen Docker-Container schwierig in den anderen Docker-Container her├╝berkommen usw. usw. Das hei├čt, dort habe ich an vielen Stellen eine zus├Ątzliche Entkopplung und das ist der Vorteil oder der Unterschied zu den sonstigen Modularisierungsans├Ątzen.

Lucas Dohmen: Was in den ISA-Prinzipzien auch diskutiert wird, ist Mikro- und Makroarchitektur. Bevor wir darauf eingehen: Was verstehst du denn unter diesen Begriffen?

Eberhard Wolff: Mikroarchitekturen sind Entscheidungen, die ich in jedem Modul getrennt von den anderen Modulen treffen kann. Makroarchitektur ist etwas, was ich ├╝bergreifend definiere f├╝r das Gesamtsystem. Ich werde zum Beispiel als Teil der Makroarchitektur vermutlich definieren m├╝ssen, wie diese einzelnen Module miteinander kommunizieren. Aber muss ich festlegen, in welcher Programmiersprache jetzt ein solches Modul geschrieben ist? Nein, das muss ich nicht. Das kann ein Docker-Container sein, darin kann ein Java-Programm sein, darin kann PHP oder Node oder sonst irgendetwas sein, das muss ich nicht unbedingt festlegen. Das k├Ânnte also eine Mikroarchitekturentscheidung sein. Und das ist etwas, was erst durch diese Aufteilung in diese verschiedenen Docker-Container wirklich relevant wird, weil ich dadurch diese M├Âglichkeiten ├╝berhaupt erst einmal habe. H├Ątte ich einen klassischen Modularisierungsansatz, m├╝sste ich wahrscheinlich die Programmiersprache standardisieren. Das muss ich jetzt bei diesem Ansatz nicht mehr.

Das hei├čt also, dass diese Unterscheidung jetzt erst so richtig relevant wird. Und das bedeutet auch in der Konsequenz, dass man eher wenige Makroarchitekturregeln definieren sollte oder muss, weil man sonst den Vorteil dieses Architekturansatzes gar nicht richtig ausnutzt. Also offensichtlich ist mindestens Integration oder so etwas, was ich definieren muss. Aber man muss ich eigentlich noch deutlich mehr definieren? Das ist etwas, bei dem einige sogar sagen, das ist nicht sinnvoll. Also jemals die Implementierungstechnologie zu standardisieren, das ergibt keinen Sinn, weil ich eben dann zu sehr die einzelnen Module festlege und da zu viele Entscheidungen zentralisiert treffe und damit den Vorteil dieser Architektur gerade zunichte mache.

Lucas Dohmen: Aber das bedeutet auch, dass ich als Architekt entscheide, ob etwas eine Mikro- oder Makroarchitekturentscheidung ist, richtig? Also eine bestimmte Frage ist nicht immer eine Mikro- oder eine Makrofrage, sondern ich entscheide, ob es eine ist. Wenn ich jetzt sagen w├╝rde, alle m├╝ssen in Go schreiben, dann w├╝rde ich das zu einer Makroarchitekturentscheidung machen, richtig?

Eberhard Wolff: Ja, aber wie gesagt, es gibt Leute, die sagen, so etwas kann eigentlich keine sinnvolle Entscheidung sein. Und das kann man auch in gewisser Weise nachvollziehen, weil wahrscheinlich in zwei oder drei Jahren jemand um die Ecke kommen und sagen wird: Hey, hier gibt es die neue Programmiersprache, wollen wir die nicht mal ausprobieren und k├Ânnen wir da nicht mal einen Service einbauen. Und wenn man sich dann dazu entschieden hat, sich auf eine Programmiersprache zu standardisieren und vielleicht sogar noch bestimmte Libraries vorzuschreiben, dann hat man sich in eine Ecke begeben und das macht wenig Sinn. F├╝r die langfristige Evolution eines Systems ist so eine Entscheidung eigentlich eine wenig sinnvolle Entscheidung.

Deswegen haben wir eben auch mit den ISA-Prinzipzien versucht zu diskutieren, was denn eigentlich das minimale Set an Makroarchitekturentscheidungen ist, die ich auf jeden Fall auf dieser Ebene treffen muss, also beispielsweise die Integrationstechnologie oder die Kommunikationstechnologie. Das sind Dinge, die ich mindestens als Makroarchitekturentscheidung treffen muss, an der Stelle.

Lucas Dohmen: Okay. Und was sind weitere Dinge, die ich entscheiden muss? Habt ihr einfach ├╝berlegt, das ist unvermeidlich, das muss ich auf jeden Fall entscheiden oder was steckt dahinter?

Eberhard Wolff: Also ein Ding, das sehr sicher unvermeidlich ist, ist Integration: Integriere ich meine Systeme synchron, asynchron oder ├╝ber die UI-Ebene? Vielleicht mache ich es auch auf verschiedene Arten und Weisen, und mit welchen konkreten Kommunikationsprotokollen mache ich das? Tue ich das mit Hilfe von REST oder messaging und vielleicht mit irgendeiner Art von Frontend-Integration? Mache ich das vielleicht nur ├╝ber Links? Das sind Dinge, die ich global definieren muss, weil sonst gar nicht klar ist, wie diese Module zusammengehalten werden. Ich w├╝rde immer argumentieren, wenn ich das nicht standardisiere, habe ich kein System aus Modulen mehr, sondern ich habe Inseln, die da zuf├Ąllig irgendwie miteinander reden. Und da f├Ąllt es schwer, von einem Gesamtsystem zu reden, wenn jede von diesen Inseln mit der anderen Insel ├╝ber irgendeine Art und Weise spricht. Und abgesehen davon w├╝rde mir auch die Komplexit├Ąt an der Stelle explodieren, weil ich dann eben einen un├╝bersichtlichen Zoo habe.

Die andere Sache ist das Deployment. Ich habe bereits gesagt, ein Vorteil dieses Ansatzes ist, dass ich die Module getrennt deployen kann, wenn ich es denn kann. Rein technisch kann ich nat├╝rlich einen Docker-Container herunterfahren und neu hochfahren. Aber wenn ich jetzt in der Continuous Delivery Pipeline, die zu diesem neuen Docker-Container f├╝hrt, Abh├Ąngigkeiten habe, dann geht das vielleicht nicht. Also wenn ich jetzt sage, ich nehme mein System, ich baue alle diese Module, ich baue alle diese Docker-Container, dann teste ich sie alle und dann bringe ich sie alle gemeinsam in Produktion, dann ist das zwar theoretisch denkbar, aber es f├╝hrt dazu, dass ich einen wesentlichen Vorteil, n├Ąmlich das getrennte Deployment, nicht umsetze. Also ist eine Regel, die wir aufgestellt haben, dass das Deployment tats├Ąchlich unabh├Ąngig ist. Wir schaffen durch diese st├Ąrkere Modularisierung die Voraussetzung daf├╝r und sagen dann, dass es auch wirklich umgesetzt werden muss.

Dann sagen wir, dass der Betrieb standardisiert sein sollte. Wir haben mehr Prozesse, die jeweils irgendwie betrieben werden m├╝ssen. Durch die Standardisierung minimieren wir den Aufwand daf├╝r und das ist sicherlich vorteilhaft. Streng genommen ist es nicht notwendig, jedes von diesen Systemen k├Ânnte anders betrieben werden. Wenn ich einen zentralen Betrieb habe, w├╝rde ich so ein Modell auf gar keinen Fall fahren, wo jeder von diesen Services anders betrieben werden kann, weil ich damit einfach diesen zentralen Betrieb ├╝berlaste. Wenn ich aber DevOps-Teams habe, bei denen jedes dieser Teams die Verantwortung auch f├╝r den Betrieb ├╝bernimmt, da ist es so, dass ich diese zentrale Festigung nicht mehr unbedingt treffen muss und genau genommen sollte ich es vielleicht auch gar nicht, weil ich am Ende sage: Okay, so l├Ąuft der Betrieb, also das ist zum Beispiel das Monitoring-Werkzeug, das ihr benutzen sollt, hiermit solltet ihr Log-Analyse machen. So, dann kommt irgendwie das Team um die Ecke und sagt: Naja, unser Problem, das uns gestern zum Ausfall gef├╝hrt hat, das ist ein Resultat dessen, dass wir mit diesem Monitoring-Werkzeug und mit diesem Log-Analyse-Werkzeug dieses Problem nicht analysieren konnten, vorher. Deswegen ist der Ausfall also darauf zur├╝ckzuf├╝hren. Und diese Diskussion will ich eigentlich nicht f├╝hren. Deswegen w├╝rde ich dann dem Team sagen: Naja, ihr seid daf├╝r verantwortlich, dass das funktioniert, ihr seid das DevOps-Team, ihr baut nicht nur die Software, sondern ihr betreibt sie auch, dann solltet ihr auch die Technologien daf├╝r ausw├Ąhlen. Ich w├╝rde erwarten, dass dann doch eine Standardisierung kommt, weil sich die Teams am Ende wahrscheinlich auf irgendwelche Technologiestandards einigen werden, um den Aufwand gering zu halten, aber ich w├╝rde es nicht mehr unbedingt erzwingen.

Lucas Dohmen: Das hei├čt also, du r├Ątst mehr dazu, dass die Leute quasi Guidelines geben, aber nicht so richtige Regeln daf├╝r.

Eberhard Wolff: Ja, best practices, und es ist auch so, dass ÔÇŽ Wie gesagt, ich will einfach nicht die Diskussion: Ich kann nicht auf der einen Seite sagen: Ihr seid daf├╝r verantwortlich, dass es in Produktion l├Ąuft, und auf der anderen Seite sage ich: Hey und das ist die Technologie, die ihr in Produktion benutzen m├╝sst. Man kann nicht die Verantwortung daf├╝r ├╝bernehmen, dass etwas in Produktion vern├╝nftig l├Ąuft, wenn man nicht die Technologien ausw├Ąhlen darf. Rechte und Pflichten m├╝ssen sozusagen in einem vern├╝nftigen Verh├Ąltnis sein, das ist genau der Punkt hier.

Lucas Dohmen: Okay, aber es ist auch denkbar, die ISA-Prinzipzien umzusetzen, wenn man einen zentralen Betrieb hat.

Eberhard Wolff: Ja. Dann w├╝rde ich einfach die gesamten Sachen, die der Betrieb haben will ÔÇô also: wie deploye ich das, wie monitore ich die Sachen, wie funktioniert die Loganalyse ÔÇôals Makroarchitekturregeln definieren. Und ich finde, das ist eigentlich genau einer der Vorteile, den dieser Ansatz bietet: Dass ich da sehr konkret definiert das mal niederschreiben kann, was denn nun wirklich die Sachen sind, die daf├╝r notwendig sind, um etwas in Produktion zu bekommen, und dadurch dieses Verh├Ąltnis zwischen Betrieb und Entwicklung halt auch klar formalisieren kann.

Lucas Dohmen: Hm, okay. Und was geh├Ârt noch zur minimalen Makroarchitektur dazu?

Eberhard Wolff: Eine Sache ist, dass wir sagen, dass diese Standards, f├╝r den Betrieb beispielsweise, genauso wie alle anderen Sachen eigentlich nur die Schnittstelle eines Microservices oder eines Moduls betreffen sollten. Also grunds├Ątzlich ist modulare Entwicklung ja so, dass wir sagen, dass die Module untereinander nur ├╝ber die Schnittstellen aufeinander zugreifen, sodass ich die Interna des Moduls ├Ąndern kann. Das bedeutet f├╝r den Betrieb, ich sollte sagen: Bitte schicke deine Log-Nachrichten auf folgende Art und Weise in unser Log-Analyse-System. Also ├╝ber syslogd beispielsweise, um etwas ganz Klassisches zu nennen. Oder schreibe ein Log-File in einem bestimmten Format oder was auch immer.

Was ich nicht tun sollte, ist, zu sagen, benutze bitte diese Library, weil ich damit nicht mehr die Schnittstelle definiere, sondern die Interna des Moduls beeinflusse und eben sage, hier soll diese Library bitte benutzt werden. Und das durchbricht zum einen Modularisierung und zum Anderen torpediert es auch einen Vorteil dieses Ansatzes, dass ich technologieunabh├Ąngig bin. Dass ich, auch wenn ich heute alles in Go schreibe, in ein paar Jahren mit irgendeiner anderen Programmiersprache etwas umsetzen kann. Wenn ich die Libraries standardisiert habe, dann kann ich das nicht tun. Und das ist genau der Grund, warum wir sagen, dass diese Regeln alle nur die Schnittstellen umfassen sollen. Und dann geht es noch um Resilience: Ein Microservices-System sollte so aufgebaut sein, dass ein Microservice, wenn er ausf├Ąllt, keinen anderen mit sich rei├čt, weil ich sonst ein zu hohes Risiko habe, dass das Gesamtsystem ausf├Ąllt. Das gilt auch dann, wenn der Microservice irgendwie heruntergefahren wird und irgendwo anders neu gestartet wird. Also in einem Cluster kann so etwas durchaus mal passieren und dagegen muss das System auch abgesichert sein, dass es von einem Knoten auf einen anderen Knoten verschoben wird. Und das ist das Resilience-Thema: Das ist auch etwas, das ein Microservices-System sozusagen als Minimum erf├╝llen muss, um den ISA-Prinzipzien zu gen├╝gen.

Lucas Dohmen: Okay. Was jetzt vielleicht den ein oder anderen ├╝berrascht, der das h├Ârt, ist, dass in dem ganzen Teil weder ConwayÔÇÖs-Law noch Domain-driven Design vorkommt. Ist das eine bewusste Entscheidung, denn das sind ja irgendwie Buzzwords, die einem doch immer begegnen, wenn man ├╝ber Microservices spricht.

Eberhard Wolff: Ja, das ist eine bewusste Entscheidung, weil wir eben die rein technischen Grundlagen aufschreiben wollten daf├╝r, wie so ein System aussehen kann oder aussehen sollte. Und die fachliche Aufteilung ist davon getrennt. Also, nat├╝rlich ist eine Aufteilung nach Domain-driven Design und Bounded Context eine sehr gute Idee, das f├╝hrt zu einem sehr gut entkoppelten System. Aber ist ein System, das dem nicht Gen├╝ge tut, immer noch ein ISA-System? Ja. Ja, das ist so. Also, auch wenn ich eine vergurkte Architektur habe, kann sie immer noch den ISA-Prinzipzien gen├╝gen. Wie die fachliche Aufteilung ist, ist davon eben unabh├Ąngig, und auch die organisatorischen Themen sind keine Themen, die wir jetzt hier diskutieren. Es ist nat├╝rlich so, dass durch diese Mikro-/ Makroarchitekturaufteilung, durch diese starke Entkopplung gro├če Teams Vorteile generieren, aber bei vielen unserer Kunden ist es auch so, dass es sehr kleine Teams gibt, die trotzdem Microservices machen und die ISA-Prinzipien umsetzen, und das ist f├╝r mich auch v├Âllig in Ordnung. Und aus dem Grund haben wir da ganz bewusst diese Themen ausgenommen.

Lucas Dohmen: Und auch die ganzen Themen wie zum Beispiel: Es muss auf jeden Fall ├╝ber HTTP kommunizieren usw., das ist bewusst ausgeklammert, um das breit aufzustellen?

Eberhard Wolff: Genau. Also, wir sagen ja, es muss einen Standard geben f├╝r eine Kommunikation, aber welcher das denn konkret ist, das bleibt sozusagen dem Anwender ├╝berlassen. Und es ist ja auch denkbar, das Systeme ├╝ber ein Messaging-System miteinander reden und gar nicht ├╝ber HTTP. Das ist nat├╝rlich auch m├Âglich, ohne weiteres.

Lucas Dohmen: Okay. Gibt es denn einen Zusammenhang zwischen ISA und SCS, also Self-contained Systems? Weil sich da ja auch die Autoren so ein bisschen ├╝berschneiden?

Eberhard Wolff: Self-contained Systems ist die Idee, die im Wesentlichen sagt: Wir bauen unabh├Ąngige Webanwendungen und bauen dar├╝ber das System auf. Self-contained Systems sagt deswegen schon einmal eine ganze Menge an Dingen: Also zum Beispiel, wir bauen eine Webanwendung - das muss ja nicht unbedingt der Fall sein, bei ISA k├Ânnten wir auch irgendetwas bauen, was einfach nur ein REST-Interface implementiert oder nur ├╝ber Messaging nach drau├čen erreichbar ist. Das w├Ąre ohne weiteres machbar. Self-contained Systems sagt dann in der Folge, dass man in erster Linie Frontend-Integrationen nutzen sollte, dann asynchrone Kommunikation, dann synchrone Kommunikation, das sind Priorisierungen. Das sagt ISA nicht. ISA sagt nur, es muss irgendwie einen Standard geben, was auch immer der ist, das ist dann dem jeweiligen Projekt ├╝berlassen. Und Self-contained Systems trifft auch eine organisatorische Aussage und sagt, jedes Self-contained System muss einem Team geh├Âren. Das bedeutet, ein Team ist zust├Ąndig f├╝r ein oder mehrere Self-contained Systems, aber kein Self-contained System wird von mehreren Teams bearbeitet. Das sind alles Dinge, die in ISA sozusagen nicht drin sind. Also insofern ist das spezieller.

Interessanterweise ist es so, dass Self-contained Systems nichts sagen ├╝ber Mikro-/Makroarchitektur. Die Definition selber enth├Ąlt diese Begriffe gar nicht, obwohl das de facto oft etwas ist, was in Self-contained Systems auch als Begriff benutzt wird und sicher de facto auch ein wichtiger Bestandteil davon ist. Insofern w├╝rde ich sagen, dass Self-contained Systems ├╝blicherweise ein Sonderfall von ISA sind und ISA ist eben ein ├ťberbegriff. Das war ja auch genau das Ziel, zu sagen: Wir definieren, was ist das Minimum, was Microservices erf├╝llen m├╝ssen, und Self-contained Systems sind ein Sonderfall von Microservices und dementsprechend auch ├╝blicherweise ein Sonderfall von den ISA-Prinzipien. Deswegen passt das, glaube ich, soweit alles ganz gut zusammen.

Lucas Dohmen: Okay. Und sind diese Regeln, die jetzt auf dieser Seite stehen, in Stein gemei├čelt und unver├Ąnderlich? Oder kann man daran noch etwas ├Ąndern, wenn man da zum Beispiel irgendetwas anders sieht als die Autoren?

Eberhard Wolff: Ja, genau. Es gibt isa-priciples.org, darin stehen die ganzen Prinzipien und da ist oben so ein Link, da ist genau genommen so eine GitHub Octocat, und das ist der Link zu dem GitHub-Projekt. Da kann man Issues einstellen und da gibt es auch gerade Diskussionen. Ein Issue, der zum Beispiel eingestellt worden ist von einem Kollegen, ist die Frage: Bei Kommunikation sagt ihr halt, dass Autorisierung auch etwas ist, was eigentlich standardisiert sein muss, wenn ich mehrere Systeme habeÔÇŽ Wenn ich mehrere ISA-Microservices habe, die gemeinsam ein System abbilden, dann m├╝ssen sie eben auch untereinander Informationen ├╝ber den aktuellen Benutzer austauschen, also die Authentifizierungsinformation. Und das ist etwas, das wir jetzt nur in der Kommunikation drin haben als Unterpunkt, vielleicht will man das zu einem eigenen Punkt machen. Es gibt einen anderen Issue, der irgendwie sagt, dass vielleicht Kommunikation und Integration doch eher zusammengeh├Âren, und von daher freuen wir uns da auch ├╝ber weitere Issues und Themen, die dort verbessert werden k├Ânnen oder ge├Ąndert werden k├Ânnen und auch ├╝ber pull requests auf dem GitHub-Projekt. Wir haben dort auch ein paar Committer, die bereits Typos identifiziert haben und Erweiterungen gemacht haben usw. Von daher ist das halt ein offenes Projekt, bei dem jeder eingeladen ist, sich daran zu beteiligen.

Lucas Dohmen: Und das bedeutet auch, dass ich das frei verwenden kann in meinen internen Firmenpr├Ąsentationen oder wie funktioniert das?

Eberhard Wolff: Ja, es ist so, das Ganze steht unter Creative Commons Attribution Share-Alike. Das hei├čt, man kann die ganzen Sachen benutzen. Man muss eben sagen, wo man es her hat und sie entsprechend selber unter einer ├Ąhnlichen Lizenz weiterverwenden. Das gilt f├╝r die Webseite: Auf der Webseite gibt es auch eine Pr├Ąsentation. Die Pr├Ąsentation gibt es als PowerPoint zum Herunterladen, die ist auch in der Webseite integriert und damit kann man herausgehen und die Prinzipien dann auch darstellend diskutieren und auch in eigenen Pr├Ąsentationen benutzen. Das ist genau die Idee, da eine Idee, ein Konzept vorzustellen und es dann den Menschen zu erlauben, sich daran zu beteiligen und das entsprechend selbst f├╝r die eigenen Projekte und die eigenen Ideen zu benutzen und auch anzupassen.

Lucas Dohmen: Okay, super. Dann danke ich dir f├╝r diese ganze Vorstellung. Ich hoffe, dass sich ein paar Leute dann mit der Seite besch├Ąftigen und auch ein bisschen Feedback geben.

Eberhard Wolff: Ja, das w├╝rde mich auch auf jeden Fall freuen. Vielen Dank f├╝r deine Zeit und f├╝r die vielen Fragen.

Lucas Dohmen: Gut. Und dann den H├Ârern: Bis zum n├Ąchsten Mal beim INNOQ Podcast. Auf Wiedersehen.

Eberhard Wolff: Tsch├╝ss.