Fallstricke bei der Middleware-Verwaltung 8. Unreife Anwendungen

Dies ist Nummer 8, der dritte Artikel in einer Top 10 der Middleware-Management-Fallen. Der vorherige Artikel befasste sich mit der Infrastruktur. Diesmal geht es um die Anwendung selbst. In letzter Zeit wurde viel über Devops und die Zusammenarbeit von Devs und Ops in einem Team berichtet, wie zum Beispiel bei sky.com. Die uncoole Realität in vielen Unternehmen ist, dass Entwicklung und Betrieb in verschiedenen Abteilungen getrennt sind und nicht gut miteinander kommunizieren. Das Ergebnis sind unausgereifte Anwendungen, zumindest aus Sicht der Middleware.

Eines der Ziele von Middleware ist es, den Anwendungsprogrammierern Standardkomponenten zur Verfügung zu stellen. Zwei der schönsten und am weitesten verbreiteten Beispiele dafür sind JDBC und die Datenquelle. JDBC ist ein Industriestandard und stellt eine leistungsstarke Abstraktion dar, die von Softwareanbietern bereitgestellt wird, um die Kommunikation mit ihrem Datenbankprodukt zu ermöglichen. Die Datenquelle ist eine weitere Abstraktion, die von Anwendungsserver-Administratoren bereitgestellt wird, um die Kommunikation mit der von ihrem Unternehmen verwendeten Datenbank zu ermöglichen. Letztere verbirgt Funktionen wie Connection Pooling, Statement Caching und datenbankspezifische Eigenschaften. In den Anfängen von J2EE waren jedoch Anwendungen zu finden, die diese Funktionen nicht nutzten. Stattdessen hatten die Anwendungsprogrammierer beschlossen, sie von Grund auf neu zu entwickeln. Viele Xebianer haben in der Vergangenheit diese selbstgebauten "Frameworks" entfernt und benutzerdefinierte Konstrukte durch Datenquellen und dergleichen ersetzt. Diese Zeiten sind nun vorbei....oder, so scheint es. Es sind nicht mehr die hausgemachten Datenquellen, die uns Sorgen machen sollten. Anwendung erfindet Plattform neu, wieder einmal. Und warum? Weil Entwickler nicht wissen, auf welcher Plattform ihre Anwendungen laufen. Der Grund: Middleware-Produkte sind ungeheuer kompliziert geworden, ihre Reichweite hat sich in ferne Galaxien ausgedehnt, ihre Tiefe ist so unbekannt wie die Tiefen des Ozeans. Übertreibe ich? Architekten können sich nicht mehr auf den reinen Codierungsteil einer Anwendung konzentrieren. Die Zeiten, in denen es nur Servlets und EJBs gab, sind vorbei. Wir sind mit ESBs, BPM, J2EE, CMS und einem wachsenden Integrationsbedarf mit allen möglichen Backends konfrontiert. Eine unausgereifte Anwendung wäre eine, die einen ESB neu erfindet. Oder denken Sie an ein Unternehmen, in dem die Middleware-Abteilung eine BPM-Plattform (wie die Oracle SOA Suite oder den Websphere Process Server) gekauft hat, aber gleichzeitig die Choreographie von Webservices mit einfachem Java implementiert, weil ihnen noch keine Architekturrichtlinien (die den Einsatz von BPM vorschreiben) vorgelegt wurden. Der Begriff "unreif" bezieht sich auf die "Reife" des jeweiligen Middleware-Stacks.

• Unausgereifte Sicherheit stellt ein Sicherheitsrisiko dar.
• Unreife Anwendungen haben mehr Bugs
• Eine unausgereifte Anwendung kostet mehr als nötig und macht die von den Middleware-Anbietern versprochene Kostensenkung zunichte. Unausgereifte Anwendungen haben eine höhere TCO, da der Verwaltungsaufwand auch nach der Inbetriebnahme anhält.

Ich will damit nicht sagen, dass Sie verpflichtet sind, die Lösung des Middleware-Anbieters für ein bestimmtes Problem zu verwenden. Nehmen Sie Webdienste. Es gibt viele ausgereifte Open-Source-Stacks, mit denen Sie diese erstellen können, ohne die (veraltete) Lösung des Herstellers zu verwenden. Es ist Sache des Architekten, solche Entscheidungen zu treffen. (Was ist der grundlegende Unterschied zwischen einer Bibliothek und Middleware? Beide sollten Ihr Leben als Programmierer einfacher machen). Alle Unternehmensanwendungen benötigen ein Mindestmaß an Qualität in Bezug auf Einsatzfähigkeit und Wartungsfreundlichkeit:

• Angemessene Protokollierung
• Eine einfache und standardisierte Methode zur Bereitstellung von Umgebungsspezifika (Eigenschaften)
• Wiederholbarer (automatisierter) Build-Prozess
• Freigabe- und Bereitstellungshinweise (Richtlinien für den Bereitsteller)
• Leistungstests inklusive
• Keine Auslieferung von einzelnen jar-Dateien oder jsp's (niemals)
• Sicherheitsrichtlinien
• Richtlinien für die Verwendung von Open-Source-Bibliotheken (welche und welche nicht, und ob und wann sie aktualisiert werden sollen...)

Entwickler sollten diese Regeln kennen und anwenden. Administratoren sollten sie kennen und durchsetzen. Alle Unternehmen, die ihre Middleware effektiv nutzen wollen, brauchen jemanden, der als Interessenvertreter für die Verwaltungsabteilung fungieren kann. Er oder sie muss aktiv das Middleware-Wissen unter den Entwicklungsteams, Architekten, Designern und Administratoren verbreiten. Die Analyse muss zur Identifizierung von generischen Diensten führen, die wiederverwendet werden können und werden. Die Architektur und die Arbeitssoftware sollten entsprechend implementiert werden. Falls erforderlich, muss eine Reihe von Kriterien aufgestellt werden, die als Barriere gegen Unausgereiftheit dienen. Stellen Sie sich ein Tool vor, das die von den Entwicklern gelieferten Produkte (EAR-Dateien) prüft und einen Bericht erstellt, der eindeutig angibt, ob eine Anwendung bestanden hat oder nicht (AFAIK gibt es so etwas nicht).

• Der Einsatz von Middleware wirkt sich auf das Risiko und die Anzahl der Story Points der einzelnen User Stories aus. Daher sollte der Middleware-Architekt an den Planungsbesprechungen teilnehmen. Zumindest solange, bis die Entwickler wissen, wie es geht.
• Ein Middleware-Kompetenzzentrum ist eine Möglichkeit, Wissen und Praktiken zu bündeln. Es besteht aus einem Team von Fachleuten mit unterschiedlichem Hintergrund, Architekten, Entwicklern, Implementierern, Administratoren, DBAs usw. Sie dienen dazu, das Middleware-Wissen zu bündeln und zu verbreiten.
• Lean Thinking und Kanban sind eine Möglichkeit, das Team des Middleware Centers zu organisieren und zu optimieren. Es gibt eine kleine Anzahl von interessanten Blogs (danke @nistude) zu diesem Thema. Ich werde in naher Zukunft über meine eigenen Erfahrungen bloggen.