5 minutes reading time (1053 words)

Kann ich wirklich jede Applikation in einen Container umwandeln und vor allem wie?

transform container

In unseren ersten beiden Containerartikeln sind wir auf die Architektur und das Deployment von Containerlösungen eingegangen. Nun möchten wir das Thema Applikationstransformation angehen. Diesen Artikel haben wir zusammen mit unserer Partnerfirma – Skillbyte  – geschrieben. Skillbyte bietet Dienstleistungen in den Bereichen DevOps & Cloud, Big Data und Analytics sowie der Softwareentwicklung.

Nun aber zum eigentlichen Thema: Bei der Applikationstransformation verfolgen Unternehmen zwei extreme Richtungen… und natürlich ist wie immer in der IT ein großer Graubereich dazwischen. Manche Unternehmen geben die Vorgabe aus, sämtliche existierende Applikationen zu transformieren und neue Applikationen ausschließlich als Container zu entwickeln. Andere sind noch vorsichtiger und entscheiden von Fall zu Fall, wie mit einer vorhandenen oder neuen Applikation umgegangen werden soll. In beiden Szenarien stellt sich jedoch die Frage, ob JEDE Applikation in einem Container laufen kann?

Schauen wir uns also die naheliegenden Vorteile eines Containers an:

- Container Images beinhalten alle Bibliotheken und Artefakte, die eine Applikation zur Laufzeit benötigt. Im Gegensatz zu herkömmlichen Virtualisierungstechnologien wie Hyper-V oder VMware beherbergen Container Images jedoch kein komplettes Betriebssystem. Sie nutzen große Teile des Host Betriebssystems. Von daher sind sie leichtgewichtiger als reguläre VMs und starten um ein Vielfaches schneller. Als Folge dessen können Host Ressourcen effizienter genutzt werden, was wiederum dazu führt, dass mehr Applikationen auf einer Hardware betrieben werden können --> Einsparung Serverkapazität

- Dadurch, dass die Container alles mitbringen, was zur Laufzeit benötigt wird, können sie problemlos auf anderen Hosts laufen. In gewissem Rahmen ist sogar das Verschieben auf ein anderen Betriebssystem möglich. Dies ist ähnlich dem Java Paradigma: "Write Once, Run Everywhere" --> Erhöhung der Portabilität

- Container laufen isoliert und können somit parallel mit mehreren anderen Applikationen auf einem Host laufen --> Reduzierung von Kompatibilitätsproblemen wegen Libraries

- Container können leichter automatisiert deployed und skaliert werden --> Reduzierung von Bereitstellungszeiten

- Container sind "immutable". Die Idee ist, dass Änderungen wie Patches, das Hinzufügen von neuen Libraries usw. immer zu einem neuen Image führt. Das reduziert das Risiko von divergierenden Servern erheblich. Die Wartung von großen Serverfarmen wird aus Sicht des Administrators erheblich vereinfacht --> Reduzierung der Administrationskomplexität

Wirklich interessant wird es allerdings bei Applikationen, die enormen Ressourcenschwankungen unterliegen. Klassisches Beispiel ist hier der WebShop, der z.B. durch eine Werbekampagne oder ein spezielles Ereignis höher frequentiert ist. Hier kann die Containertechnologie helfen, die Applikation einfach, automatisiert und binnen Sekunden zu skalieren. Das klingt simpel und ist es in der Regel auch – wenn einige Voraussetzungen geschaffen worden sind. So muss die Architektur der Applikation grundsätzlich auf Skalierbarkeit ausgelegt sein.

Containertechnologie ist ein neues Paradigma welches nicht nur für den Betrieb gilt, sondern auch für die Software Entwicklung (Stichwörter: DevOps, GitOps, 12-factor-app, etc.). Die Migration zu einer agilen, automatisierten, modernen Infrastruktur braucht Experten. Die Landschaft der Tools und Herangehensweisen ist groß und geprägt von ständigem Wechsel. Auf der anderen Seite stehen jedoch großartige, positive Veränderungen in der Geschwindigkeit von Software Releases, erhöhter Security, Kosteneinsparungen, schnelleres Adaptieren an Marktgegebenheiten usw. Der Lehrsatz : Nicht die Großen fressen die Kleinen, sondern die Schnellen die Langsamen hatte noch nie so viel Bedeutung wie jetzt.

Um den Unternehmen den Umstieg auf Containertechnologie zu erleichtern, haben Firmen Automatismen erdacht, um bestehende Applikationen in Docker Container zu überführen, Z.B. Docker MTA, Image2Docker, etc. Die Marketingaussage ist "Ohne Code neu zu schreiben" oder Applikationen ändern zu müssen. Wir halten diesen Ansatz für eine reine Marketingaktion, denn technisch kann das nicht funktionieren. Ein Monolith ist und bleibt ein Monolith, auch wenn dieser in einem Container läuft. Die Test- und Release-Zyklen bleiben gleich, denn die Komplexität steckt in dem Monolithen. Bei den meisten "Portierungsprojekten" geht es ja eher darum, dass Große in kleine Teile zu zerlegen, um eben diese Komplexität zu senken. Damit werden kleinere und agilere Teams geschaffen, die nur verantwortlich sind für bestimmte Teile der Applikation.

Stellen Sie sich vor, Sie möchten per A/B testing zwei Versionen eines Call-To-Action Buttons testen, um zu sehen welche der Versionen zu mehr Conversions führt. Bei einem Monolithen ist das Build und Deployment so komplex, fehlerträchtig und langsam, dass man von solchen Tests absieht, weil sie einfach zu teuer sind. Hat man aber die Software in sinnvolle Teile zerlegt, kann der Frontend Code unabhängig von dem Rest der Software gebaut und deployed werden.

Des Weiteren ist der Container die kleinste technische Einheit einer eher generellen Umstellung, einer neuen Kultur der Vorgehensweise. Etwas mit "magic" zu automatisieren, ohne zu verstehen, was da genau passiert, ist nicht anzuraten. Zusammenhänge müssen verstanden und Entscheidungen bewusst getroffen werden.

Wir von TEAL Consulting und skillbyte helfen Ihnen, diese komplexen Landschaften zu verstehen, die richtigen Ansätze für Ihre speziellen Use Cases zu finden und die richtigen Entscheidungen zu treffen. Wenn Sie mögen, unterstützen wir auch bei der Durchführung der Migration, beratend, aber auch Hands-On.

Zusammenfassend stellen wir fest, dass es enorme Vorteile bringt, eine große Anzahl von Anwendungen zu containerisieren. Grundsätzlich kann jede Applikation transformiert werden. Auch wenn der Code keine dynamische Skalierung hergibt, so können doch Ressourcen auf dem Host eingespart werden.

Bevor Unternehmen große Migrationsprojekte starten, um eine Vielzahl von existierenden Applikationen zu transformieren, lohnt es sich, diese genauer zu analysieren. Es empfiehlt sich mit Web und weniger komplexen Applikationen zu beginnen. Dies stellt zum einen sicher, dass schnell erste Erfolge realisiert werden und zum anderen, dass vor allem auch Erfahrungen gesammelt werden können.

Doch wie geht man nun konkret vor, um bestehende Anwendungen zu transformieren? Gemeinsam mit Skillbyte haben wir ein Vorgehen entwickelt bei dem abhängig vom Kunden-Know-How zunächst Wissen aufgebaut und dann eine existierende Applikation transformiert wird. 

Nach ca. einem Monat* haben wir mit euch eine Beispiel Applikation aus eurem Umfeld in eine moderne Cloud Native Version überführt, welches Ihr On-premises oder in der Cloud betreiben könnt.

Wenn wir Euch bei der Applikationstransformation unterstützen können bzw. Ihr weitere Informationen benötigt, meldet euch gerne unter Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!

*Die Phasen können stark variieren je nach Größe der Applikation. Ziel ist es, Ihre Mitarbeiter in die Thematik einzuführen und die Vorteile der neuen Technologie näher zu bringen. 

Naked TEAL - Für Euch! – Mit Euch! – Seid dabei!
ESAE Serie Teil 4 – Schutzmaßnahmen für die Umgebu...

Related Posts

 

Comments

No comments made yet. Be the first to submit a comment
Guest
Samstag, 25. Mai 2019