Die Zukunft des Einsatzes: Teil 1 - Denkmäler vs. billige Wohnungen

Ich werde eine Serie über die Zukunft der Bereitstellung starten. Wie und was werden wir in, sagen wir, 5 Jahren oder so bereitstellen. Dies ist natürlich nur meine Meinung und bitte schreiben Sie Ihre eigenen Ideen in die Kommentare unten.

Zu Beginn dieser Serie werde ich über den aktuellen Stand der Dinge sprechen, oder zumindest über das, was ich bei vielen Unternehmenskunden sehe. Die meisten Unternehmen, bei denen ich war, haben physische Server, die von zahlreichen Anwendungen verschiedener Entwicklungsteams genutzt werden. Einige dieser Server sind alt und werden seit Jahren (+4 Jahre ;)) vom Betrieb gewartet. Das bedeutet, dass sich der Server verändert hat, dass viele Deltas, d.h. Patches, Deployments usw. angewendet wurden, und wie mein Kollege Vincent sagte, hat die Anwendung von Deltas ihre Nachteile ;) Natürlich spreche ich von Servern und nicht von Anwendungen und die gleichen Regeln gelten nicht, oder doch?

Deltas auf Servern sind schlecht, Punkt. Ich denke, es gelten dieselben Regeln. Die Anwendung von Deltas mag zwar schneller sein, aber am Ende wird es immer schwieriger, den Weg nachzuvollziehen, den Sie von vor 4 Jahren bis heute zurückgelegt haben! und das ist auf den Servern selbst augenscheinlich. Versuchen Sie, einen 4 Jahre alten Server wiederherzustellen, auf dem jede Woche mindestens 5 Bereitstellungen durchgeführt wurden, jeden Monat ein oder zwei Patches auf die OS-Middleware aufgespielt wurden und alle sechs Monate eine Änderung am Dateisystem vorgenommen wurde. Es ist einfach nur schwierig. Und hier ist das Paradebeispiel Vor einigen Jahren wurde ich Zeuge eines Projekts, bei dem versucht wurde, die gesamte Server- und Anwendungsumgebung von einem Standort zu einem anderen zu verlagern und in der Zwischenzeit einige veraltete Standards loszuwerden, die sich auf diesen Servern befanden. Sie verfügten über automatisierte Deployment-Skripte für alle ihre Anwendungen. Das Einzige, was sie also tun mussten, war sicherzustellen, dass sie am neuen Serverstandort eine saubere Umgebung hatten, in der sie die neueste und beste Version ihrer Anwendungen installieren konnten. Sie versuchten 6 Monate lang, es zum Laufen zu bringen, scheiterten aber daran, dass sie die Server am entfernten Standort nicht richtig reproduzieren konnten, da die Anwendungen auf diesen Servern so viel veraltetes Material benötigten! Schließlich gaben sie auf und zogen alle ihre Server um, indem sie ein Server-Backup am entfernten Standort wiederherstellten. Die Lektion, die dieses Unternehmen gelernt hat, war, die Menge der Anwendungen auf verschiedene Server zu verteilen. Dadurch konnten sie ihre Server und Anwendungen aktueller halten und veraltete Standards sichtbarer loswerden. Das Neue einzuführen ist einfach, das Alte loszuwerden, einfach sein lassen... Das Unternehmen hat neue Server erstellt, die von neuen Anwendungen verwendet werden sollten. Daher konnten sie diese fast beliebig installieren. Diese neuen Anwendungen konnten dann die neuen Funktionen dieser Server nutzen und fast alles war gut. Wenn eine alte Anwendung einige der neuen Funktionen nutzen wollte, die nur auf den neuen Servern verfügbar waren, musste sie ihre Bereitstellung und manchmal auch ihren Code anpassen. Es wurde akzeptiert, dass man bei der Nutzung neuer Funktionen auf einen neuen Server mit aktualisiertem JDK, Pfaden für Protokolldateien, mehr Arbeitsspeicher, einer neuen Version des Anwendungsservers oder eines Portals und so weiter umzieht. Für Anwendungen gab es einen natürlichen Upgrade-Pfad. Alte Anwendungen laufen auf alten Servern, aber diese Server benötigen außer dem einen oder anderen Patch und sauberen Protokolldateien nicht viel Wartung. Neue Anwendungen werden auf neuen Servern mit besserer Middleware, Tools usw. ausgeführt, was die Wartung auf einer anderen Ebene etwas einfacher macht. Unterschiedlicher Wartungsaufwand - Denkmäler vs. billige Unterkünfte Wie können mehr Server zu einem geringeren Wartungsaufwand führen, ist das nicht einfach nur seltsam? Doch, das ist es! Aber der Unterschied ist folgender: Wenn ich einen Server für alle meine Anwendungen habe, wird es schwierig, Änderungen am Server und an diesen Anwendungen vorzunehmen. Das ist so, als würden 40 Personen (Anwendungen) in einem riesigen Gebäude (Server) leben. Bei jeder Änderung müssen Sie herausfinden, welche Auswirkungen sie auf das Gebäude selbst und die darin lebenden Menschen hat. Ich habe die Erfahrung gemacht, dass ich jedes Mal, wenn ich eine Änderung am Server vornehmen wollte, ein Komitee durchlaufen musste, um eine Genehmigung zu erhalten! Das Komitee bestand nicht nur aus Hardware/OS/Middleware-Mitarbeitern, sondern auch aus allen Anwendungsspezialisten! Alle 40 von ihnen ;( Sie können meine Frustration nachempfinden, denn ich habe innerhalb eines Jahres bereits die dritte Änderung für diesen Server beantragt. Als wir auf kleinere Server (billiges Gehäuse) mit weniger Anwendungen (kleine Familien) umzogen, wurde es viel einfacher, Änderungen vorzunehmen ;) Ok, ok, also der Wartungsaufwand war nicht das Problem, sondern die Zustimmung von 50 Leuten zu einer Änderung zu bekommen und dann herauszufinden, ob es im Denkmal funktioniert, war das Problem. Dagegen war es ein Kinderspiel, etwas zu ändern und/oder ein brandneues, billiges Haus zu bauen! Und wie sieht es mit der Zukunft aus? In meinem nächsten Beitrag werde ich erkunden, was meiner Meinung nach das nächste große Ding nach dem "Monument" und dem "billigen Wohnraum" ist. Natürlich hat es etwas mit Cloud-/Virtualisierungstechnologien zu tun. Es wird sich alles um das Verschieben von Appliances drehen! und das ist etwas, wofür Deployit Unterstützung bieten wird.