Irgendwie hört man momentan über all von DevOps. Ein DevOp ist wohl jemand der nicht nur entwickelt sondern auch den operativen Betrieb mit überwacht und diesen vielleicht auch komplett in Eigen-Regie betreut. Jedenfalls liest man solch eine Interpreation oft (ob diese jetzt die korrekte Interpreation ist sei mal dahin gestellt...).
Dieses Konzep ist jetzt nichts neues. In kleine Firmen ist sowas einfach normal (und läßt sich nicht ändern, weil man einfach zu wenig Personen hat und man alles eben übernhmen können muss) und in großen Firmen setzt sich sowas wohl auch immer mehr durch. Wenn man meine Arbeit betrachtet, könnte man auch mich als DevOp bezeichnen.
Dann wäre ich voll hip und modern. Aber am Ende will ich dass nicht unbedingt sein. Arbeitsteilung ist an sich gut und bringt viele Vorteile:

* Man kann sich auf eine Sache konzentrieren
* Wissen ist nicht in einer Person konzentriert (Wenn diese Person ausfällt bleibt Wissen vorhanden)
* Es ist alles transparenter, da mehrere Leute eingebunden sind
* Man kann sich nicht überall perfekt auskennen, deswegen sollte man nichts machen, wo man sich nur halb auskennt, wenn jemand da ist der sich damit besser auskennt

Warum aber gibt es diesen DevOps-Gedanken und warum soll damit alles so viel schneller und einfacher gehen?

* Weil es unglaublich schwer ist brauchbare Schnittstellen zwischen Teams und Abteilungen zu etablieren
* Weil es schneller geht etwas selber zu machen, als jemanden es zu erklären und einzuarbeiten
* Weil man nicht viel Doku schreiben muss, weil man es ja selber schon alles weiß
* Weil die Software so komplex ist, dass Deployment und Fehler-Analyse nur mit tiefgreifenden Kenntnissen der Software möglich ist
* Weil Menschen schlecht skalieren... weil Menschen bei der Zusammenarbeit viel Overhead erzeugen

Das Problem ist einmal die Schnittstellen innerhalb der Firma sowie deren Prozesse und einmal die Komplexität der Software. Gerade im Java-Bereich (JEE) ist es sehr ausgeprägt. Frameworks. Es gibt tausende von Frameworks. Für jeden Zweck und wenn man alles kombiniert und alles an Libs in den richtigen Versionen hat, hat man meistens schon so ein komplexes Konstrukt, dass es dann schon oft eine Tagesaufgabe ist den Workspace auf einem anderen Rechner einzurichten.
Einen JBoss/Wildfly zu installieren, zu starten und zu stoppen ist ja noch gut möglich. Datasources einrichten und Anpassungen vornehmen braucht schon etwas wissen. Wenn man dann für eine Anwendung noch eigene Module und Adapter braucht, wird es oft schon so speziel und spezifisch für die eine Anwendung, dass man ohne grundlegendes Wissen schnell Probleme bekommt.
JPA, Logging, Module + Versionen... alles exakt so einrichten, dass es so läuft wie auf dem Entwicklungsrechner.. viel Arbeit.
Bevor man nun anderen Personen alles erklärt und dann bei Problemen tausend nachfragen kommen, denkt man sich oft: "Mache ich es doch lieber selber!".
Also am Besten einfach alles genau so übernehmen wie es auf dem eigenen Entwicklungsrecher eingerichtet ist. Aber jede Änderung abgleichen ist natürlich auch doof. Deswegen wird all das möglichst mit in die Anwendung gezogen. Besonders die Konfiguration.

Ich erinnere mich noch an meine ersten Web-Projekte mit dem Tomcat. Damals noch mit Tomcat 4. DataSource hab ich in der server.xml eingetragen und mein Projekt als WAR deployed. Dann lief es. Es gab nur die DataSource mit einem bestimmten JNDI-Pfad. Wenn diese vorhanden war lief es. Die WAR jemanden zu geben, der sie dann deployte war kein Problem.
Aber dass war dann irgendwann nicht mehr so toll, weil für jede deployte Anwendung die server.xml anzupasen war nicht toll. Die Server wurden von Administratoren verwaltet, die aber sich nicht wirklich mit Tomcat auskannten und die zentralle server.xml anzupassen konnte natürlich dazu führen, dass andere Anwendungen dann nicht mehr liefen, wenn man was falsch machte.
Also wanderte viel die in context.xml. Mit JPA kam noch die persistence.xml dazu und weil man ja Unit-Tests machen wollte, hat man den Datenbank-Server dort direkt eingetragen und keine Datasources von der Server-Umgebung mehr verwendet. Das Logging ging auch gleich mit in die Anwendung und die Anwendung hat bestimmt in welche Datei gelogt wurde und was wie gelogt wird. Wenn man mal was anderes
Loggen wollte.. tja.. Anwendung neu bauen und neu deployen.

Wenn man jetzt noch mehr Framworks hat, die auch gerne Config-Daten haben wollen, nimmt man natürlich die auch gleich mit rein, weil der Entwickler es ja einmal alles eingestellt hat und man die Dateien dann nicht kopieren muss oder am Ende sogar noch mal komplet selbst anlegen muss.

Man bekommt also eine komplet vorkonfigurierte Anwendung die man dann deployed, die aber dann auch nur für diesen ganz speziellen Fall funktioniert. Datenbankserver ändern oder URLs zu externen System wechseln.. das geht nicht so einfach und die Anwendung muss komplett neu gebaut werden, wenn sowas mal passieren sollte.
Das macht natürlich alles für die Server-Admins simpler, da einen sauberen Server zu installieren einfach ist. Der Entwickler übernimmt dafür alles. Konfigurierbare Anwendungen sehe ich immer seltener. Was aber den Admins natürlich auch einen Teil der Kontrolle über die von denen betreuten Systeme nimmt und das gefällt natürlich auch nicht wirklich.

Was wären Lösungen? Schwer zu sagen. Meine Ideen wären:

* Anwendungen sollten möglichst "unkomplex" sein
* Die Anwendung sollte nicht vorkonfiguriert sein bzw die config sollte sich im Server überschreiben lassen
* Der Admin sollte sich mit der Umgebung auskennen und sollte wissen wie man die Anwendung und Umgebung konfiguriert
* Einfaches Deployment: Anwendung + Deployment-Descriptor (Config-Daten) in die Umgebung kopieren und Deployment starten
* Anwendungen sollten gut von ein ander isoliert sein
* Anwendungen sollten sich von Außen so gut anpassen und konfigurieren lassen, so das der Admin mit etwas Glück kleine Probleme beheben kann ohne das Code angefasst werden muss
* Die Umgebung aus AppServer/Servlet-Container mit einer Zusammenstellung der benötigten Frameworks sollten bei allen Projekten standardisiert werden. Also eine Person stellt immer aktuelle Zusammenstellungen zusammen, die dann von den Entwicklern verwendet werden und wenn möglich auch immer auf die aktuellen Versionen updaten.

Natürlich sollte sich jeder Entwickler grundlegend mit allem von AppServer bis zum Logging-Framework auskennen. Aber er sollte sich auf die Entwicklung konzentrieren und den normalen Betrieb der Anwendungen jemanden überlassen der die Serverumgebung sehr gut kennt und dort auch Performance- und andere Probleme lösen kann und die gesamte Infrastruktur verwaltet. Die Infrastruktur ändert sich laufend und die Anwendung sollte sich einfach und unkompliziert darauf anpassen lassen. Eine XML in einem Package in einer JAR im Lib-Verzeichnis einer WAR in einem Tomcat ist genau so schlimm, als wenn man die Daten direkt hart in eine Klasse kodiert hätte. Meiner Meinung nach müssen Config-Daten (ob aus einer Datei oder der Datenbank) zur Laufzeit änderbar sein.

Aber am Ende muss man sagen, dass ich auch schon oft genug gedacht habe "Hätte ich es doch einfach gleich selber gemacht...". Man braucht Vertrauen und einen Draht zu einander. Deswegen sollte man Teams vielleicht nicht horizontal aufbauen, sondern vertikal. Die Idee, dass einer alles macht, ist wohl auch weniger die grundlegende Idee hinter DevOps gewesen. Auch dass alles wieder in Software-Tools und so enden muss, sehe ich eher kritisch, weil man Komplexität oft nicht durch mehr Komplexität lösen kann.
Am Ende darf es eben nur ein DevOp-Team geben, wenn man das Konzept umsetzen möchte. Ein DevOp in einer Person ist unsinnig bzw bedingt sich selbst. Im Team müssen die Schnittstellen und die Rücksichtnahme zwischen den Fachbereichen geschafen und gelebt werden. Man sollte also Kompetenzen nicht versuchen zusammen zu fassen, sondern diese nur dichter zu einander bringen.

Links:

http://slott-softwarearchitect.blogspot.com/2015/03/it-appears-that-devops-may-be-more.html
http://jeffknupp.com/blog/2014/04/15/how-devops-is-killing-the-developer/
https://www.codecentric.de/kompetenzen/publikationen/die-devops-bewegung/