Transkript
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.