Artgerechte Haltung von microservices-based Applikationen in Containers oder Docker

Eine Enterprise Applikation muss nach der Erstellung durch die Entwicklung auch in den Betrieb gebracht werden. Eine Möglichkeit ist der Betrieb der Software innerhalb von Containern oder Dockers, was auch Container sind.

Container oder Dockers für den Betrieb einer Applikation

Containerization ist das Verpacken einer Applikation oder Service inkl. Abhängigkeiten und Konfiguration in ein „Paket“. Warum? Nun, es gibt mehre Vorteile, die sich dadurch ergeben. Ein wesentlicher und wichtiger Punkt: Testing, also Testen in einer Einheit. Wer schon mal versucht hat eine komplexe (Enterprise) Applikation zu testen weiß wie schwierig so etwas werden kann. Gerade wenn Funktionen einmal quer durch die Applikation jagen. Es gibt oft viele Abhängigkeiten, die es schwer machen eine stabile Software auszuliefern. Genau aus diesem Grunde sollte man bei der Architektur der Software an das Testen denken. Nur mal ein Stichwort: Test Driven Design.

Zurück zu den Containern: Mit Containern erhält man eine isolierte Applikation, die währende der Entwicklung, dem Test, dem Rollout und dem Betrieb bedeutend einfacher zu handhaben ist. Mit dem Ansatz von Containern ist auch die Idee von Continous Integration greifbarer.

Skalierbarkeit / Scalability

Ein weiterer wesentlicher Vorteil der Container ist die Skalierbarkeit. In kürzester Zeit kann ein solcher Container erneut instanzsiert werden und die Funktionalität redundant verfügbar gemacht werden. Dies gilt es beim Design der Architektur und Datenzugriffe bzw. Datenhosting zu berücksichtigen. In vielen Applikation ist es schlecht unmöglich einzelne Services doppelt zur Verfügung zu stellen.

Abgrenzung / Isolation

Dadurch, dass jeder Container für sich alleine läuft, reduziert sich auch ein Komplettabsturz der gesamten Applikation. Sollte ein Microservices crashen, so bleibt der Rest der Architektur stabil. Im besten Fall wird nur dieser Microservice (automatisch) neu gestartet und die Beeinträchtigung ist minimal.

Übertragbarkeit / Portability

Arbeitet man mit Containern können die schnell in einen anderen Containter-Host übertragen werden. Die Idee ist wie mit den virtuellen Maschinen. In beiden Technologien können die Einheiten auf einen beispielsweise leistungsstärkeren Host übertragen werden und dort ohne großen Mehraufwand betrieben werden.

Flexibilität / Agility

Die Flexibilität der Container ermöglicht Auslastungs-Peek einzelner Prozesse, zum Beispiel zu einer bestimmten Uhrzeit oder Tag durch das zeitweise Starten weiterer Container zu regulieren. Ein Beispiel: Um 7-9 Uhr morgens und 16-18 Uhr Abends ist der Zeiterfassung-Prozess eines Konzerns mit 1000 Mitarbeiter stark belastet. Läuft der Zeiterfassungs-Prozess als Mircroservices, so kann in der Zeit weitere Prozesse dazu geschalten werden, um allen Mitarbeitern eine angemessene Response-Zeit zu ermöglichen.

Kontrolle / Control

Mit Hilfe der in sich geschlossenen Einheiten ist die Kontrolle von Zugriffen einfacher zu steuern. Da jeder Mircoservice für sich alleine steht, muss die Authentifizierung bei jedem Service erfolgen oder zumindest der Zugriffs-Token geprüft werden. Schlupflöcher im Berechtigungskonzept werden damit kleiner.

Was ist Dockers?

Dockers ist ein open-source-Projekt der gleichnamigen Firma. Docker image container können auf Linux und Windows laufen. Reine Windows Images können beispielsweise nur auf Windows laufen – meist als Virtual Machine. Windows Containers können im Windows Server Containers oder in Hyper-V Container laufen.

In Docker gibt es ein paar besondere Terminologien, die hier mal ohne weitere Ausführungen aufgeführt werden:

  • Container image
  • Container
  • Tag
  • Dockerfile
  • Build
  • Repository (repo)
  • Registry
  • Docker Hub
  • Azure Container Registry
  • Docker Trusted Registry (DTR)
  • Docker Community Edition (CE)
  • Docker Enterprise Edition (EE)
  • Compose
  • Cluster
  • Orchestor

.net Core vs. net Framework für Docker Containers

Grundsätzlich: Beide Frameworks werden unterstützt. Sollte man plattformübergreifend programmieren wollen, so fällt im großen und ganzen auf .net CORE. Wenn die Applikation starke Abhängigkeiten zu Windows hat oder Windows APIs nutzt, dann ist .net Framework das Mittel der Wahl. Diese zwei Sätze machen die Entscheidung nicht einfacher. Der Einzelfall ist hier entscheidend und muss in jedem Entwicklungs-Projekt neu entschieden werden. Weitere Gedankengänge zur Wahl des Frameworks gibt es hier …

vor 4 Jahren