Tiefe Kenntnisse von Applicationservers


#1

Wenn in einem Project ein Application Server benutzt wird, dann es ist klar, dass Grundkenntnisse vom Application Server sollen sowohl ein Entwickler als auch Software Architect haben.
Aber was wenn es um tiefe Application-Server Kenntnisse geht?
Soll z. B. Software Architect ein gutes Wissen in Tuning von Application-Servers (WebLogic, JBoss EAP usw) haben?
Oder DevOps beschäftigt sich damit? Oder noch jemand anderer?
Wie sieht das am öftesten bei euch in Projekten?


#2

Hallo,

deine Fragen sind immer sehr allgemein gehalten, ich versuche mich aber trotzdem mal an einer Antwort, im Hinblick auf verschiedene Rollen:

  • Entwickler
  • Müssen meistens wenig über die Application Server wissen. Umgebungsvariablen, Realms, Policy Sets und Clusterfähigkeit der Applikation und JDBC Resources sollten bekannt sein, also alles was direkt mit der Anwendung zu tun hat.
  • Architekten
    • Hierfür müsste man erst einmal “Architekt” definieren.
    • In meinem aktuellen Projekt gibt es z.B. einen Systemarchitekten, der für die Produktionsumgebung zuständig ist, Abwärtskompatibilität, Clusterfähigkeit und Failoverkonzepte sicherstellt. Dieser Mensch sollte schon tiefergehendes Wissen von den verwendeten Application Servern haben, da er ansonsten schlicht und einfach seinen Job nicht machen kann
    • Außerdem haben wir noch einen Enterprise Architekten, der sich abstrakt mit der Kommunikation zwischen Systemen, den zu verwendeten Zielsystemen und fachlicher Architektur beschäftigt. Erforderliches Wissen über Application Server: 0
  • DevOps
    • Die Kollegen von DevOps in unserem Projekt sind für automatisierte Deployments und Continuous Integration zuständig, haben damit naturgemäß viele Berührungspunkte mit Applicationservern. Zu ihren Aufgaben gehört das verkskripten und Automatisieren aller Deployments, Stagings und Konfigurationsänderungen, sie haben meinstens gute bis sehr gute Kenntnisse von Application Servern.

#3

Die Grundidee von JEE und Application-Servern ist, eine einheitliche Schnittstelle zu im Geschäftsumfeld nützlichen Services anzubieten. Application-Server sollten deshalb zumindest prinzipiell austauschbar sein. Wenn man gezwungen ist, jedes Detail des jeweiligen Application-Servers kennen zu müssen, ist etwas ganz, ganz falsch gelaufen. Dort Resources reinzustecken, hintertreibt die Idee dahinter. Wenn überhaupt, würde ich eher externe Hilfe in Anspruch nehmen, da so etwas hoffentlich nicht zu einer regelmäßige Angelegenheit werden sollte.

Wenn im aktuellen Umfeld die Notwendigkeit für Detailwissen sehr stark zu spüren ist, würde ich zuerst schauen, ob es andere Application-Server gibt, die leichter zu handhaben sind. Wenn auch das nicht der Fall ist, kann es durchaus sein, dass Application-Sever generell der falsche Lösung für die Aufgabe sind. Eine Aufgabe, die nicht den Annahmen der Architektur von Application-Servern entspricht, erfordert eben eine eigene Architektur. Wenn ich schon in einem Gebiet “tiefe Kenntnisse” benötige, dann bitte zu meinen Konditionen, in einem Umfeld, das ich selbst unter Kontrolle habe, und nicht der Anbieter meines Application-Servers. Sich sehenden Auges in eine derartige Abhängigkeit zu begeben, fordert eine Katastrophe geradezu heraus.


#4

Oft werden embedded Versionen von “ApplicationServern” verwendet, im MicroService Umfeld reicht es oft, einen embedded Tomcat oder embedded Jetty zu nutzen (Spring Boot etc.), da man die Features der “fetten” JEE ApplicationServer sowieso nicht braucht bzw. weil diese Features die Nachteile, die man sich durch Komplexitaet und Ressourcenverbrauch erkauft, es einfach nicht wert sind.


#5

Vielen Dank für ihre Antworten. Sehr Aufschlussreich.
Sagt mir noch bitte. Programmiert bei euch auch Software Architect? Soll im Allgemeinen der Software Architect auch programmieren.
Meiner Meinung nach, soll definitiv, besonders Software Architect (Kernpunkte im Projekt)! Aber vielleicht irre ich mich.
Ich frage nur weil ich gehört habe, dass nicht überall es so ist und bin gespannt wie es bei euch aussieht.


#6

Ich bin ganz klar dafür, dass ein Softwarearchitekt an dem Produkt mitwirken sollte. Sicherlich programmiert diese Person nicht Nine-To-Five mit, aber die Schmerzen und Probleme sollte man auch am eigenen Leib erfahren. Zudem halte ich dies für weitere Architekturentscheidungen notwendig.


#7

Wenn der Software Architekt nicht mitentwickelt, fehlt das Feedback wie sinnvoll seine Lösungen sind. Da gibt es eine sehr schöne Anekdote in “Domain Driven Design” von Eric Evans: Der Kunde hat ihm gesagt, er wäre zu teuer um zu entwickeln und hat ihm die Mitarbeit am Code verboten. Das war wohl das katastrophalste was er jemals abgeliefert hat, und er würde es nicht wiederholen.


#8

Doch, bei uns schon.
“Bildchen malen” kann der in seiner Freizeit, macht aber keiner unserer Architekten :wink:


#9

Ok, spannend. Ich denke, Dokumentation ist eine wichtige Aufgabe in der Architektur. Das kann ich nicht immer “programmieren”. Ganz autark ist man meist ja nicht von seiner Umwelt. Wie behandelt ihr da Abstimmungen, die vielleicht auf Makro-Ebene getroffen werden?


#10

“Dokumentation” ist nebensaechlich zu funktionierender SW, letztere aendert sich staendig, funktionierende Beispiele in Form von Code sind wichtiger als Bildchen, “Abstimmungen auf Macro Ebene” sind auch nicht wirklich relevant wenn das nirgendwo umgesetzt wurde.

Wenn jemand etwas neues vorstellt, dann kann man initial vielleicht mal erzaehlen/Diagramme verwenden um zu kommunizieren, aber wenn das danach nicht in Form von Code gegossen wird, existiert es dann wirklich? :wink:
Was fast taeglich verwendet wird beim Pairing ist der Notizblock und ein Bleistift, Diskussion werden im kleineren gerne im IM gefuehrt, Dinge wie ein “Code Forum” gibt es 2-woechentlich, da kann man dann neue Konzepte allen Entwicklern der Abteilung vorstellen und diskutieren.

Ein Beispiel fuer “Abstimmungen auf Makroebene” waere zB. auf React im Frontend zu setzen, die Schnittstellen zum Backend sind REST Services, Bilder dazu kann man googeln, ist ja nicht gerade revolutionaer wenn man ehrlich ist, und das trifft auf viele Architekturen zu.
Ansonsten wird viel (zu viel?) ueber das interne Wiki kommuniziert, da gibt es dann auch Bildchen, aber diese sind nicht notwendigerweise von Architekten angefertigt.
Die Architekten sind meist in den PRs als Reviewer dabei, zumindest in den “wichtigen”, da gibt es dann die Moeglichkeit Feedback zu geben.

Liegt alles vielleicht auch daran dass SW bei uns DIE Produkte sind (100%), nicht nur komplementaere Komponenten um eigentlich Produkte herum, die Prozesse sind auch nicht aus dem Automobilbau bzw. Luft-Raumfahrt entlehnt.

Ist natuerlich nicht alles Perfekt, aber ich hab schon in Grosskonzernen gearbeitet, da sassen alle Architekten in einem Kaemmerchen und hatten eigentlich gar Ahnung wo der Schuh im taeglichen Leben des Entwicklers, des Admins oder gar des Kunden so drueckt.


#11

Naja, auf Makroebene würde ich auch Dinge klären wie

  • Wie sprechen Services robust miteinander (z.B. wenn ein Dienst offline ist)
  • Was gibt es für Randbedingungen (z.B. an die Infrastruktur, Programmiersprachen, …)
  • Gibt es übergreifende nichtfunktionale (und vielleicht funktionale) Anforderungen?
  • Wie sehen meine Domains aus?

Natürlich sollte sich eine Software nebenbei mit dokumentieren. Allerdings ist das nicht Programmieren sondern Dokumentieren. Natürlich sollte sich eine Software im besten Falle selbst dokumentieren. Aber übergreifend finde ich so etwas schwierig.

Ich bin ganz klar dafür, dass sich Architekten eben nicht aus den Projekten herausziehen, sondern mitarbeiten. Und von einem Architekturwasserkopf halte ich überhaupt nichts. Aber Abstimmungen auf übergreifender Ebene halte ich für wichtig.