insureNXT

<p>In den letzten Tagen habe ich mich intensiv mit dem Tuning von XSLs beschäftigen dürfen, die innerhalb einer Web-Anwendung zur Erzeugung der HTML-Masken eingesetzt werden. Prinzipiell stellten die XSLs in diesem Fall kein Antwortzeit-Problem dar, jedoch verbrauchte eine XSL-Transformation einfach zu viel CPU. Dies wollten wir optimieren.</p><p>Nach ein wenig googlen habe ich dann festgestellt, dass das Thema <em>XSL-Tuning</em> im Vergleich zu Java-Tuning/-Profiling dünn besetzt ist. Die meisten Einträge sind schon relativ alt zu diesem Thema. Auch gibt es relativ wenige Werkzeuge, die man einsetzen kann. Es gibt zwar einige XSL-Profiler (z.B. <a href="http://www.stylusstudio.com/xslt_profiler.html" target="_blank">Stylusstudio</a> , <a href="http://www.oxygenxml.com/xslt_debugger.html" target="_blank">Oxygen</a> ), jedoch war in unserem Fall die XSL-Transformation in einer Web-Anwendung vollständig eingebettet. Daher wollten wir nicht das dynamisch erzeugte XML in Dateien schreiben und dann einzelnd profilen. Einige XSLT-Implementierungen bieten selber schon Profiling-Informationen an, z.B. kann man bei Saxon einen entsprechenden Parameter setzen. Wir setzen Xalan ein und dort gibt es eine solche Option nicht.</p><p>Wir sind daher unseren „normalen“ Weg gegangen, d.h. wir haben einen Java-Profiler benutzt und die Xalan-Klassen instrumentiert. Xalan (wenn XSLTC verwendet wird) generiert Bytecode für die XSLs zur Laufzeit (Translets), die wir ebenfalls profilen konnten. Im Profiler konnte man dann recht gut erkennen, welche Templates (bei Verwendung von includes/call-template/apply-templates) die meiste Zeit verbraucht haben und hatten dann entsprechende Ansatzpunkte, bei denen wir optimieren konnten.</p><p>Wir haben dabei festgestellt, dass XSL-Tuning grundlegendes Verständnis einer XSL-Transformation voraussetzt, d.h. nicht nur, welche XSL-Tags verwendet werden können und welche Alternativen es gibt, sondern insbesondere auch, wie ein XSL-Tag /XPath-Ausdrück funktioniert. So arbeitet eine XSL-Transformation grundsätzlich auf einem XML-Baum (auch wenn nicht alle XSLT-Implementierungen DOM benutzen und auch Xalan durch das eigene DTM optimiert) und alle Operationen zur Navigation innerhalb eines XML-Baums sind relativ teuer , z.B. „..“, „//“ oder „descandant::“-Ausdrücke. Je nach Komplexität des XML-Baums konnte man hierdurch schon optimieren. Es hilft auch, diesen XML-Baum möglichst klein zu halten, d.h. Datenmenge zu reduzieren. Im Endeffekt waren es solche „Baumoperationen“, die wir weg-optimiert haben. Aus Performance-Sicht teuer war auch der Umgang mit „nodeset()“, diese Funktion haben wir benutzt selber nochmal innerhalb der XSL XML zu parsen….</p><p>Ansonsten haben wir auch einige andere Optimierungen probiert:</p><ol><li>Umsetzung der Maßnahmen aus den offiziellen Xalan-FAQs</li><li>Austauschen von Xalan durch andere Implementierungen (z.B. Saxon)</li><li>Auslagern von „teuren“ Teilen in eigene Java-Implementierungen. Hier bietet Xalan Mechanismen für eigene Extensions</li></ol><p>Auch bei XSL-Tuning gilt : Immer nur eine Maßnahme durchführen und dann nachmessen. Je nach XSL kann eine Maßnahme auch schlecht sein, daher vermeide ich hier auch generelle Regeln…</p><p>Wenn alles Tuning nicht helfen sollte, gibt es noch die Möglichkeit, die XSL-Transformation komplett auszulagern auf ein dafür optimiertes System (z.B. <a href="http://www-03.ibm.com/software/products/en/ibm-datapower-gateways" target="_blank">IBM Datapower</a> , Layer7).  Hier haben wir die IBM Datapower getestet und diese hat die XSL-Transformation in einer wahnsinnigen Geschwindigkeit ausgeführt. Hier spielen natürlich andere Gründe eine Rolle, ob man eine solche Appliance einsetzen möchte.</p>

XSL-Performance Tuning

<p>In letzter Zeit liest man viel zu Mandantenfähigkeit – der Trend rund um die Cloud lässt diese Anforderung in den Vordergrund rücken, da sie verständlicherweise bei SAAS ein Muß ist. So liest man zu verschiedensten Frameworks / Tools, dass sie „mandantenfähig“ sind. Beispiele:</p><ul><li><a href="https://ucf.github.io/Athena-Framework/" target="_blank">Athena Framework</a> </li><li>Grails hat ein MultiTenant-Plugin</li><li><a href="http://googleappengine.blogspot.com/2010/08/multi-tenancy-support-high-performance_17.html" target="_blank">Google App Engine</a> </li><li>Windows Azure Appfabric</li></ul><p>Da gibt’s noch viel mehr – auch zahlreiche Blogeinträge und Dokumentationen zu anderen Frameworks, wie man Mandantenfähigkeit abbilden kann, z.B. mit Hibernate (http://relation.to/Bloggers/MultitenancyInHibernate).</p><p>Ach ja, und natürlich wird in Java EE 7 „Multi-Tenancy“ eingebaut sein (<a href="http://jcp.org/en/jsr/proposalDetails?id=342" target="_blank">JSR-342</a> ), da Java EE 7 die „Cloud“ als wichtigen Treiber für die Java Enterprise Plattform auserkoren hat.</p><p>Seit Jahren begleitet mich das Thema Mandantenfähigkeit bei vielen Kunden (schon lange vor der Wolke) und immer war es eine Herausforderung. <span>Und jetzt machen die Frameworks das einfach und mit Java EE 7 ist das dann auch noch standardisiert !</span></p><p>Aber was ist denn nun eigentlich mandantenfähig bei den Frameworks? Aus meiner Sicht gibt es Anforderungen an Mandantenfähigkeit auf verschiedensten Ebenen einer Applikation:</p><ul><li>Verschiedene Oberflächen für verschiedene Mandanten</li><li>Andere Prozesse / Workflows innerhalb einer Anwendung</li><li>Abweichende Geschäftslogik/-regeln je Mandant</li><li>Disjunkte und gemeinsame Daten von Mandanten</li><li>u.v.m.</li></ul><p>Ein einfacher Blick in die Dokumentation der verschiedenen Frameworks zeigt jedoch schnell, dass sie immer nur Teilaspekte von Mandantenfähigkeit adressieren. Ist auch korrekt, dass z.B. ein OR-Mapper nur die bekannten Pattern zur Abbildung von Mandanten-Daten (getrennte Datenbanken, eine Datenbank mit getrennten Tabellen, Daten der Mandanten in den gleichen Tabellen, etc.) abbilden muss – und nichts anderes. Das hilft aber schon mal weiter. Viele Frameworks bieten ein Konzept mandantenfähgkeit von Geschäftslogik/-regeln nicht an.</p><p>Interessanter werden schon noch die Frameworks, die eher einen kompletten Stack abbilden  – z.B. Spring oder Java EE.</p><p>Für Java EE 7 ist es noch zu früh wirklich zu sagen, in welchen Bereichen/APIs Manandentfähigkeit Verwendung finden wird. Im Summary des JSRs findet man, dass bestimmte APIs wie JPA, JDBC oder JMS auf Mandantenfähigkeit ausgelegt werden:</p><blockquote><p>…. In particular, all resource manager-related APIs, such as JPA, JDBC and JMS, will be updated to enable multitenancy….</p></blockquote><p>Auch wird man in Java EE über Metadaten zu einer Applikation hinterlegen können, dass sie mandantenfähig ist. Aber man muss mal den Early Draft (geplant für das dritte Quartal in 2011) abwarten und dann mal schauen, was dann wirklich angedacht wird.</p><p>Spring hat erstmal keine direkte Unterstützung von Mandantenfähigkeit vorgesehen – allerdings kann man hier mit den vorhandenen Mitteln sehr schnell ein Konzept zur Mandantenfähigkeit abbilden. So haben wir in einem Projekt über Hierarchien von BeanFactories und geschickten Namenskonventionen ermöglicht, einzelne Funktionen pro Mandant auszutauschen. Die Patterns zur Abbildung von Mandanten in der Datenbank lassen sich ebenso in Kombination mit einem OR-Mapper wie Hibernate anwenden. Spring selber kennt keine Mandanten – man kann Spring aber als Framework sehr gut nutzen, um Mandantenfähgkeit auf verschiedensten Ebenen abzubilden.</p><p>Was insgesamt sehr wohl eine Rolle spielt ist die Anzahl der Mandanten, die ein System unterstützen muss. Ich denke je mehr Mandaten es sein sollen (wie z.B. bei SaaS-Anwendungen), desto weniger wichtig wird die Anpassbarkeit pro Mandant (z.B. bei einzelnen Funktionen, etc.) – und wenn, dann sollte der Mandant es selber können. Alles andere ist wohl nicht mehr managebar. Viele Kunden von uns haben die Anforderung an eine Unterstützung einer hohen Anzahl an Mandanten nicht – allerdings benötigen die dann die Flexibilität, für jeden Mandant Anpassungen / Erweiterungen vorzunehmen um dann dennoch insgesamt nur ein System zu warten und dieses auch wirklich zu vertretbaren Kosten warten zu können.</p><p>Insgesamt ist es immer noch so, dass man bei „Mandantenfähigkeit“ genau hinsehen muss, was die Anforderungen eigentlich sind. Viele Frameworks bieten allerdings heutzutage Mechanismen, die man geschickt nutzen und in die Gesamtlösung integrieren kann.</p><p>Bei der Anforderungserhebung einfach mal mit der Frage beginnen „Was ist ein Mandant ?“ – dann wird man schnell erkennen, wie viel Arbeit man vor sich hat…..</p>

Mandantenfähigkeit – zukünftig „built-in“ in allen Frameworks?

<p>Bei unseren Kunden und auch bei codecentric dreht sich alles um den besten und schnellsten Weg, die richtige Software zu entwickeln – und das natürlich in hoher Qualität. Von daher bin ich auch ein fleißiger Leser des „State of DevOps“-Report (<a href="https://cloud.google.com/devops/state-of-devops/" target="_blank">hier zum Download verfügbar</a> ), der immer ganz gut widerspiegelt, welche Praktiken Teams einsetzen, die in hoher Frequenz und hoher Qualität ausliefern. Bisher nie unmittelbar Thema in den Reports war die IDE – wie gehen hoch produktive Teams mit dem „Ausrollen“ einer IDE um? Ich kenne verschiedene Möglichkeiten: vom standardisierten ZIP-File bis hin zu integriert im automatisierten Device-Management. Oft sind es bei Kunden durchaus größere Projekte, die das Ausrollen einer IDE automatisieren, da oft auch neue/moderne Hardware („Entwicklerrechner“) damit einhergehen. Aber es ist schon etwas her, seit ich das letzte Mal richtig in einem Kundenprojekt programmiert habe. Ich habe mir öfter während des lokalen Builds einen Kaffee holen können …</p><p>Und dann lese ich diese Aussage von Gartner:</p><blockquote><p>By 2025, 30% of large enterprises will use browser-based IDEs to streamline development workflows and enable better manageability.“</p></blockquote><p>Natürlich habe ich den Trend wahrgenommen, auch die IDEs aus einer Cloud heraus anzubieten – gerade, wenn es um reine Cloud-Workloads geht, die man entwickelt (z. B. Serverless). Eine IDE, die vollständig im Browser funktioniert, benötigt keine Installation mehr – auch etwaige Entwickler-Testumgebungen etc. sollten nicht mehr installiert und konfiguriert werden müssen.</p><p>Aber was mich überrascht hat, ist die Geschwindigkeit der Verbreitung, die hier prognostiziert wird – wenn ich bedenke, was Kunden da machen müssen, um die Entwicklungsumgebungen umzustellen. Daher wollte ich mir Browser-basierte IDEs einmal genauer ansehen und die Vor- und Nachteile beleuchten.</p><h2>Vorteile lokaler IDEs</h2><ul><li>Aus Sicht eines Java-Enterprise-Entwicklers, wie ich einer war, ist eine lokale IDE erst einmal super. Dafür gab es mehrere Gründe:<br /> Auch in standardisierten Umgebungen gab es immer genug Möglichkeiten, die lokale Umgebung für sich anzupassen. Durch stärkere Trennung von Entwicklung und Build-Prozess wurde es sogar möglich, verschiedene IDEs zu nutzen.</li><li>Da der erste Test eigentlich immer auf dem eigenen Rechner ausgeführt wurde, erlangte man viel Wissen über die Infrastruktur. Dies vereinfachte oft die Kommunikation mit dem Betrieb im Fall von auftretenden Fehlern. Insbesondere dann, wenn schlanke Application Server auf den lokalen Rechnern auch die schwergewichtigen Application Server in Produktion verdrängt hatten.</li><li>Man brauchte immer einen gut ausgestatteten Rechner, was man als Techie natürlich grundsätzlich begrüßt hat. Für die Developer-Experience schon ein positiver Punkt.</li><li>Die Komplexität einer lokalen Umgebung machte natürlich auch Spaß. Und man konnte alles kontrollieren. Oft hatte man auch bei Kunden Admin-Rechte auf dem Entwicklerrechner.</li><li>Wenn der lokale Build länger dauerte konnte, man nicht nur Kaffee holen, sondern hatte auch das Gefühl, etwas geschafft zu haben. Bei komplexeren Projekten dauerte es länger … und Komplexität macht Spaß.<br /> Man konnte viel offline entwickeln (während der berühmten Bahnfahrt), war also nicht immer auf Netzwerk angewiesen.</li></ul><h2>Vorteile Cloud-basierter IDEs</h2><p>Ich denke, auch heute noch kann man das nachvollziehen. Aber was spricht eigentlich für einen Browser-basierten Ansatz? Als Entwickler hätte man erstmal keinen Grund, die Kontrolle über seine IDE und seinen Entwicklerrechner zu verlieren. Und bin ich dann wirklich schneller in der Softwareentwicklung?</p><p>Es sind andere Punkte, die uns auch mit der IDE in die Cloud treiben wollen:</p><ul><li><strong>Cloud Workloads</strong>: Die Workloads verschieben sich weiterhin in die Cloud – und das schneller als in den letzten Jahren. Es werden dann auch immer mehr echte Cloud-Anwendungen entstehen, nicht nur Cloud als Host von Kubernetes-Containern. Parallel werden schon viele Build-Prozesse in die Cloud verlagert (oder sind es schon). Diese Trends machen dann natürlich eine lokale IDE irgendwann immer komplexer; oder der Anteil, der wirklich lokal läuft, reduziert sich dramatisch. Dann hat eine IDE in der Cloud irgendwann entscheidende Vorteile.</li><li><strong>Remote Work</strong>: Wir alle in der IT haben auf ein Remote-Modell umgestellt (oder umstellen müssen) – d. h. Entwicklungsteams sitzen nicht immer zusammen, nicht mehr im selben, geschützten Netzwerk. Das ändert die Anforderungen an die eingesetzten Rechner, aber macht auch die Entwicklungsinfrastruktur wieder komplizierter – z. B. bei Einrichtung von VPN-Verbindungen ins lokale Netz. Gleichzeitig ist gerade der Bedarf an Softwareentwicklung überall sehr hoch, d. h. Teams werden erweitert, neue Mitglieder kommen an Bord und dies dann auch verteilt. Manchmal werden Lösungen geschaffen, die alles andere als ideal für eine positive Developer Experience sind, z. B. wenn eine IDE über virtuelle Maschinen bereitgestellt wird. Zusammenarbeitsmodelle in den Entwicklungsteams (z. B. Pair Programming) könnten noch besser unterstützt werden. Warum nicht mal unterwegs vom iPad aus noch eine Kleinigkeit korrigieren?</li><li><strong>Compliance</strong>: Die Datenschutz- und Security-Anforderungen an einen Entwicklerrechner sind hoch, gerade in regulierten Branchen (z. B. Banken, Versicherungen). Es besteht auch oft Netzwerkzugriff auf kritische Netzwerk-Bereiche. Reagiert wird manchmal damit, dass dedizierte „Entwickler -Laptops“ für die Remote-Arbeit ausgegeben werden, damit man vollständige Kontrolle über den Laptop hat (Virusprogramme, Netzwerkzugänge, Verschlüsselung, etc.). Im Grunde wollen aber Softwareentwickler*innen ihre eingesetzte Hardware selber bestimmen – eigentlich möchte man ja auch nicht externe Entwickler*innen mit Rechnern ausstatten, da dies noch zusätzliche Projektkosten sind. Mit Browser-basierten IDEs könnte man diese Probleme völlig anders adressieren – alles ist in der Cloud, auch die Testsysteme. Compliance-Anforderungen ließen sich einmalig lösen und Entwicklungsteams leichter skalieren.</li><li><strong>Ramp-up</strong>: Die Ramp-up-Aufwände für neue Teammitglieder lassen sich reduzieren, ebenso werden Updates an den Entwicklungsumgebungen einfacher. Dies spart Zeit und hilft, Geld einzusparen.</li></ul><h2>Einschränkungen Browser-basierter IDEs</h2><p>Natürlich gibt es auch Punkte, die die Verlagerung der IDE in die Cloud verlangsamen – bzw. wo auch noch kritisch hinterfragt werden muss:</p><ul><li><strong>Connectivity</strong>: Man braucht halt grundsätzlich immer eine gute und stabile Netzwerkverbindung. In Kombination mit dem Trend zu mehr Remote Work ist es dann wirklich abhängig von der Connectivity, ob und wie gut man arbeiten kann. Dem entgegen steht natürlich, dass sich die Connectivity stetig bessert – und dass man auch mit lokaler IDE kaum noch wirklich lange offline arbeiten kann. Anwendungen sind zu komplex geworden, so dass fast immer Schnittstellen gebraucht werden. Auch das Commit-Verhalten hat sich glücklicherweise geändert – man fühlt sich schon unwohl, wenn man nicht mehrfach am Tag etwas committen kann.<br /> Es kann aber auch sein, dass man mit einer IDE im Browser weniger Datenvolumen erzeugt als mit einer lokalen IDE. Heute lädt man Docker-Images, JAR-Files, andere Abhängigkeiten auf seinen Rechner … Da kommt schon was zusammen.</li><li><strong>Compliance</strong>: War das nicht einer der Treiber? Ja, aber in Europa gilt die DSGVO – die kann hier sehr bremsend wirken auf den Trend zur Browser-basierten IDE. An den Ansatz, die IDE im eigenen Rechenzentrum zu hosten (Private Cloud), glaube ich nicht – das wird dann doch dauerhaft zu teuer.</li><li><strong>Emotional</strong>: Es könnte für viele Entwickler*innen ein Schritt sein, den sie nicht gehen möchten. Im Browser programmieren – wirklich? Dies könnte Widerstände erzeugen, die es zu überwinden gilt.</li></ul><p>Jetzt fragt ihr euch: Von welchen IDEs spricht Rainer da eigentlich? Daher mal im Folgenden ein paar Beispiele. Grundsätzlich muss man genau hinschauen, was die jeweilige Umgebung auch leisten kann und auch möchte – einige sind auf bestimmte Anwendungsfälle optimiert und haben nicht den Anspruch, eine lokale IDE komplett zu ersetzen. Der Überblick hier ist nicht vollständig – es geht nur darum, ein Gefühl für verschiedene Ansätze zu entwickeln.</p><h3>Eclipse Che</h3><p>„Run your favorite IDE on Kubernetes“ – der Claim auf der Webpage erklärt auch schon den Ansatz von <a href="https://www.eclipse.org/che/" target="_blank">Eclipse Che</a> :<br /> Browser-basierter Remote-Zugriff auf die präferierte IDE. Momentan direkt unterstützt werden die Jetbrains IDE (basierend auf Jetbrains Projector), Visual Studio Code und Eclipse Theia. Eclipse CHE bringt daher keine eigene IDE mit, sondern kümmert sich primär um das ganze Handling einer kompletten Entwicklungsumgebung.<br /> Die Entwicklungsumgebung insgesamt wird über ein „devfile“ beschrieben, auf dessen Basis die gesamte Umgebung automatisiert zur Verfügung gestellt wird.<br /> Es gibt direkt als SaaS-Umgebungen nutzbare Eclipse-Che-Umgebungen (z. B. von Red Hat), aber man kann Eclipse Che auch auf dem eigenen Kubernetes-Cluster installieren und betreiben.</p><p>Eclipse Che ist damit schon eine sehr mächtige und recht individuell konfigurierbare Plattform. Man könnte sogar verschiedene IDEs mixen oder auch leicht IDEs wechseln.</p><h3>GitHub Codespaces</h3><p>Komplette Entwicklungsumgebungen basierend auf Visual Studio Code werden über <a href="https://github.com/features/codespaces" target="_blank">Codespaces</a>  zur Verfügung gestellt – der komplette Funktionsumfang von Visual Studio Code steht hierbei zur Verfügung. Die Entwicklungsumgebung wird wiederum über eine Datei beschrieben und automatisiert zur Verfügung gestellt. Das Dev-Team, das GitHub entwickelt, nutzt mittlerweile selber Codespaces – in einem interessanten <a href="https://github.blog/2021-08-11-githubs-engineering-team-moved-codespaces" target="_blank">Blog-Eintrag</a>  gibt es Details.<br /> Die IDE wird als VM zur Verfügung gestellt, deren Größe auch konfigurierbar ist – bis zu 32 Cores und 64 GB RAM. Aber natürlich zu entsprechenden Preisen.</p><h3>GitPod</h3><p>Der Ansatz von <a href="https://www.gitpod.io" target="_blank">GitPod</a>  ähnelt den vorangehend beschriebenen: Es wird eine komplette Entwicklungsumgebung automatisiert bereitgestellt, als IDE-Basis werden Visual Studio Code und auch IntelliJ verwendet. Interessant ist, dass kürzlich eine enge Partnerschaft mit IntelliJ <a href="https://www.gitpod.io/blog/gitpod-jetbrains" target="_blank">verkündet worden</a>  ist – das „Works on my machine“-Problem wird gemeinsam angegangen. GitPod wird als SaaS angeboten, aber auch zur Installation auf dem eigenem Kubernetes-Cluster, z. B. in Azure, AWS oder Google.</p><h3>Codeanywhere</h3><p><a href="https://codeanywhere.com" target="_blank">Codeanywhere</a>  basiert grundsätzlich auch auf Visual Studio Code, reichert diese IDE aber um weitere Features an. Insbesondere lassen sich eigene Server mithilfe von Standard- Protokollen einbinden (z. B. SSH) – auf diesen Servern können wir dann aus der IDE heraus Dateien editieren oder sogar SSH-Terminals starten. Aber auch Codeanywhere bringt eine Reihe von vorinstallierten Containern mit, um schnell eine reine Cloud-Programmierumgebung zu schaffen.</p><h3>AWS Cloud9</h3><p><a href="https://aws.amazon.com/de/cloud9/" target="_blank">AWS Cloud9</a>  ist die Cloud-basierte Entwicklungsumgebung von AWS. Sie unterstützt ebenso eine Vielzahl von Sprachen, ist aber dann doch recht optimiert für den Einsatz im AWS-Ökosystem – auch wenn sich andere Server grundsätzlich mit SSH einbinden lassen. In Zusammenspiel mit dem Baukasten von AWS (CodeStar, CloudFormation, etc.) wird die Umgebung eher richtig sinnvoll bei AWS-Workloads, weniger in hybriden Szenarien.</p><h3>JetBrains Fleet</h3><p>Wenn JetBrains die <a href="https://www.jetbrains.com/de-de/fleet/" target="_blank">„next-generation IDE“</a>  entwickelt, dann lohnt sich ein Blick auf den Ansatz. JetBrains verfolgt ein deutlich anderes Konzept als die bisher genannten Plattformen. Kernidee ist es, dass die IDE selber über eine verteilte Architektur verfügt – kurz: Der leichtgewichtige Editor befindet sich auf der Entwicklermaschine, alle anderen Teile können auf zentrale Maschinen verteilt werden, auch die mächtige Code Engine von IntelliJ. Fokus des Ansatzes ist die bessere Kollaboration aller beteiligten Entwickler*innen. Viele Vorteile einer Cloud-IDE können so auch realisiert werden, aber es ist eine wirklich reine IDE – automatisiertes Hochfahren von Umgebungen ist z. B. nicht Teil der Plattform. Momentan befindet sich Fleet noch in der geschlossenen Beta-Phase. Ich kann mir vorstellen, dass die oben genannten Plattformen von dieser neuen Architektur Gebrauch machen könnten und in der Zukunft auch Fleet integrieren.</p><h3>Codesphere</h3><p>Die bisher genannten Ansätze zielten auf sehr generische Anwendungstypen ab, d. h. eine möglichst breite Unterstützung von Programmiersprachen und Container-basierten Architekturen. Es gibt aber auch Ansätze, die klar auf die Vereinfachung der Entwicklung bestimmter Anwendungstypen abzielen und hier nicht nur eine Cloud-IDE mitbringen, sondern eine durchgängige Plattform bis hin zum Betrieb, und dies hoch automatisiert, aber auch hoch standardisiert. <a href="https://codesphere.com/" target="_blank">Codesphere</a>  ist ein noch recht junges Startup und die Kernidee ist es, Entwickler*innen eine durchgängige Plattform zu bieten, die die IDE direkt mit der Infrastruktur verbindet. Hier wird nicht „nur“ eine Cloud-IDE mitgebracht, sondern auch eine Cloud-Infrastruktur für Test und Produktion der erstellten Web-Anwendungen – inkl. integriertem Monitoring.</p><h3>Replit</h3><p>Mit <a href="https://replit.com" target="_blank">Replit</a>  erzeugt man sogenannte „Repls“, d. h. konkrete Anwendungen/Apps/Web-Anwendungen, die dann auch direkt auf Replit-Servern ausgeführt werden (Test und Produktion).</p><h3>CodeSandbox</h3><p><a href="https://codesandbox.io" target="_blank">CodeSandbox</a>  fokussiert darauf, Web Development im Team schnell zu machen – durch gute Kollaborationsmöglichkeiten und Optimierung auf Web Development. CodeSandbox kann man aber auch in bestehende Entwicklungsprozesse integrieren, d. h. kann ergänzend sein als IDE und nicht eine komplette IDE ersetzen. Wiederum ein nochmal anderer Ansatz.</p><p>Wenn man jetzt noch Low-Code-Ansätze betrachtete, wäre die Liste schnell noch viel länger. Aber auch schon so gibt es wichtige Player im Markt der IDEs, die auf den Browser-basierten Ansatz aufspringen bzw. auch alternative Ansätze zur klassischen Offline-IDE suchen.</p><h2>Verschiedene Arten von Cloud-basierten IDEs</h2><p>Ich sehe grundsätzlich verschiedene Typen von Cloud-IDEs:</p><ol><li><em>Vollumfängliche Entwicklungsumgebungen und -plattformen</em>, die für möglichst viele Anwendungstypen geeignet sein sollen. Diese sind am ehesten vergleichbar mit aktuellen, lokalen Entwicklungsumgebungen – Beispiele sind Eclipse Che, GitPod oder GitHub Codespaces.</li><li><em>Rapid-Development-Plattformen</em>, die für bestimmte Anwendungstypen von Entwicklung bis Produktion (inkl. Infrastruktur) einen durchgängigen Entwicklungsprozess erlaubt, ohne dass man sich um die Infrastruktur kümmern muss (Codesphere, Replit). CodeSandbox würde ich auch hier einordnen, obwohl hier die Infrastruktur im Betrieb nicht im Fokus ist und für Fullstack-Anwendungen keine Durchgängigkeit vorhanden ist.</li><li><em>Low-Code-Ansätze</em>, die ich hier nicht betrachtet habe. Diese fokussieren teilweise sogar konkrete Branchen und gehen über die reine Technologie hinaus.</li></ol><h2>Fazit</h2><p>Es gibt gute Gründe, weshalb auch die IDEs und die kompletten Entwicklungsplattformen in die Cloud wandern – oder zumindest auch per SaaS den Entwicklungsteams zur Verfügung gestellt werden. Auch der klassische Java-EE-Entwickler (wie ich einer war) wird das zu spüren bekommen. Vor allem, wenn die Geschwindigkeit von der Entwicklung zur Produktion (und zurück) und Kollaboration im Team mit modernen Team-Praktiken im Vordergrund steht, wird der Einsatz von Cloud-basierten IDEs kaum aufzuhalten sein.</p><p>Spannend ist, wie sich das Ganze in Zukunft entwickeln wird und vor allem: mit welcher Geschwindigkeit die IDEs adaptiert werden.</p>

Die Zukunft der IDEs – aus Sicht eines „Java-EE-Entwicklers“

Die wirtschaftliche Lage in Deutschland wird sich dieses Jahr nicht schlagartig verbessern – sie bleibt angespannt, der Kostendruck hoch. Zusätzlich belasten Fachkräftemangel, demografischer Wandel und Fragen der digitalen Souveränität den Markt.\nWas hat das mit Tech-Trends und IT zu tun? \nIT und technologische Entwicklungen sind eine Chance, unter Druck handlungsfähig zu bleiben. Trotz der Herausforderungen werden Unternehmen in Deutschland in Tech und IT investieren.\nAus meiner Sicht prägen die folgenden Themen 2026 besonders deutlich, weil sie direkte Antworten auf aktuelle Anforderungen liefern:\nAI‑Powered Software Teams\nDurch den wachsenden Einsatz von AI entlang des gesamten Software‑Lebenszyklus werden Teams anders arbeiten: Product Owner erzeugen Code, Lead Developer sichern Qualität, Architekt*innen gewährleisten Integration in komplexe Umgebungen u. v. m. Mit weniger Personen entstehen oder modernisieren wir schneller komplexe, geschäftskritische, individuelle Enterprise‑Software – bei hoher Qualität.\nAI in den Kernprozessen\nDie Zeit der Experimente und Prototypen ist vorbei: Grundsätzlich hat jedes Unternehmen AI im Einsatz – teils als Pilot, teils produktiv in überschaubaren Use Cases. Der technologische Fortschritt ist so weit, dass viele Unternehmen Kernprozesse jetzt „AI‑native“ implementieren wollen und müssen – auf Basis klarer Business Cases. AI wird im Unternehmen ausgerollt.\nSecurity: Preemptive & AI\nDie Bedrohungslage durch Cyberrisiken bleibt hoch. AI verschärft Angriffe und erschwert die Abwehr. Eine gute Defensive und Forensik allein reichen kaum noch aus. „Preemptive Security“, also permanente, präventive (und automatisierte) Threat‑Bekämpfung, rückt stärker in den Fokus. Mit dem zunehmenden AI‑Einsatz wird AI‑Security (z. B. LLM‑Security, IAM etc.) 2026 zum Fokusthema.\nUse‑Case‑orientierte Gen‑AI‑Lösungen\nNach starker Investition in generische Gen‑AI‑Lösungen (z. B. Chat‑Systeme mit Unternehmensdaten für bessere E‑Mails oder Informationsaufbereitung) und die breite Ergänzung von Tools um AI‑Chat‑Interfaces, folgt der nächste Schritt: spezialisierte Lösungen. SaaS‑Anbieter und Startups bieten zunehmend konkrete Gen‑AI‑Anwendungen für fachliche Use Cases an – basierend auf großen Sprachmodellen, aber bereits stark optimiert. Unternehmen werden diese Lösungen vermehrt einsetzen, weil sie schneller und einfacher zu implementieren sind als Eigenentwicklungen.\nSouveräne Managed Services\n2025 brachte einen deutlichen Schub für souveräne Clouds und europäische Lösungen – politisch getrieben und marktseitig verstärkt. In Europa stehen wir dennoch erst am Anfang; der Einsatz souveräner Managed Services (SaaS, Cloud etc.) wird dieses Jahr prägen.\nDigitale Souveränität und Compliance sind nicht nur bei „Managed Services“ relevant, sondern werden zum Alltag: Bei jeder IT‑Entscheidung sind diese Aspekte mitzudenken. 2025 zeigte zwar, dass AI‑Implementierungen (oft noch nicht „souverän“) nicht gestoppt werden, dennoch müssen Souveränität und Compliance kontinuierlich mitwachsen.\nZusammenfassung\nZusammenfassend wird 2026 in Deutschland das Jahr, in dem AI breit operationalisiert wird – mit klaren Business Cases im Fokus. Das betrifft die Kernprozesse aller Unternehmen. Wichtig sind eine klare Strategie und ein strukturiertes Vorgehen, um in den Folgejahren nicht „Aufräumen“ zu müssen.\nGerade in der Softwareentwicklung werden wir unsere Produktivität mit AI deutlich steigern (müssen). Was in Bereichen wie Prototyping, Apps und Web bereits etabliert ist, wird 2026 bei komplexen, geschäftskritischen Anwendungen mit Lebenszyklen von über fünf Jahren zum Standard.\nEs ist außerdem an der Zeit, Hype‑ und evangelisierende Kommunikation rund um AI zurückzufahren. Aussagen wie „A oder B wird revolutioniert“ helfen nicht mehr – dieses Jahr zählt das Machen.\n

Tech Trends 2026 in Deutschland: KI operationalisieren statt hypen

<p>During the last days I have intensivley worked on performance tuning of XSLs. These XSL are used within an web application to render HTML for presenting screens to the user. In this case, the response time of the XSL processing was not really a problem, but its need of ressources, e.g. CPU time. We wanted to optimze the XSLs or the processing itself to fix this issue.</p><p>First (of course) we “googled” about this. But we realized, that there is not much material about the topic <em>XSL-Tuning</em> in comparison to Java-tuning/-profiling. The most of the entries/sites are old. Also, there are not many tools you can use to profile/tune a XSL transformation. There are some tools (like <a href="http://www.stylusstudio.com/xslt_profiler.html" target="_blank">Stylusstudio</a> , <a href="http://www.oxygenxml.com/xslt_debugger.html" target="_blank">Oxygen</a> ), but in our case the XSL transformationen is done within the web application. Even the XML ist dynamically produced at runtime and we didn’t want to change the application to write an XML output which could have been used to profile it “offline”. Some XSL processors have the possibility to trace profile informations, e.g. you can use a specific parameter for Saxon to log these informationes. We were using Xalan and don’t have this option. Acutally we have tested Saxon with our XSLs, but there was not a performance improvement in our case.</p><p>So we have done it our “normal” way. We used a Java profiler and instrumented the Xalan-classes. We also instrumented the classes (translets) Xalan generates during processing, if you have enabled XSLTC. With the visualisation done by the profiler we could easily recognize, which templates were responsible for the heavy CPU usage. The advantage for us was, that we have structured our XSLs in many templates und used includes/call-templates to call them. You can see this in the profiler. So after we knew, which templates had to be focussed, we tried to optimize them.</p><p>During the optimization we found out, that you need fundamental knowledge of a XSL-transformation, not only the knowledge about which XSL-tags you can alternativley use, but also how a XSL-tag or XPath expression works. The main thing is, that the whole XSLT consist of tree processing and tree operations. It doesn’t matter, if the concrete implementation uses SAX instead of DOM, even Xalan uses an optimzed model (DTM). All tree operations, which navigation through the tree are expensive (e.g. “..”,”//”,”descandant:”). In our case it was worth trying to minize this kind of navigation. We also reduced the size of the XML-input (= the tree is smaller), which increased performance. Other operations on the tree (e.g. “nodeSet()”, which we have used to parse XML within XSL) werde also not cheap in terms of performance.</p><p>In general we have tried out the following optimizations:</p><ol><li>Read the Xalan FAQ und follow the performance recommendations.</li><li>We have tested other XSLT implementations (e.g. Saxon)</li><li>Xalan provides Mechanisms to include own Jaca-Code in your XSL. It’s not the best design-style, but you can in some cases replace “hot” XSL-operations.</li></ol><p>Even für XSL-tuning there ist still the #1-performance tuning rule: Always implement one (only !) optimzation and the measure the success of this step.</p><p>In case of XSLT processing, there are no general rules you can apply (despite of the avoidance of tree operations), because in one XSL (with specific XML data) a operation can be problematic, in other cases it won’t.</p><p>If all the XSL tuning does not help enough, then there is the possibility to let optimized systems/products do the XSL transformations for you (e.g. <a href="http://www-03.ibm.com/software/products/en/ibm-datapower-gateways" target="_blank">IBM Datapower</a> , Layer7). We tested the IBM Datapower appliance and the speed of the XSL transformations was incredible. Of course, if you want to use such an appliance, there are other things which are worth to think about (administration, integration in the application architecture, etc.)</p>

Gründer und Vorstand

Founder and CEO

Du hast Fragen oder möchtest dich zu deinen Herausforderungen austauschen? Gern – trag einfach deine Kontaktdaten ein.

Kontaktanfrage | Sales (allgemein)

Kontakt

Kontakt aufnehmen

Die Zeit der IT als Flaschenhals ist vorbei. Mit KI-nativer Softwareentwicklung geben wir deinen Business-Ideen endlich Vorfahrt. Lass uns auf der insureNXT gemeinsam darüber sprechen, wie wir deine IT zum echten Business-Enabler machen. Ich freue mich auf den persönlichen Austausch.

Warum wir Software neu denken müssen

Code ist kein Engpass mehr. Mit KI-nativer Softwareentwicklung wird dein Business schneller. Erfahre mehr auf der insureNXT 2026 – wir freuen uns auf dich!

Zukunft sichern: Mit KI-nativer Softwareentwicklung als Business-Turbo

Code entsteht KI-nativ. Business wird zur Priorität.

Zur insureNXT

Du willst, dass deine IT endlich zum Business-Enabler wird? Dann triff uns auf der inusreNXT 2026 in Köln! Wir zeigen dir, wie du mit KI-nativer Softwareentwicklung den Flaschenhals „Code“ beseitigst und deine IT-Abteilung zum Business-Enabler machst.

inusureNXT 2026: AI Native. Insurance Driven. Zero Bottlenecks.

insureNXT 2026

Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Data Effectiveness

Digitale Produkte & Lösungen

Digitale Souveränität

IT-Security

Künstliche Intelligenz

Software-Modernisierung

Leistungen von A bis Z ...

Leistungen

Arbeitsweise

Referenzen

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Events

Fachmedien

Softwerker

Webinare

Wissens-Hub

Jobs

Unsere Kultur

Karriere

Über uns

Aktuelles

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

insureNXT 2026

inusureNXT 2026: AI Native. Insurance Driven. Zero Bottlenecks.

Zukunft sichern: Mit KI-nativer Softwareentwicklung als Business-Turbo

Code entsteht KI-nativ. Business wird zur Priorität.

Warum wir Software neu denken müssen

Jetzt für unseren Newsletter anmelden