Agile Infrastruktur und Continuous Delivery in CoreMedia – Teil2

Der normale Start eines solchen Projektes bestand meist darin diese Fragen zu beantworten:

  • Welche Dienste brauchen wir?
  • Wieviele Redakteure werden das System nutzen?
  • Wieviele User erwarten wir auf den CAEs?
  • Brauchen wir Ausfallsicherheit und wenn ja in welchem Ausmaß?
  • Wieviele Artikel, Bilder und sonstige Assets soll das System aufbnehmen können?
  • etc.

All diese Metriken dienen dazu die entsprechende Hardware zu planen und zu bestellen. Dann vergehen meist mehrere Tage, wenn nicht Wochen bis die Hardware eintrifft oder im Rechenzentrum bereitgestellt werden kann. Dann machen sich die Admins, meist mit der Hilfe von Kollegen aus der Entwicklung, daran einen CoreMedia Strang (Dev) aufzuzetzen, damit die Entwickler loslegen können. Meist braucht man aber natürlich mehrere Stränge: Dev, Stage, Prod, vielleicht noch eine Schulungs oder Referenzumgebung. Wow, jede Menge Zeug. Neben den reinen CoreMedia Diensten kommen dazu: Loadbalancer, Datenbanken, Apache Configs, Firewall Regeln, Domain Routings, Port Mappings JMX, Dienste, Corba, usw. Jeder der aus dem CoreMedia Umfeld kommt, kennt das alles bereits und wir wollen hier nicht weiter in der Wunde bohren.

Anmerkung: CoreMedia ist aus unserer Sicht das beste Enterprise Content Management System und inzwischen recht komplex, da es jede Menge Funktionalität bietet. Das was wir oben beschrieben haben liegt also in der Natur der Sache und hat nichts mit falscher Infrastruktur zu tun. Im Gegenteil, wir werden später aufzeigen, warum CoreMedia sehr gut geeignet ist für die DevOps Welt.

So, jetzt ist alles installiert und die Entwickler legen los. Sprint zu Ende. Gut. Wie kriegen wir jetzt das Release in die anderen Umgebungen. Die meisten haben ein CI Tool wie Jenkins, der verschiedene CoreMedia Dienste bauen und per bash Skripte und SSH auf die Server deployen kann. Das ist schon der „Gut“ Fall, da das meiste automatisiert ist.  Da das Szenario meist auf reiner Hardware oder maximal Hypervisor Systemen (VMWare) beruht, bringt es einige Probleme mit sich. Betriebssystem Patches stehen an, Oh, Jenkins hat zuwenig RAM und CPU, Wir brauchen eine neue CAE wegen zuviel Load, die RAM Module auf der RLS haben einen defekt und müssen ausgetauscht werden, Redhats neuester Treiber hat Fehler XYZ verursacht usw, usw.

Wir haben aber auch Szenarien wo irgendwelche ZIP oder RPM Artefakte auf Fileservern abgelegt werden, irgend einer sich die schappt und einspielt. Jeder hilft sich so gut er kann und die IT Policy es zulässt. All diese Szenarien haben nicht wirklich mit Agilität zu tun, das Schlimme: dadurch dass dieser Prozess mit „Schmerz“ assoziert wird (meist sind es die Admins :-)) sind die Deployment Zyklen eher langfristig ausgelegt.

Den Weg den wir in den folgenden Artikeln beschreiben ist ein alternativer Weg und beruht auf den neusten Errungenschaften in der Infrastruktur Welt. Das Zauberwort ist „Container Virtualisierung“. Diese Technologie beschert uns eine Menge weiterer Werkzeuge mit denen man all die genannten Problem lösen kann. Im nächsten Artikel fangen wir mit dem ersten Tool an: Terraform.

Teilen:

Relevante Artikel

Advanced AI applications for the insurance domain

Advanced AI applications for the insurance domain

Has an automobile accident ever happened to you? You are probably aware of the difficulties associated with filing an auto insurance claim if you have

Framework für die Einführung von Generative AI

Framework für die Einführung von Generative AI

Der Leitfaden zur Einführung von Generative AI in Ihrem Unternehmen: Ein systematisches Framework In der Ära der digitalen Transformation ist Generative AI nicht mehr nur

Wie können Large Language Modelle wie GPT-4 Geschäftsprozesse optimieren?

Wie können Large Language Modelle wie GPT-4 Geschäftsprozesse optimieren?

Wussten Sie, dass KI-Modelle wie GPT-4, Gemini, LLama2, Mistral & Co. dabei helfen können, die Leistungsfähigkeit Ihres Unternehmens zu steigern? Diese großen Sprachmodelle sind revolutionäre