Wer kennt das nicht? Man interessiert sich für ein neues Auto einer bestimmten Marke in einer bestimmten Farbe und auf einmal fahren (vermeintlich) sehr viele Autos dieses Typs durch die Gegend. Zumindest meint man das.
Dieses Phänomen nennt man in der Psychologie „*selektive Wahrnehmung*“.
Es ist eine dieser unglaublichen Leistungen des menschlichen Gehirns, Muster zu erkennen und darauf basierend ganz bestimmte Aspekte dieser Muster aus der Flut von Informationen und Eindrücken herauszufiltern. Das macht es dem Gehirn erheblich leichter neue Informationen mit vorhandenen zu verknüpfen und sie so effizienter zu speichern.
Man spricht von „selektiver Wahrnehmung“ auch dann, wenn ein Mensch auf ein bestimmtes Thema fixiert ist.
Das kann dazu führen, daß andere Informationen mit gleicher Priorität überhaupt nicht mehroder nur noch spärlich wahrgenommen werden.

Was hat das mit IT zu tun?

In unserer Industrie wird in unregelmäßigen Abständen immer wieder eine komplett neue, noch nie zuvor dagewesene „neue Sau durch’s Dorf getrieben“.
Vor einigen Jahren war es zunächst Java, dann J2EE, JSPs und EJBs. Zustäzlich wurden immer wieder neue Frameworks erfunden und immer gab es eine noch bessere, noch effizientere Methode (Java-) Software zu erstellen.
Manche Diskussionen über diese Themen erinnerten mich an die „Flame-Wars“ aus den Anfängen der BBS, als man noch mit 1.200 baud Texte in grünen Buchstaben auf schwarze Bildschirmhintergründe hämmerte.
Gestern hatte ich ein sehr interessantes Gespräch über die Bedeutung von Java-Applikations-Servern in der heutigen IT-Welt. Braucht man sie überhaupt noch und wenn ja wofür?
Es gibt sie noch und es wird sie auch noch eine ganze Weile lang geben, denke ich. Für mich drängt sich der Vergleich mit „COBOL“ auf. Auch heute noch gibt es einige Systeme, die immer noch COBOL Code ausführen. Auch wennn es fast täglich weniger werden, so bieten sie einigen Kollegen immer noch eine Lebensgrundlage.
Jetzt macht die Meldung die Runde, daß der letzte Programmierer der Raumsonde Voyager in Rente geht und man jemanden sucht, der sowohl Fortran, als auch Assembler beherrscht und der Programme in 64 KB RAM fehlerfrei zur Ausführung bringt.
In letzter Zeit sind die Projekte, in denen meine Weblogic-Kenntnisse gefragt waren, immer weniger geworden. Dafür werden die Anfragen mehr, die sich um den Themenbereich „Migration von Weblogic auf [irgendeine neuere Technologie]“ beziehen. Das wundert mich nicht wirklich.
Seit ich mich mit Virtualisierung (~ 3 Jahre) und jetzt auch mit Docker (~ 1 Jahr) beschäftige, habe ich den Eindruck, daß man in unserer Industrie immer mehr darüber nachdenkt diese „Dinosaurier“ (aka Java-Applikation-Server) los zu werden, bzw. durch neuere, modernere Technologien zu ersetzen. Gerade wenn es um kurzfristige dafür aber sehr hohe Lastspitzen geht, bietet die herkömmliche Technologie nicht immer genügend Flexibilität und Leistungsfähigkeit. Oder anders herum ausgedrückt, wer will sich für zwei signifikante aber außerordentliche Lastspitzen die dafür notwendigen Ressourcen anschaffen, wenn er sie maximal 10 Tage im Jahr wirklich braucht?
Das ist nicht nur „totes Kapital“, sondern solche Server veralten schnell und haben dadurchkeinen guten RoI. Also, warum sollte man mehrere zigtausend Euros „herumstehen“ lassen. Das geht doch mit kurzfristig hinzugemieteten Ressourcen aus der Cloud viel leichter, schneller und erheblich kostengünstiger.
Auch wenn die Java-Applikations-Server versprachen den Modularitätsgedanken in die Tat um zu setzen, so sind doch viele große, schwergewichtige und leider auch schlecht zu wartende „Software-Giganten“ darauf entstanden. Zum einen, weil man immer mehr Funktionalität in solche Applikationen hineingezwängt hat und zum anderen, weil man glaubte, es sei besser „alles“ in einer Applikation zusammen zu fassen. Manchmal spielten auch Unternehmens interne Entscheidungen aka „Politik“ bzw. „Head-Count“ eine nicht unwesentliche Rolle.

Retten „Microservices“ und „DevOps“ die Welt?

„Microservices“ und „DevOps“ sind die neuen Schlagworte mit denen ab sofort die Software-Welt gerettet werden soll.  Damit sollen die bisherigen, mächtigen Web-Applikationen abgelöst bzw. ersetzt werden.
Aber sind es auch die richtigen Werkzeuge dafür oder ist es nur wieder eine der neuen Sauen, von denen in zwei Monaten kaum noch einer spricht?
Auf den ersten Blick erscheint mit diesen neuen Technologien fast alles leicht lösbar; man zerlegt größere Applikationen in kleine Microservices und fertig!
Fertig?
Auch wenn es immer mehr Applikationen gibt, die sich an Webservices bedienen, so sind sie nicht so leicht aus ihrem bisherigen Kontext heraus zu lösen und häufig zeigt sich, daß der Teufel auch hier im Detail steckt. Außerdem stellt sich die Frage, ob es nicht leichter und effektiver ist, die Funktionalität auf dem neuen Technologie-Stack neu zu implementieren und die vielen Vorteile der neuen Technologien effizienter zu nutzen.
Doch nur weil man eine neue Technologie hat, die auf die ersten Blicke viele Dinge erleichtert und bisherige Probleme leichter lösbar erscheinen läßt, so sollte man reflektieren, ob man nicht der „selektiven Wahrnehmung“ aufsitzt. Wenn auch in allerbester Absicht.
Die Faszination für die neuen Technologien kann schnell dazu verleiten, daß man Alternativen nicht beachtet und entsprechend würdigt bzw. prüft. Denn nicht immer ist es notwendig bereits gelöste Probleme mit neuen Mittel erneut zu lösen.
Die immer noch im Einsatz befindlichen COBOL Programme sind der Beweis dafür, daß man auch mit „veralteter“ Technologie erfolgreich arbeiten kann.

  • Müssen wir eine Kundenverwaltung, mit einem innovativen Java-Script-Framework auf einem Node.js Server in Docker Containern neu implementieren, wenn die bisherige Version in COBOL auf dem Mainframe noch alle Anfragen schnell und zuverlässig beantwortet? Welchen Mehrwert schafft das und wie groß ist er?
  • Müssen wir eine bestehende Web-Applikation in kleine Stücke zerlegen, um sie als Microservices in (Software-) Containern zur Verfügung zu stellen und bringt das den gewünschten, meßbaren Mehrwert?
  • Müssen wir bestehende, robuste und sehr leistungsfähige Datenbank-Systeme auf eine neue Technologie-Plattform heben, nur weil diese RDBM-Systeme nicht mehr „hippster“ sind?
  • Müssen wir nicht alle bestehenden Systeme durch diese neue Technologie ablösen, weil wir damit eine viele Faktoren bessere Auslastung der bestehenden Infrastruktur erreichen?

Häufig zeigt sich, daß man durch eine solide Analyse und den geschickten Einsatz neuer Technologien in Verbindung mit den bestehenden Systemen einen erstaunlichen Mehrwert erzielen kann. Schließlich gibt es aber auch diese Situationen, in denen man den Mut haben muß ein bestehendes, bewährtes System durch ein neues zu ersetzen.
Denn erst durch den geschickten Einsatz eben jener neuen technischen Möglichkeiten ist man in der Lage bisher unmöglich Scheinendes in Software zu gießen und Funktionalitäten anzubieten, die den entscheidenden Wettbewerbsvorteil bringen. Sei es nun, daß man schneller auf Marktsituationen reagieren kann, sei es, daß man etwaige Sicherheitslücken sehr viel schneller schließen kann oder sei es, daß man den kompletten Stack eine Version höher hebt.
Die neuen Technologien ermöglichen eine Frequenz neue Releases in Produktion zu bringen, die bisher als völlig utopisch erschienen. Gegenwärtig arbeitet eine große, internationale Bank daran ihren kompletten (!) Web-Auftritt mit aller dahinter liegender (Backend-) Funktionalität in weniger als 10 Minuten komplett austauschbar zu machen. Solche Vorhaben benötigten bisher mehrere Wochen!
Demnächst ist es also möglich, mehrmals am Tag ein neues Release in Produktion zu bringen. Ob das immer angezeigt und erforderlich, ja überhaupt sinnvoll ist, muß im Einzelfall bewertet werden.

Die Frage für die Antwort „42“

Die wichtigste Frage ist, wann soll man sich für was entscheiden und warum?
Es ist nie leicht gewesen solche Entscheidungen zu treffen und häufig spielt eine gehörige Portion „Bauchgefühl“, „Intuition“ und nicht zuletzt ein gewisses Quentchen Glück eine entscheidende Rolle.
Aber in den meisten Fällen führt nur der Weg über eine eingehende Analyse und Betrachtung der Prozesse sowie der Geschäftsabläufe zum Erfolg.
Gerne wird dabei übersehen, daß diese neuen Technologien eine gewaltige Menge an Veränderungen mit sich bringen.
So kann es sein, daß bisher unverzichtbare Qualifikationen und jahrelange Erfahrung nicht mehr in dem bisherigen Maße oder auch gar nicht mehr gebraucht werden.
Zum Beispiel: Ein Wechsel der Technologie der Datenhaltung, etwa von einer OracleDB basierten Plattform auf ein stark verteiltes Datenbank-System wie Cassandra, kann das Wissen und die jahrzehnte lange Erfahrung von Mitarbeitern mit Oracle Datenbanken weniger bedeutsam oder gar obsolet machen.
Doch dieses Wissen und dieser profunde Schatz an Erfahrung ist von unschätzbarem Wert für Unternehmen. Es wäre ein großer Fehler diese Mitarbeiter nicht in die „neue Welt“ mitzunehmen.
Auch das ist ein sehr wichtiger Aspekt einer Technologie-Migration.
Meiner Meinung nach kann man viele technische und organisatorische Fragen durch kleinere Pilotprojekte vorab klären, aber eben nicht alle.
Häufig ist die Intuition von erfahrenen Mitarbeitern der Schlüssel zum Erfolg einer solchen Migration und nach meiner Erfahrung unabdingbar.
Es ist jeder neuen Technologie inhärent, daß man manche ihrer Auswirkungen nicht immer valide einschätzen kann oder die Wechselwirkungen mit anderen Technologien unterschätzt. Aber das darf nicht der Anlaß sein sie nicht einzusetzen. Es kommt viel mehr darauf an alle Aussagen zu validieren und entsprechend zu bewerten. Ganz konkret für den jeweiligen Einzelfall.
Als Beispiel mag folgende Aussage dienen:

(Software-) Container lassen sich sehr leicht sowhl horizontal als auch vertikal skalieren!

So heißt es zumindest!
Aber wie immer entscheidet die Empirie und nicht eine selektive Wahrnehmung oder Wunschdenken.

Eure Meinung

Deswegen interessiert es mich mehr über folgende Punkte zu erfahren:

  • Wie gut skaliert diese neue Technologie „Software-Container“ wirklich? Kann ich 10.000 Server starten und bringt  das tatsächlich eine (ca.) 10.000fache Leistung? Wovon hängt es in der Praxis wirklich ab?
  • Gibt es einen Punkt, wo ein „Mehr“ an Servern kein „Mehr“ an Leistung bringt?
  • Welche Herangehensweisen gibt es, um die gefürchteten „Bottlenecks“ auf dieser neuen Technologie-Plattform zu entdecken UND auch zu beheben?
  • Wie kann man sicher stellen, daß man die richtigen Parameter misst und nicht Mist misst? Also, kann man mit den Möglichkeiten des bisherigen Monitorings diese neue Technologie aussagekräftig genug überwachen?
  • Oder ist es vergebene Liebesmüh und man „skaliert einfach darüber hinweg“?

Was meint Ihr? – Welche Erfahrungen habt Ihr gemacht? – Was sind valide Ansätze und was hat sich schon als Irrweg oder nicht effizient herausgestellt?
Für Kommentare, Anregungen und spannende Diskussionen bin ich zu haben.
Nicht jedoch für „Flame-Wars“ oder „IT-Glaubenskriege“ jeglicher Art. Das werde ich einfach ignorieren.
Thorsten

Jetzt teilen auf:

Jetzt kommentieren