Skillbyte Podcast #13: CoreMedia CMS - Entwicklung und Betrieb

Willkommen zum Skillbyte-Podcast! Skillbyte ist Ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: CoreMedia CMS - Entwicklung und Betrieb

// Inhalt //
00:57 -> Definition: CoreMedia CMS - was ist das?
04:03 -> CoreMedia vs. Wordpress
05:45 -> Mächtigkeit und Flexibilität
08:26 -> CoreMedia Government Site Builder
09:33 -> Zusammenfassung: Was ist CoreMedia
10:02 -> CoreMedia Komponenten
12:24 -> Deployment und Komponentenverwaltung
13:43 -> CoreMedia Content Cloud
14:05 -> CoreMedia Continuous Deployment
14:55 -> Docker + Kubernetes Erleichterungen für die CoreMedia Entwicklung
18:37 -> CoreMedia Dokumentation
19:39 -> Was ist im CoreMedia Paket? (Dokumentation, Blueprint)
22:10 -> CoreMedia Customizing richtig gemacht / Upgradeability bewahren
25:56 -> Gute Releasestrategie, Schlechte Releasestrategie
27:27 -> So gehen moderne CoreMedia Releases
31:13 -> Synchronisierung von Code und Content
33:32 -> Wo geht die CoreMedia Reise hin?
36:57 -> CoreMedia als Headless CMS
38:35 -> Die Geschichte des CoreMedia Studio
41:37 -> CoreMedia, was können wir besser machen?
43:18 -> Der Blick in die Glaskugel

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

AUTOMATISCH ERZEUGTES TRANSKRIPT

Herzlich willkommen im Skillbyte Podcast Nr. 13 Kompetenzteams, moderne Entwicklung und Betrieb. Heute sprechen wir über das Content Management System Media und ich bin heute hier wieder mit Masiar. Hallo Masiar, freut mich, dass du wieder da bist.

Ich freue mich auch.

Ja, ich freue mich insbesondere, da du ja ein ausgewiesener Comedia Experte ist. Mit wie viel Jahren Erfahrung? Ich weiß es gar nicht.

Ich weiß es auch nicht. Ich glaube auf jeden Fall über 10 15 Jahre.

15 Jahre bestimmt. Ich hätte jetzt noch mehr gedacht. Ja, es wird ein sehr interessantes Gespräch. Heute bin ich mir sicher für unsere Zuhörer, wenn Sie mehr zum Thema Comedia und dessen Betrieb hören möchten, auf jeden Fall dranbleiben. Gerne auch den Podcast abonnieren und wenn Fragen aufkommen sollten, gerne ein E-Mail an Podcast Skillbyte senden. Wir freuen uns immer auch über Bewertung des Podcasts, je nachdem, wo er uns gerade zuhört bei Soundcloud, dieser iTunes, Apple Podcasts oder ähnlichem. Ja, ich würde ganz gern beginnen, dass wir kurz noch mal sagen, was Comedia ist. Also viele Leute, die uns zuhören, werden das wissen. Ich denke, es schadet nicht, wenn wir kurz noch mal darauf eingehen. Comedy ist ein Content Management System und Content Management bedeutet im Internet Content, also Text, Bilder Musikdateien in verschiedenen Nutzungs Szenarien anzuzeigen, also auf einer mobilen Website, auf einer Browser Website, in einer App als PDF für den Druck exportiert usw. Oder Content können auch Artikel sein, beispielsweise bei Webshops. Das könnte, dann könnte man auch von Content Management sprechen.

Die Artikel, Beschreibungen, Bilder und so weiter. Ich versuche den Leuten das immer so ein bisschen zu erklären, weil die kennen meistens WordPress und ach ja, WordPress. Da schreib ich Text rein und kann ihn auf einer Webseite veröffentlichen. Im Grunde ist ein Content Management System ist so eine Art WordPress, wobei es natürlich noch viel, viel mehr Aufgaben unter der Motorhaube übernehmen kann. Bei Comedia das Besondere also was unterscheidet jetzt beispielsweise ein einfaches CMS WordPress von dem Enterprise Grade CMS wie Comedia Comedia ist sehr feingliedrig. Also die einzelnen Komponenten oder die einzelnen Funktionen werden mit einzelnen Diensten abgewickelt, die Suchfunktion, das Editieren von Texten, die Auslieferung Seite hinterher. Und bei WordPress ist das alles zusammen in einer Komponente untergebracht. Und dadurch, dass man diese feingliedrige Aufteilung hat bei Comedia kann man es viel besser skalieren. Also man kann eine Suchmaschine haben oder drei Suchmaschinen oder fünf Suchmaschinen, je nachdem wie viel Last man hat und wie viele unterschiedliche Suchmaschinen man verwenden möchte, um einfach zwecks Skalierbarkeit und Redundanz. Natürlich kann von den Suchmaschinen auch eine dann ausfallen.

Ist es besser da mehrere Dienste zu haben? Das ist bei einfachen CMS Systemen nicht immer der Fall. Hast du noch was anzumerken, was ich zum Thema CMS sagen könnte oder was du sagen kannst?

Ja, es gibt sehr viele Comedia sagte es ist ein Enterprise Content Management System und dementsprechend ist es auch komplex, muss man ehrlicherweise sagen. Es ist Java basierend auf und zwar auf dem Spring steckt. Das ist sehr sehr, sehr mächtig und sehr flexibel, aber auch entsprechend komplex zu implementieren und zu betreiben, weil es, wie du schon sagtest, aus sehr, sehr vielen verschiedenen feingliedrigen Diensten besteht. Als Beispiel Es wird komplett gebaut mit Maven und es hat über 150 Maven Module allein und es kommt mit sehr vielen Extensions, also Personalisierung, User Management Suche und sehr viel mehr komplexen Projekten, die auch teilweise separat zu lizenzieren sind. Also man muss, weil ich sage das jetzt extra anfangen, weil ich auch Kunden erlebt habe, die die Komplexität komplett unterschätzen.

Absolut.

Und sich im Prinzip so die meisten kennen irgendwie WordPress, die haben sich das irgendwo installiert oder kennen das von Bekannten und sehen, wie einfach das ist und sind dann verfallen in Schockstarre. Wenn sie plötzlich einem Comedia gegenüberstehen und kleine Features entwickelt haben, wollen die dann irgendwie Tage Wochen dauern. Es ist halt einfach mega komplexes System und null zu vergleichen mit einem System wie WordPress.

Ja, WordPress ist ja im Prinzip eine fertige, also eine natürlich erweiterbar da Open Source Software. Aber du hast ja alle Funktionen, hast du ja schon in einfacher Grundfunktionen implementiert. Na dann eben erweiterbar über Plugins und bei Comedia kriegst du ja so einen Baukasten, den du erst mal aus diesen 150 Modulen. Also kein Kunde setzt alles ein oder nie. Jedenfalls nicht bekannt. Baust du dir ja erst mal deine Installation zusammen mit den Komponenten, die du eben verwenden möchtest.

Genau, genau ein anderes Ding. Was dazukommt ist, wenn ich mich für so ein CMS. Scheide muss mir auch bewusst sein, dass so und so nett es ausschaut in Marketing Präsentation und ich sage mal das was als Demo gezeigt wird und so weiter. Ich brauche auch die Ressourcen, die das können und umsetzen. Das ist dann ist meine Intention. WordPress arbeitet sich kann man relativ schnell Ergebnisse erzielen und dementsprechend geht das alles relativ fluffig von der Hand. Und hier brauche ich tatsächlich a Java Entwickler, die Java können und b natürlich das Comedia noch haben. Und die gibt es halt auch nicht wie Sand am Meer, weil ähnlich wie alle Entwicklungs Ressourcen im IT-Sektor. Das muss einem Bewusstsein ist einem das alles bewusst, dann kriege ich wie ich schon sagte mit Comedian sehr mächtiges flexibel Tool an die Hand.

Ja, gerade Mächtigkeit und Flexibilität sind glaube ich die Stärke, weil Comedia ist natürlich auch dadurch, dass es in so vielen unterschiedlichen Kontexten eingesetzt wird. Viel, also viele Nachrichtenseiten benutzen, dass die Bundesbehörden benutzen das zu einem großen Teil. Ja, muss man es sehr. Ich will jetzt nicht sagen verbiegen, aber man muss es sehr vielseitig sein, damit es auch diese unterschiedlichen Content Kanäle eben ideal unterstützen kann. Und natürlich, der eine hat 1000 Besucher auf der Webseite am Tag der für den reicht ein Server bei so einer Nachrichten Webseite. Da hast du ja sehr sehr wenige Leute, die Inhalte generieren, also die Redakteure und ganz ganz viele Konsumenten, die millionenfach dann auf diese Nachrichten Website vorne aufschlagen. Und das ist natürlich ein ganz anderer Use Case, der dann den man dann auch nur über einen mit einer entsprechend hohen technischen Komplexität abfangen kann.

Genau. Also allein schon, wenn man nur das Thema Caching mal mal sich vornimmt, was gerade bei hoch frequentierten Seiten der Fall ist. Meistens hast du, wenn du auch noch global unterwegs bist hast und zu der davor, dann hast du in Comedia selber drei Kachin Layer auf die Komplexität anzuspielen und und jedes funktioniert ganz anders. Das ist sehr komplex für sich und sich Gedanken zu machen, so ein Konzept zu machen, was technisch, was eigentlich nicht alles zu kennen ist auch nicht gut, weil weil Cash kann auch teuer werden. Also das alleine ist schon ein Thema, was irgendwie sehr viele Ressourcen bindet. Nehme meine hoch frequentierte Seite.

Ja und du hast halt immer diese dieses Thema. Also was wo auch wirklich Business Entscheidungen dranhängen kann ich eher viel. Das heißt aber auch, dass wenn auf einer Nachrichtenseite der Redakteur einen neuen Artikel veröffentlicht, dann dauert das halt einige Minuten, bis der sozusagen vorne ist erscheint. Das will man aber nicht immer, zum Beispiel bei einem Live-Ticker zu einem Ereignis. So, da möchte ich ja eher wenig quatschen, weil die Änderungen sofort nach vorne sich auswirken sollen. Das heißt, du hast halt irgendein Mechanismus, der, wenn ein Artikel aktualisiert wird oder ein Content Element aktualisiert wird, der dann die Cases in validiert und in allen möglichen Ausprägungen man dann eben schauen muss, dass man genau den Use Case trifft. Teilweise hat man auch konkurrierende Use Cases innerhalb des gleichen Systems, die man dann wieder ausbalancieren muss. Genau das kann man alles machen mit Comedia dabei WordPress einfach mal raus, glaube ich. Kann man so sagen. Genau. Oder man hätte dann mehrere WordPress Installationen für einen Use Case und würde die unter so einer Dach Seite zusammenfassen oder so.

. Ja, das ist das was man vielleicht noch sagen. Von der Geschichte her gibt es noch den Comedia Government Zeit Bilder. Das war eine Komponente, die wurde entwickelt, die hat bis vor der Version 10 seit der Version 10 ist der Government Builder Open Source. Man kann ihn sich einfach im Internet herunterladen. In früheren Versionen hat er auf Comedia aufgesetzt. Das heißt die Bundesbehörden hat eine Comedia Installation gehabt und obendrauf dann diesen Government Leitbilder, der dann eben von einem Baukastensystem gesprochen, der sehr flexibel ist, aber der dann auf diesem Baukastensystem schon mal so eine Art von Konfiguration für Abläufe getroffen hat, die in Behörden eben vorkommen oder die Sinn machen, wenn man so möchte. Man hat dann, wie ich überlege, wie man sich das vorstellen kann, also noch eine Stufe obendrauf hat man Comedia schon so konfiguriert, dass es sinnvoll möglichst einfach für Behörden einsetzbar ist, sowohl aus der Redakteurs Sicht? Also Redakteure sind für mich alle Personen die in ein CMS Inhalte einstellen, bildet Bilder, Texte usw. als auch aus der Nutzer sicht vorne raus, weil Behörden eben Anforderungen haben an gewisse Standards zur Barrierefreiheit, die dann natürlich auch unterstützt werden müssen.

Noch mal zusammenfassend Comedia ist ein großes komplexes Enterprise CMS, was natürlich dann auch zu gewissen Komplexitäten führt, bei der Entwicklung oder beim Betrieb. Und das ist ja unser Kernthema heute. Und von daher freue ich mich, dass ihr da einfach mal drüber sprechen können, was du da vielleicht für Probleme erlebt hast in der Vergangenheit und wie die in der Vergangenheit gelöst wurden und welche modernen Lösungen es. Genau diese Probleme heute gibt, um Comedia betreiben zu können, braucht es mehrere Komponenten. Du hast einmal einen Content Server, wo der gesamte Content gespeichert wird. Dahinter steckt eine Datenbank. Da kann man wählen, ob das MySQL oder oder Apostrophe oder Oracle ist. Dieser Content Server da vorgelagert ist eine Web Applikation genannt Studio, mit der Redakteure Content erstellen können. Dann das ist die reine Erstellung Komponente Helm und dann gibt es eine Auslieferung als Komponente. Das fängt mit dem sogenannten Master Live Server an. Das ist ein Hub, der quasi mitbekommt, dass im Content Server Content erstellt worden ist. Der nimmt sich dann diesen Content und verteilten Content auf beliebig viele Live Server und diese Live Server ist im Prinzip eine Replik von dem Content Server.

Das heißt der Content wird vom Content Server weiter nach rechts geschoben auf diese Live Server und davon kann es beliebig viele geben, je nachdem wie viel Last ich verteilen muss und wie viele IDs ich habe.

Diese Skalierbarkeit um diese Skalierbarkeit Rechnung zu tragen.

Genau und vor diesem Live Server das ist kann man sich vorstellen, dass es eine Standalone Komponente mit wiederum der Datenbank dahinter und davor ist. Dann wiederum ein Spring Boot Applikation genannt Sea Eye Content Application Engine. Und das ist die Auslieferung des Komponente. Das sind die Hauptkomponenten. Und dann gibt es noch entsprechend ein Such sauber, das ist ein Soler. Dann gibt es Content ider die mitbekommen, dass Content erstellt worden ist und diesen Content dann automatisch Richtung der Soler schieben und dort editieren. Dann gibt es noch eine Menge DB für für User relevante Daten. Und all diese Komponenten müssen irgendwie zusammenspielen. Die kommunizieren untereinander über das Korber Protokoll. Das ist recht oldschool, ist ein bidirektionale Protokoll, steht voll und das ist sehr reell, liebe und ist aber oldschool. Das heißt, ich hab da teilweise Probleme bei den Firewalls. Da muss ich gewisse Ports öffnen, dafür sorgen, dass die Connections permanent da sind und so weiter und so fort.

Ich glaube, in den neueren Versionen soll das auch über HTTP einfach abgelöst werden. Also das Rest Calls wird dann durchgeführt werden, aber ich kann nicht sagen, ob das schon released ist oder ob Korber noch benutzt wird.

Nein, noch nicht. Also auch in der neuesten Applikation wird noch Korber benutzt. Okay, worauf ich hinauswill ist, dass diese Komponenten auch in einer bestimmten Reihenfolge gestartet und gestoppt werden müssen. Das bedeutet, dass Deployment der Betrieb dieser dieser ganzen Form ist relativ kompliziert und meistens hast du das ja nicht nur einmal für Produktion, sondern dass es einmal für Entwicklung. Dann ist es vielleicht einmal für Staging und hast dann vielleicht drei Umgebungen, die alle verwaltet werden müssen. Und im Grunde früher war das so, dass du diese Standalone Applikation für sich die bloed hast die Wahl Dateien für die CIA zusammengebaut, das abgetippt erläutert. In den neueren Versionen kann dann irgendwann einen ein Chef dazu. Das heißt Comedia der Scripte mitgegeben, die dieses ganze Deployment automatisiert haben und wir tatsächlich die Skillbyte. Einer der ersten, die das Ganze auf Docker und Kubernetes geschoben haben, ist das Wir haben diese ganze Komponenten gescriptet, automatisiert und in Docker Container verpackt. Das heißt, wir waren in der Lage, diese ganze Infrastruktur und Zuhören und Comedia kennen, wissen, dass es teilweise Tage und Wochen gedauert hat, bis man diese diese Infrastruktur aufgebaut hat.

Und wir haben das so weit runter automatisiert, dass du quasi innerhalb einer halben Stunde eines Tages komplett aufbauen konntest. Inzwischen ist es selber so weit, hat also auch Docker und Kubernetes manifestiert. Es gibt auch eine Content Cloud von Comedia mal einem nicht so ganz flexible Variante, wo ich aber keine Infrastruktur brauche, sondern das quasi als Cloud Dienst von Comedia kaufen kann und ohne mich selber mit der Infrastruktur Betrieb auseinandersetzen zu müssen. Und das setzt auch auf Docker und Kubernetes auf das Comedia selber geht in die Richtung. Und weil der der Hintergrund ist gerade ich sage mal, wenn man ein Medienunternehmen nimmt, was Newsportal zum Beispiel betreibt, dann muss man viele Dinge schnell ausprobieren. Du willst ein neues Feature einführen, du willst Animate Tests machen? Ist eine lange Headline, eine kurze Headline? Gut, welches performt besser? Und um diese ganzen Features schnell testen zu können, muss natürlich auch deine Devotees Pipeline oder diese die Kette entsprechend aufgebaut sein und mit einer Infrastruktur oder mit Systemkomponenten wo du was bauen musst und Tomcat die müssen und so weiter geht es natürlich nicht ganz so schnell von der Hand, als wenn du auf eigene Füße gestellt hast, sprich Kubernetes.

Und damit ist es möglich, diese schnellen Deployment mehrmals am Tag machen zu können. Das sind so die Herausforderungen beim Betrieb. Wie gesagt, auch nicht ganz unkompliziert, aber machbar.

Ja, du hast es eben schon gesagt, bis eine Umgebung eine. Umgebung mit eben diesen ganzen Content Servern, Replikation, Servern, Suchverfahren und Auslieferungsverfahren hochgefahren ist, konnte sehr viel Zeit vergehen. Diese Komplexität hat meiner Ansicht nach dazu geführt, dass auch in der Entwicklung die Entwicklung von Comedia ist. Ja jetzt auch. Ich will jetzt nicht sagen behäbig, aber der Round Trip ist einfach sehr groß, wenn er Feature entwickelt. Bei den meisten Komponenten, wenn wir ein Feature entwickelst, was jetzt über die Komplexität hinausgeht, dass man HTML Änderungen an irgendeinem Modul durchführt, sondern wirklich, sagen wir mal eine Cernko Komponente anpasst, dann hat man immer das Problem Okay, ich baue jetzt einmal durch, dann rollig die aus, dann teste ich die in der Testumgebung und dann erst sehe ich das Ergebnis so. Das heißt, dieser typische Zyklus etwas probieren, angucken, Erkenntnisgewinn, nächstes Ding probieren und so weiter ist relativ schwerfällig. Und durch eben diese Komplexität des Systems ist es bei mir immer so gewesen, dass in den Teams, in dem ich gearbeitet habe, ist halt ein, maximal zwei Testumgebung gab von Comedia und auf der haben alle Entwickler gearbeitet.

Das heißt, du hast nicht nur den Fall, dass du quasi nur selber einen sehr langsamen Roundup hast Entwicklungs Roundup, sondern du teilst ja auch diese Ressource mit dem ganzen Team. Und wenn du zum Beispiel du hast an dem Such Index was verändert und muss die neuen Elemente. Also löscht den alten Such Index möchte spielt seine Änderung ein und muss jetzt die Elemente neu finden lassen, also in den Index aufnehmen und jemand anders arbeitet gerade an einer dynamischen Liste. Also eine dynamische Liste ist zum Beispiel Zeig mir die Top 5 Mais geknickten Artikel und die ändern sich natürlich im zeitlichen Verlauf, die Suche aber leer ist. Die dynamischen Listen basieren ja auf der Suche, dass du demjenigen dann blockiert hast oder dass es immer wieder dazu kam, dass sich die Entwickler gegenseitig auf die Füße getreten sind, weil sie zeitgleich nicht mal an einer Komponente geschraubt haben, aber an Komponenten, die sich gegenseitig bedingen. Ja, und das war bei der Entwicklung problematisch. Wenn du jetzt natürlich sagst, mit der Docker Kubernetes Installation könnte man im Prinzip kann sich jeder Entwickler seine eigene Entwicklungsumgebung hochfahren, dann könnte man ja da auf jeden Fall schon mal ein Geschwindigkeits Vorteil erzielen.

Definitiv.

Was es noch gab von Comedia war ja diese. Das war auch ein Maven Script, wo man sich dann lokal auf der eigenen Maschine eine komplette Comedia Installation hochfahren konnte. Die war dann so boxt in so einer VirtualBox oder bei mir hieß das System und ist meiner Ansicht nach ist dann auch ist der Run da auch sehr groß gewesen, weil halt einfach die dieses komplexe Comedia System auf dem lokalen Rechner schon dem Rechner ganz schön runter reißt oder ihn in die Knie zwingt und man auch da nicht so schnell vorankommt und man dann doch wieder auf der allgemein zugänglichen Testumgebung landet.

Ja genau das müssen halt irgendwie 5 6 Dienste laufen. Server laufen lokal plus eine Masiar SQL plus eine Soler ist das schon eine Menge für so ein kleines für einen kleinen Rechner. Aber es ist machbar. Also was ich damals entwickelt habe, hatte ich lokal auch alles auf einem Rechner. Und ich sage mal, wenn du einen Rechner mit 16 Gigabyte schnell CPU hast, kannst du einigermaßen arbeiten. Natürlich nicht mit dem ich Daten mit großen Datenmengen, aber im kleinen Rahmen geht das auch.

Man muss auf jeden Fall, also bei so einem komplexen System versteht es sich von selber, dass man auch die Workstation, auf der man arbeitet, leistungsfähig ist, damit man einfach schneller vorwärts kommt. Eine weitere Schwierigkeit bei der Entwicklung von Comedia liegt darin, dass das System ja Closed Source ist, ja ein proprietären ist. Ich glaube, man kommt an die Sourcen ran von Comedia selber, wenn man danach fragt, aber prinzipiell ist ist es nicht frei verfügbar und es der Kunde muss es, der Endkunde muss es sozusagen kaufen oder lizenzieren. So, das heißt, du hast natürlich ganz wenig Hilfe im Internet bei Fehlermeldungen über Allgemeines bring Fehlermeldungen. Die findest dann natürlich bei Stack Overflow, aber nichts Comedia spezifisches, aber ganz ganz wenig. Das heißt, dass nur die Dokumentation von Comedia, die ist schon einigermaßen umfangreich, aber natürlich behandelt die meistens nur einen Beispielfall, der jetzt nicht unbedingt auf deinen Anwendungsfall passt. Das heißt, zusätzlich zu diesen langen Entwicklungs Round Chips und den geteilten Ressourcen im Entwicklungsteam kommt noch, dass man sehr viel ausprobieren muss, weil man gar nicht so viel Dokumentation hat.

Und dieses Problem verschlimmert sich dadurch noch. Und die Kubernetes oder dieser Betrieb wird noch wichtiger.

Es ist tatsächlich so, dass man vielleicht dazu sagen, was passiert, wenn ich es Comedia kaufe und damit starten will. Du bekommst Zugang zu einem zu GitHub Repo von Comedia und da kannst du eine Art es nennt sich Blueprint Workspace herunterladen oder klonen. Und in diesem Blueprint, also was man kauft ist. Sie ist mehr oder weniger ein Framework, das heißt, was du dann vor dir hast auf deinem Rechner, ist wenn du intelligent als Java Idee benutzt, hast du ein Projekt mit eben diesen erwähnten 160 Modulen Helm so oder fühlst du dich erst mal erschlagen, weil du weißt gar nicht, was diese einzelnen 160 Projekte alles bedeuten und die sind auch nicht im Einzelnen erklärt. Also gerade werden wir sehr viel mit Medien oder großen Projekten arbeitet. Da weiß genau wovon ich rede. Eine Hölle an Dependency und Abhängigkeiten. In welcher Reihenfolge muss ich was bauen wie Staaten? Was bedeuten diese ganzen Projekte? Und das es tatsächlich in der Doku nicht beschrieben, also mehr oder weniger. Du kommst ohne Consulting, egal ob ich es dann comedia oder von externen Beratern.

Kannst du nicht selber einfach mal so loslegen, weil es mega komplex ist und hinzu kommt wenn du was falsch machst? Also nehmen wir mal als Beispiel an, du hast die Internationalisierung ein globales Projekt starten. Da muss ein Dokument Modell definieren. Das heißt, du musst im Vorhinein sagen Okay, ich habe einen Artikel, der die und die Properties und da gibt es noch eine Vererbung Struktur gerade für die Internationalisierung. Für die Translations gibt es auch in diesem Dokument Modell Strukturen. Wenn du da was falsch machst, dann kommst du davon nicht mehr los, dass du entwickelst Content was dann aufbaut auf diese Dokumenten Struktur aufgebaut hast. Und wenn das falsch ist, dann kannst du das nicht einfach mal so umbauen. Eigentlich ist das auch eine Schwachstelle von Comedia, dass es kein vernünftiges on boarding gibt für für ich sage mal Firmen, die da selber die ersten Schritte machen wollen. Du bist halt angewiesen auf Berater und kann nur raten, die sind in Anspruch zu nehmen, sei es jetzt eine Schulung oder externe Leute an Bord holen. Also in diesem Blueprint sind die Best Practices mit drin.

Was Comedia über die letzten 10 15 Jahren in verschiedenen Projekten gelernt hat, haben sie dort eingebaut. Als Beispiel Wenn du diesen Blueprint Nutzen verstanden hast, dann brauchst du zum Beispiel keine Galerie mehr selber zu bauen, weil es da mit drin ist. Internationalisierung ist mit drin, wenn du es richtig machst, wenn du willst. Personalisierung ist mit drin. Du musst nur im Studio gewisse Regeln beachten. Also vieles kommt mit diesem Blueprint mit. Das kannst du mitnehmen. Jetzt kommt aber du willst das, du willst es an deine Geschichte anpassen. Und auch hier habe ich gemerkt, dass das viele Kunden oder viel Diskussions oder Beratungsbedarf gibt, weil wenn du anfängst in diesem Blueprint rumzumachen, das heißt in einem direkten Code, was von Comedia kommt und anfängst, Dinge umzubauen oder in falschen Ordnern zu bauen im falschen Leben Modul, dann wird das Update schwierig, weil die funktionieren Updates bei Comedia. Es gibt einfach eine neue Version in GIZ und wenn du dann viele Dinge umgebaut hast, dann kannst du einfach nicht mehr in Pull machen, weil dann gibt es Merch, Konflikte.

Das heißt, du musst auch wissen, wie du innerhalb dieses Blueprint entwickelst, nämlich in Form von Extensions, dass du alle Code Änderungen in eigenen Modulen hast, unmöglich die von Comedia gelieferten Komponenten unangetastet lässt, damit wie gesagt Updates später einfacher gehen, weil ich habe es ganz oft erlebt, dass ein ein Upgrade von dir keine Ahnung 5, 6 oder 7 auf immer sehr sehr viel Pain war ohne Megaprojekt für sich, weil gerade wegen dieses Problem, was ich erzählt habe. Seine Kunden haben sehr viel im PIN-Code rumgemacht und das war quasi fast nicht mehr Upgrade. Bei manchen Projekten muss ich sogar Kunden raten. Ich glaube, es ist einfacher das ganz frische Blueprint zu klonen und die ganzen gemachten Änderungen diesmal richtig als Extension reinzuziehen.

Mit der Update Baccarat ist das natürlich auch so eine Sache. Ich wusste nicht, dass man wirklich so allein gelassen wird von Comedia. Ich hatte schon gedacht, dass sie so ein on boarding Prozess haben. Aber ja, es ist auch meine Erfahrung, dass du bekommst ja diesen Baukasten und entwickelst den für deinen Use Case und irgendwann geht jeder. Also klar, du hast da noch Comedia und dieses Dokument Typ Modell, von dem du eben sprachst. Das ist natürlich ein ganz zentraler Punkt. Das entwickelt auch jeder individuell für sich. Jeder hat eine Comedia Installation, aber es gibt keine zwei gleichen Comedia Installationen auf dem Planeten, weil einfach so viel individuell da dran geschrieben wurde. Und natürlich, wenn jeder Zeiten von regelmäßig auftretenden Sicherheitslücken muss man natürlich diese Security Fixes machen und man muss auch die Versions, also die großen Versions Sprünge bei Comedia mitmachen. Muss man natürlich irgendwo updaten, damit man nicht aus dem Support herausfällt und das bindet manchmal für einen längeren Zeitraum die Hälfte oder noch mehr der Entwicklungs Kapazitäten von den Teams. Das habe ich auch so erlebt und ich habe es mal in einem Projekt erlebt, wo das Update also das Update sieht dann so aus, dass das einige, also es werden Ordnerstruktur und umbenannt verschoben, zumal da jetzt die Schlagzahl an Releases erhöht hat.

Das heißt die findet schneller statt und da scheuen sie sich auch nicht zurück so komplette Ordnerstruktur hin und her zu schieben. Da hast du bei einem Update was rein auf gibt basiert keine Chance mehr. Launische Kunden gesehen, wo in einem. Workspace Artefakte von über drei oder vier verschiedenen Major Versionen enthalten waren und das ist natürlich tödlich. Wenn du dann noch mal Major Upgrade auf eine ganz neue Version machen willst. Irgendwann ist Schluss und dann hast du ein Riesenprojekt technische Schulden mitgenommen, die dann aufgelöst werden müssen. Dann bist du schnell bei Magna nur in Updates und hast zusätzlich noch verstehst. Immer von der Fragestellung entnehme ich, dass die frische Version und bring meinen Content und meine Erweiterungen da ein oder nehme ich meine vorhandene Version und bringe das Update da rein, nur um dann nach dem Update ist vor dem Update wieder da vorzustellen und es ist tatsächlich bei Comedia nicht so. Also bitte liebe Kunden, macht euch das bewusst, wenn ihr hier zuhört. Wir sprechen immer von man Monaten und Jahren bei bei Comedia Projekten heißt das Budget sollte ausreichend dimensioniert sein, die Comedia in Erwägung zieht.

Also es ist nichts für kleine Unternehmen, sondern es ist definitiv ein Experten System für Großunternehmen, die idealerweise ein Team haben aus mehreren Entwicklern, die sich ausschließlich um das System kümmern können und man direkt beim nächsten Thema und natürlich auch von Administratoren, die sich um den Betrieb kümmern. Also ich weiß, dass wir ein Wir waren ja auch mal in Projekten, wo man abenteuerlichsten Releases gefahren hat nachts um 4 einfach wirklich per Hand per bash die Dienste gestoppt, die neue Version des Dienstes ausgerollt, wieder hochgefahren, geguckt ob es funktioniert hat. Und das hat man dann für alle Maschinen nach und nach gemacht, auf der das System installiert war. Und das denke ich, ist ja auch da ist man heute weit von weg mit der Kubernetes Infrastruktur, die eher schon eingesetzt hat. Auch bei anderen Kunden ist es ja dann wirklich so, dass man klickt und das System rollt diese einzelnen Änderungen aus, fährt die Dienste runter entweder zu einer Last Zeit oder man. Dadurch, dass die Dienste mehrfach vorhanden sind, merkt man gar nicht, dass jetzt gerade ein Dienst aktualisiert wird.

Gerade auch diese alte Methode von Hand Roll Backs war natürlich ein Horror, wenn man festgestellt hat nach einigen Stunden Oh, hier gibt es ein ernsthaftes Problem, wir müssen da irgendwie ran. Das war wurde alles manuell gemacht. Also ist es menschlich sehr belastend alleine spätnachts Software Releases zu einem Produktionssystem zu machen. Aber auch ist es da einfach ein hohes unternehmerisches Risiko, das auf diese Art und Weise zu tun. Wie würde das denn heute gemacht werden? Also ich stelle mir das so vor der Mann würde es nicht mehr bauen auf die Maschinen installieren, sondern auf jeden Fall in so einem Kubernetes Cluster vielleicht mit Rancher aufsetzen. Die einzelnen Dienste dann da eben Provisionen auf die einzelnen Ports und dann den ganzen Roll out so durchführen, dass man das im Grunde einmal auf einem geklonten Cluster oder in Staging Umgebung durchspielt, falls das überhaupt noch nötig ist. Wenn man schon diese Sicherheit des Kubernetes Clusters hat es kommt, es kommt auch wieder in die Primats stattfinden. Also wenn du viel in der Serie machst, sprich Typekit änderst, Java Code änderst, dann ist es recht trivial, diese Serie neu zu bauen, on the fly zu duplizieren, ohne das Downtime entstehen und so weiter.

Wenn du allerdings Content Änderungen hast, sprich Dokumenten, Modell Änderungen, dann ist das schon eine andere Sache, weil dieses Dokument Modell Änderungen betreffen, die diese Hauptreihe selber nicht erwähnt hat. Der Content Server, Master, Live Server und Replikation als Server und vielleicht auch die Suche oder weitere Komponente, vielleicht auch die Suche. Genau, exakt. Dann bist du ganz schnell dabei, die komplette Kette zu duplizieren und dann musst du auf Reihenfolgen achten. Also du kannst, du musst zuerst die in den Dokumenten Änderung, sondern du musst den Content Server diplomen und dabei musst du aber zusehen, dass wir mit dem Master, also den Content Server mit den neuen Dokumenten Struktur haben, die ein bisschen hochgefahren hast. Dann kennt der Master Server diese Dokumente Server Änderungen, Dokumenten, Modell Änderung noch nicht. Sprich du musst ein Abschalten, denn ein Hochfahren warten bis der eine da ist und den anderen die planen. Und diese Reihenfolge ist nicht ganz trivial, weil dann kannst du dir auch den Content zerschießen und dann hängst du. Da fahren die Server nicht mehr hoch und dann ist Party.

Deswegen ist das sehr sehr wichtig, dass man dann halt gewisse Reihenfolgen und so weiter einhält. Das heißt, du musst mit den Kubernetes Jargon gesprochen mit Helm helfen, realness Props arbeiten, die dann Kaste schmeißen, damit sie zu diesem Case passen. Da gibt es ein paar Tricks, die man anwenden kann. Das haben wir übrigens auch für für ein, zwei große Kunden so gebaut. Das funktioniert wunderbar.

Okay, und die müssen dann nur noch in ihrer Skillbyte die Pipeline auf den Knopf drücken und spielen das neue Release aus. Wobei ich mir vorstelle wahrscheinlich je nach Release gibt es unterschiedliche Knöpfe. Also so ein Key Webserver Release wird immer noch einen anderen Release dran haben als so eine große Dokument Typ Änderungen, die ja im Grunde alles Services. Und die ja fast nicht ohne Downtime kannst du das denn nicht durchführen?

Also bei Comedia ist es ja so, dass du, wenn du zum Beispiel der Content Server nicht läuft oder der Masiar Live Server nicht läuft laufen, dann wird Content immer noch ausgeliefert vom Replikation Live Server, also von vorne. Insofern ist schon eine gewisse Entkopplung da, die du auch für Releases und die Planens ausnutzen kannst. Was aber hinzukommt, das ist die eine Komponente, die technischen Server, Strukturen mit Kubernetes, Docker und so weiter zu planen. Das andere ist meistens entwickeln die Entwickler Features auf einem Development Server. Das heißt ich leg mir dort Content an, mache die Dokumenten Typ Änderungen, wenn es welche gibt dort mache mein Code in dieser Umgebung und lege Content und Inhalte, Konfiguration, Settings usw. Diese Struktur von ich sage mal Settings und Dokumenten, die werden teilweise auch natürlich notwendig auf dem Server. Das heißt, da gibt es, da habe ich bis jetzt noch keine STANDARD Lösung gefunden. Es gibt ein paar Ansätze, wo ich all diese Content Strukturen nachbauen package und die als Paket. Ich sage mal von einem DF in Produktion bringen, damit es dort die Redakteure direkt nutzen können.

Es ist halt nicht nur mit diesem technischen Server Komponenten getan, bei denen die Formen, sondern ganz ganz ganz oft braucht es dort auch diese Content Strukturen und Settings, die dann dort auch überspielt werden müssen. Da bauen meistens die die Kunden sehr eigene Lösungen, teilweise händisch, teilweise automatisiert mit ganz unterschiedlichen Ansätzen.

Bei einem Content Management System muss natürlich der Code zum Content passen. Wenn du aus einer exakt exakt Realistin 5 Liste machst, dann musst du zwei Bilder einhängen oder zwei Elemente einhängen. Und das muss halt. Das ist eine weitere Herausforderung. Das natürlich der Code. In dem Moment, wo der neue Code vorne läuft, der jetzt fünf Bilder braucht muss. Auch im Content müssen dann eben diese fünf Bilder eingegangen sein. Da muss ich sagen, geht es mir wie dir, da habe ich auch noch keine elegante Lösung gesehen. Was man der Erfahrung nach wie das gehandhabt wird, ist meistens, dass die Entwickler eine Komponente dann so gestalten, dass sie rückwärts kompatibel ist. Also dass die Komponente drei Bilder anzeigt, wenn sie drei Bilder sieht in einem Content Objekt und wenn sie fünf Bilder sieht, dann zeigt sie fünf an. Oder du hast doch ein Setting an diesem Content Objekt dran mit du sagst zeigt nur drei oder zeigt nur fünf, dass du quasi erst mal den neuen Code ausrollen kannst, kann aber noch mit der alten Content Struktur arbeiten und dann schaltest du die neue Funktion sozusagen.

Wenn neuer Content und neuer Code ausgerollt wurden, schaltest du dir erst an, dass du nicht sofort dir was kaputt machst. Richtig? Das habe ich auch oft gesehen, aber wirklich elegant ist das natürlich nicht, weil man da sehr aufpassen muss. Content zu synchronisieren ist aber nicht unbedingt ein einfaches Thema. Ja genau, weiß nicht auf dem Entwicklungs System, das wird ja dann immer älter. Das ist auch so eine Sache. Meistens wird der Content dann von dem Live System nicht auf das System zurück repliziert, weil es erstens viel zu viel Content ist und der Produktionssystem ist natürlich alles drin. Manchmal ist es rechtlich nicht zulässig, dass man alle Informationen aus dem Produktionssystem irgendwo anders noch mal in einem Testsystem speichert, wo alle dann mit Admin Zugriff jedes Feld auslesen können. Das sind so die Nickeligkeiten, die man hat, aber das ist ja schon mal gut zu wissen, wenn man dann verschiedene Release Trades hat, um eben schnell reagieren zu können. Was glaubst du, wo geht die Reise hin? Bei Comedia glaubst du, dass die Kunden das den besser beraten wird.

Wenn sie sagen wir nehmen dieses Cloud Angebot an, dann haben wir mit der Update Rei nichts mehr zu tun. Aber sind Feature limitiert oder?

Also ganz ehrlich, ich habe auch einen Kunden oder zwei glaube ich erlebt, die gesagt haben wir haben keinen keine Lust mehr auf diese Update Geschichten, weil es immer so viele Ressourcen frisst und haben dann zu einem anderen Content Management System Switch. Wobei ich nicht weiß, ob sie da besser fahren, dann finden sie vielleicht andere Probleme haben, aber tatsächlich ist das halt ein Problem. Wobei es damit zusammenhängt, dass man halt nicht wusste, wie man die Entwicklung macht und dann in diese Hölle reingeraten ist, die ich eben erwähnte, dass der Code einfach nicht mehr tragbar ist. Nichtsdestotrotz haben die Kunden das halt als Problem empfunden und haben dann halt ein anderes System gewählt. Ich glaube, dass das die Architektur relativ festgefahren ist und man so leicht nicht mehr davon wegkommt oder man Jahre, also Comedia seitig das auf andere Füße zu stellen finde ich jetzt allerdings auch nicht so schlimm. Also wie gesagt, wenn man gewisse Sachen einhält und weiß, dann wird das Leben einfacher. Die Reise bei dir geht denke ich Richtung einem einem System hin, wo du per API Content aufrufen kannst.

Weil der Trend ist halt, dass man sein eigenes Frontend Framework wie React, Angular, WU oder was auch immer nimmt und dann einfach nur Content. Zeigen will und dafür braucht es kein Template im System von Comedia, dafür braucht es nicht unbedingt Serie, sondern ich brauche halt ein System, wo ich mir so ein Objekt Store, ja wo ich gegen eine API gehen kann und dort mein Konto Typekit und dann zeige ich sie in meinem selbstgewählten Framework von den Framework an. Da wird die Reise, glaube ich.

Du hast gerade eben gesagt, die Kunden wechseln dann zu Konkurrenz Systemen. Die Frage wäre ja, wie lösen die Konkurrenz Systeme? A Das Problem, dass Content und Code nicht zusammenpassen. Ich meine, das ist ja ein einfach ein konzeptionelles Problem. Das kannst du ja nicht durch eine Softwarelösung. Du kannst es vielleicht abmildern, aber ganz gelöst bekommst du es nie. Und da wäre es ja interessant zu wissen, ob die Kunden hinterher glücklicher sind, weil sie vielleicht mehr Dokumentation bekommen und dann nicht in so viele Sackgassen laufen, am Start und schneller produktiver sind, oder? Was ich mir manchmal auch gedacht habe, ist das Comedia für den einen oder anderen Einsatzzweck, für den der Kunde dann letztlich benutzt hat. Vielleicht einfach ein, zwei Nummern. Zu groß ist auch definitiv, dass der Kunde einfach der braucht diese ganze Flexibilität gar nicht, sondern der braucht im Grunde ich sag es jetzt einfach mal so eine Art WordPress für eine kleine Seite, wo einmal am Tag Informationen eingetragen werden und dann also falls überhaupt. Und dann gibt es einfach eine Website, wo die Leute drauf gehen können, um sich das anzugucken.

Dafür braucht man meiner Meinung nach, dann gibt es einfachere und kostengünstigere Lösungen. Wenn das die Anforderung ist. Comedia braucht man, wenn man wirklich viel Content in vielen Gestalten, also viele Bilder, viele Texte, viele weitere Content Klassen nach gewissen Schlüsseln taxonomischen verwalten möchte und die auf sehr viele unterschiedliche Plattformen bekommen möchte. In die App, in die Webseite.

Der Content, den die Redakteure einstellen, sollte eine sehr hohe Qualität haben, damit man den eben möglichst flexibel über die verschiedenen Ausspielung Kanäle nutzen kann.

Ich glaube, das Stichwort ist Hedley CMS, wo du quasi kein wie gesagt kein kein Frontend mehr hast, sondern einfach nur ein Content Repository, was der Rest von Europa angesprochen werden kann und an Jason oder oder XML zurück liefert, damit das selbst gewählte Frontend das darstellen kann. Und da weiß ich hatte ein Kunde von mir, war dort sehr innovativ unterwegs und hat angefangen das bestehende Comedia System selber so umzuschreiben, um das als Helm CMS nutzen zu können. Und da waren wir auch mit Comedia selbst im Gespräch, haben dort mit ihrer Innovation Abteilung mit einem Kollegen zusammengesessen, überlegt, wie man das zusammenführen kann, diese Erfurts, die beide da leisten. Und das alles ist jetzt irgendwie, in dem das neue Comedia geflossen ist, 10 die dann dieses Hedley CMS immer mehr in den Vordergrund rücken.

Comedia hat auch gemerkt, dass ein Schmerzpunkt der, den sie wahrscheinlich so lange begleitet wie es kommt. Da gibt es ja diese Editor Maske oder die Wie sehen die Masken aus, mit denen die Redakteure letztlich arbeiten. Und da gibt es einfach Menschen, die mit dem System arbeiten. Aber es gibt auch sehr sehr viele einfach Content Quellen, so Wetterberichte, die dann einfach in dieses Content Repository rein gefiedert werden. Und ja, bei Handles sagst du ja direkt Bau dir deine Maske selber und wenn du gar nicht so viel Funktionen brauchst, bist du relativ schnell fertig. Und wenn du alle Funktionen brauchst, dann kannst du immer noch das Studio nehmen.

Ja, das das. Das heißt, es bezieht sich mehr auf die Auslieferung Seite. Du brauchst natürlich immer noch ein bisschen mehr Frontend für für den Admin Frontend für Redakteure um um Content einzustellen. Der früher gab es bei Comedia diesen Java Web Start Editor eher. Ich habe mal von Kollegen als Liebesgaben bezeichnet wurde, weil er sehr rudimentär war und sehr low level und dann hat er ziemlich viel Zeit investiert und hat das Studio rausgebracht, was optisch sehr naiv ist, aber meines Erachtens das komplizierteste Stück Software.

Ja, in dem ganz automatisch auf dem Podium, was ich je gesehen habe. Es ist mega kompliziert dafür. Also ich habe so oft erlebt, wo der Kunde sagt Hey, können wir da mal so ein Element ändern und und dies und jenes damit machen. Und das dauert Tage und Wochen, um so ein Ding einzubauen. Und dann schlägt sich jeder die Hände über den Kopf zusammen. Doch was ist das? Und das ist eine Komponente, wo ich echt keine Freunde geworden sind, also ganz wüster wird. Du bist in ActionScript, das wird dann über so einen Compiler der Open, was sie selber geschrieben haben und sollen. Und das nennt sich und nun der transkribiert quasi von ActionScript Richtungen da was transformiert das in JavaScript und das wird dann ausgeführt und das weiß ich. Das war sowas von Entwickler unfreundlich, weil keiner so richtig Durchblick und Doku dazu ist. Sehr sehr rudimentär und deswegen Code siehst du nicht, so auch nicht.

Und Wahnsinn, Commedia war ein Stück zu früh dran, glaub ich. Was die Technologie der Technologie ist. Auswahl angeht Wenn es damals schon Angela gegeben hätte oder so, hätten die das damit gemacht.

Oder React und so genau oder dann hätte man Typoskript benutzt statt ActionScript. Also ActionScript ist ja auch. Ja, gibt es ist ein STANDARD, aber das, die haben ja ActionScript, genau genommen, damit das irgendwie in eine gewisse Objektorientierung drin haben. Und die Idee Unterstützung. Also es machte schon Sinn, was sie gemacht haben, weil einfach die Tools gefehlt haben zu dem Zeitpunkt, wo sie es gebraucht haben. Nur ja, jetzt haben wir de facto STANDARD bei solchen Dingen und Comedia hat seine Technologie es proprietär und dann sind sie auch wieder alleine und müssten das dann alles ändern und könnten nicht auf die Gemeinschaft zählen, die ihn dann vielleicht diesen ActionScript Bock dann wieder abnehmen würde, damit es alles in JavaScript oder irgendeiner anderen Metasprache, die heute gebräuchlicher ist, übersetzt wird.

Und mit jedem Projekt, wo ich drin gewesen bin, haben sich alle gesträubt das Studio mit Studio zu übernehmen, weil du die Technologie, ein eigenes Ding quasi tot ist. Die kann keiner lernen. Das klingt jetzt witzig, aber es ist echt ein Problem.

Also man vermeidet Anpassungen im Studio, auch wenn es geht. Und das ist auch meine Erfahrung. Und das ist nicht untypisch, dass man sagt, wir brauchen dann nur einen Button, der irgendwie die Farbe ändert, wenn jemand mehr als x Wörter in die Box getippt hat oder so was oder irgend so ein Alert, der auf irgendwas Bezug nimmt und das D Du hast den Alert implementiert, du hast die Daten Strecke dahin gelegt, du hast alles gemacht. Aber jetzt die Anzeige im Studio ist das rot oder gelb. Diesen beiden da oben einzubauen, das dauert dann lange her und ich glaube er wird uns jetzt hassen, wenn Sie das hören.

Ich hoffe nicht ich. Sie können gerne eine E-Mail schreiben und wir laden auch gerne von Comedia die Entwickler ein, dass sie mit, dass sie mit uns gemeinsam diese Herausforderung, nennen wir es mal diskutieren und uns auch vielleicht nur alternative Herangehensweisen aufzeigen, wie man das alles macht. Und ich glaube auch wir sind eher wir gehen ja konstruktiv mit dem Thema um. Und Comedia ist ja kein schlechtes System. Nein, ein komplexes System, vor allem wenn du einen komplexen Sachverhalt hast. Und es bietet sehr viele Komponenten, die du zusammenstecken kannst. Nur und das ist das denke ich, was in unserem Gespräch rauskommt, du musst halt wissen, was du tust. So, und das möglichst früh. Oder einen Partner haben, der dir da helfen kann. Der sagt Okay, ich habe das schon einige Male gemacht und ich kann dich vor den schlimmsten Stolperfallen schützen und lass uns das zusammen angehen. Und genau das im Grunde machen wir ja bei Skillbyte. Also wir haben ja auch mehrere langjährige Comedia Entwickler, zwei davon noch mit Steve Jobs Fachwissen dazu also sechs Entwickler, zwei Spezialisten, die sich mindestens seit dem Jahr 2010 oh Gott, das ist ja auch schon zehn Jahre her intensiv mit Comedia Installationen beschäftigt haben und die da über viel, viel Fachwissen verfügen.

Trotzdem ist jedes Projekt noch spannend und herausfordernd. Gut, aber so ist die Welt der Technologie nunmal.

Klingt komisch, ist aber so. Genau deshalb lieben wir das auch. Also genau, wenn Kunden oder wahrscheinlich eher Entwickler uns zuhören, die Fragen zu Comedia haben, können sie gerne auch eine E-Mail an Podcast Skillbyte senden und wir schauen dann, wie wir mit euch in Kontakt treten können, um euch eure Frage zu beantworten. Hast du noch so einen heißen Tipp oder eine Prophezeiung, in welche Richtung es gehen mag? Mit Comedia also wird Comedia weiterhin relevant sein? Wird es eine Veränderung geben im Sinne von, dass die ganzen Services noch weiter zerteilt werden? Hier Microservices, Architektur? Oder geht der Trend dahin, dass man nur noch Open Source CMS Systeme nimmt, wie das ja auch beim Government Zeit Bilder geschehen ist, damit da mit man gemeinsam an der Basis Platform arbeiten kann?

Ja, ich glaube schon, dass das Comedia bestehen bleibt, weil ich als Kunde im Management System anbietet, sehr lange am Markt ist, sehr große Kunden hat. Die konzentrieren sich im Moment ein bisschen mehr Richtung E-Commerce. Also eine Zeit lang waren sie mehr auf Medienunternehmen fixiert, aber gehen immer mehr Richtung Richtung E-Commerce und wollen jetzt ganz stark Richtung USA expandieren. Haben jetzt auch einen. Also die hatten ja die Mobilität, die Telekom als Investor mit drin. Telekom ist raus und haben jetzt quasi Private Equity Investors in den USA drin. Auch glaube ich mit der mit der mit der Absicht mehr in den USA zu expandieren. Deshalb auch dieser Partner stellen dort immer mehr Entwickler ein. Und der wichtige Punkt ist, dass sie halt Support bieten. Den beiden großen Unternehmen ist es so, dass sie meistens kein Open Source Projekte nehmen, sondern ein eine Firma oder Produkt einer Firma nehmen, wo sie auch Support einkaufen können. Und das ist halt bei mir der Fall. Der Support ist auch wirklich gut. Die Jungs sind schnell, haben sehr viel Ahnung.

Da wird sehr viel Wert darauf gelegt, dass die Leute geschult und fit sind. Und deswegen glaube ich, es gab ja auch einige andere Hersteller, etwa bei Siemens Hersteller, die gekommen. Und gegangen sind und Comedians quasi alle überlebt und auch wenn ich jetzt mal auf Studio geschimpft habe, es ist halt immer noch eines der besten Teams am Markt meines Erachtens ja. Und deswegen glaube ich schon, dass die, dass die bestehen bleiben, vielleicht ihren Fokus ein bisschen ändern, ihre Markt Ausrichtung ein bisschen ändern, aber die wird es noch lange geben.

Meine großen Unternehmen Umfeld glaube ich auch. Ich glaube auch, dass sie nach und nach ihre Architektur mal modernisieren werden. An der Wand gesagt Korber ist glaube ich in Java 11 schon als der Fabrikate markiert. Das heißt, es fliegt irgendwann aus dem Chor JDK raus und wird dann nur noch Kubernetes dann noch runterladen können, so als externes Projekt. Aber der Stern sinkt, was auch der Fall ist. Also die die Jungs und Mädels, die da arbeiten, sind alle super nett. Es ist halt so eine familiäre Stimmung. Also auf dem Partner tagen ist immer so wie so ein Klassentreffen. Also man man trifft die Kunden, die die Comedia Kollegen selber ist. Es macht sehr viel Spaß mit denen zusammenzuarbeiten und die Alten die sie auch unterwegs haben, sind alle super fit. Also insofern sind sie schon sehr gut aufgestellt.

Das stimmt. Mit der Consultants habe ich auch bisher gute Erfahrungen gemacht, das war auch immer einwandfrei. Alles klar, ich danke dir. Ich danke dir an unsere Zuhörer, wenn ihr Fragen habt oder Anregungen oder mit uns in die Diskussion treten möchtet, schickt gerne eine E-Mail an Podcast skillbyte Wenn euch der Podcast gefallen hat, lasst gerne eine Bewertung da, abonniert uns oder klickt den Daumen für ein Like an oder schaut auf Skillbyte de Slash Blog vorbei, wo wir weitere Artikel zu technischen Themen veröffentlichen. Ich danke dir Masiar Danke Maurice, ich wünsche dir noch einen schönen Tag.

Ja, bis dann.