Im vergangenen Dezember habe ich in meinem ersten Teil über die Zukunft der Bereitstellung den Unterschied zwischen großen alten Servern mit einer Unmenge von Anwendungen und vielen neuen glänzenden kleinen Servern mit jeweils einer eigenen Anwendung erläutert. Diesmal werde ich mich mit der Cloud oder Ihren virtualisierten Servern befassen und Ihnen meine Vision davon vorstellen, wie wir in etwa 3-5 Jahren Anwendungen verpacken und bereitstellen werden.
Wie wir früher eine Anwendung bereitgestellt haben
Nun, das kennen Sie alle auswendig: Sie richten Ihre Umgebung ein, installieren z.B. einen Anwendungsserver, richten Ihre Datenbank ein, wählen ein SQL-Skript aus, das gegen die Datenbank läuft, konfigurieren Ressourcen und stellen die Anwendung auf dem Anwendungsserver bereit. Nachdem alles eingerichtet ist, starten Sie den ganzen Haufen und sonnen sich im Ruhm!
Gilt das obige Einsatzszenario auch für virtualisierte/wolkige Umgebungen? Ja, das tut es, natürlich! Die Einrichtung der Umgebung wird stark vereinfacht, wenn Sie AMIs oder virtuelle Images (auch Appliances genannt) verwenden. Sie erhalten Ihren Datenbank- oder Anwendungsserver sofort, aber die Konfiguration und Installation der Anwendung und der Konfiguration/Ressourcen ist immer noch die gleiche langweilige und mühsame Aufgabe.
Das Ganze auf die Spitze treiben
Wenn Sie sich viele der aktuellen Images ansehen, handelt es sich im Grunde nur um ein Betriebssystem, das Sie instanziieren können. Einige Anbieter, wie Oracle, haben Images, die auch eine installierte Datenbank auf einem Betriebssystem enthalten, wie z.B. eine beliebte Variante von Linux. Aber stellen Sie sich vor, dass Sie Ihre eigene Anwendung mit einem Image bündeln können, das dann zu Ihrer eigenen virtuellen Appliance wird. Sie verwenden Ihre eigene virtuelle Appliance (Betriebssystem + installierte Anwendung + Konfigurationsdateien), um Ihre Umgebung schnell einzurichten und voila! keine langweilige Installation eines Anwendungsservers/einer Datenbank mehr, keine Bereitstellung von Anwendungen pro Umgebung.Klingt zu schön, um wahr zu sein, was?! In der heutigen Zeit ist es das leider auch.
Das "größte" Problem
ist die Größe des virtuellen Images.
Nehmen wir an, Sie haben eine neue Version Ihrer Anwendung erstellt. Insgesamt sind War + Konfigurationsdateien + einige DDL-Skripte etwa 100 MB groß, das ist in der Tat keine große Sache! Sie können sie leicht in verschiedene Umgebungen kopieren. Versuchen Sie nun, ein virtuelles Abbild dieser Version zu erstellen.Schritt 1, holen Sie sich das Abbild (= 2GB groß, Betriebssystem + installierter Anwendungsserver + installierte DB)Schritt 2, installieren Sie Ihre Anwendung auf dem virtuellen Abbild (+= 100MB)Schritt 3, bereiten Sie das Abbild vor und packen Sie es zusammen.Gesamtgröße Ihres Pakets oder, wenn Sie möchten, Bundles (Betriebssystem + Anwendungsserver + DB + Anwendung = 2100MB). Versuchen Sie, Ihre VMWare 2,1 GB über das Internet in Amazon EC2 zu konvertieren und zu kopieren! Es wird eine Weile dauern und das sind eine Menge Tassen Kaffee, bevor Sie es zum Laufen bringen können. Die schlaueren unter Ihnen verwenden einfach die AMIs, die bereits auf Amazon vorhanden sind, und bündeln sie neu, wodurch das Problem gelöst wird :).
Zu einfach für Sie?
Wer legt also seine Datenbank auf denselben virtuellen Server? Niemand, oder zumindest niemand ernsthaft ;) Nun, für diese Leute können Sie ein zweites virtuelles Image mit der Datenbank erstellen und dieses mit Ihrem Anwendungsimage verpacken. Jetzt haben Sie 2 Images, die zusammen verwendet werden können, aber wieder müssen Sie mehr hochladen und vielleicht mehr Speicherplatz verschwenden.
Und was ist mit Ressourcen, zu denen Sie eine Verbindung herstellen müssen und die Sie nicht mit Ihren Images zusammenpacken können, wie z.B. ein LDAP des Unternehmens oder noch schlimmer ein Mainframe-System, auf das Sie über MQSeries und einen Message Broker zugreifen müssen? Nun, hier wird deutlich, dass nach der Erstellung von Images und deren Instanziierung in der Umgebung manchmal noch Aktivitäten erforderlich sind, wie z.B. die Konfiguration von JMS-Ressourcen für die Verbindung mit einem entfernten Queue Manager, damit Ihre Anwendung voll funktionsfähig ist. In vielen Fällen benötigen wir also immer noch eine automatisierte Bereitstellung, um alles in Gang zu bringen. Und wenn wir schon dabei sind, können Sie einen Blick auf unsere Deployit 1.3-Beta werfen, die bereits einige dieser Paketierungskonzepte enthält, wie z.B. Deployment-Pakete mit, Queues, Datenquellen usw..
Dennoch ist es ein schönes Bild, das man zeichnen kann... aka das Image ist das neue EAR
Paketieren Sie Ihre Anwendung mit einem Betriebssystem und liefern Sie es als Ihre Version aus. Sie können mit diesem Image fast alles machen, was Sie wollen, was für IHRE Anwendung am besten ist. Passen Sie nicht nur den Anwendungsserver, sondern sogar das Betriebssystem an! Verwenden Sie die Bibliotheken, die Sie wollen. Der Himmel ist die Grenze!;) oder zumindest das, was Sysadmins tolerieren.
Das ist IMHO das größte Plus! Sie können etwas liefern, das sehr, sehr nah an der Produktionsumgebung ist. Dadurch werden Laufzeit- und Konfigurationsprobleme, mit denen Sie möglicherweise konfrontiert werden, wenn Ihre Anwendung in der Produktion läuft, beseitigt oder stark reduziert.In Teil drei werde ich einen Blick darauf werfen, wo die Virtualisierungs-/Cloud-Anbieter wie IBM, Oracle, VMWare (+ Spring, anyone?) jetzt stehen. Wie Sie schon morgen (und nicht erst in 3-5 Jahren ;) ) damit beginnen können, virtuelle Images/Appliances bereitzustellen, anstatt nur einen Krieg zu führen.
