Aufgabenbereich

Praxisbericht.tex

@@ -24,8 +24,8 @@
 \usepackage{listings} % code blocks
 \usepackage{xcolor}
 
-\usepackage[backend=biber, style=numeric, url=true]{biblatex} %URL in biblatex
+%\usepackage[backend=biber, style=numeric, url=true]{biblatex} %URL in biblatex
-\addbibresource{literatur.bib}
+%\addbibresource{literatur.bib}
 %\bibliography{literatur} %bibtex
 
 \graphicspath{{graphics/}}
@@ -154,16 +154,28 @@ Das Software-Engineering Department befindet sich im ersten Stock auf der Südse
 
 \section{Aufgabenbereich}
 
-Mein Arbeitsplatz befindet sich in der Abteilung PA INF GUI, kurz für Projektabwicklung Software-Engineering Nutzeroberfläche. Während der Name auf alleiniges Ausarbeiten von grafischen Nutzeroberflächen (Graphical User Interface, kurz GUI) vermuten lässt, ist diese Abteilung auch für die Integration der verschiedenen Backends selektron WMS, selektron MFCS, selektron RPS zuständig. Dies wird über das Kernmodul selektron core, bestehend aus den Komponenten . Mein Aufgabenbereich, das Evaluieren von Kubernetes als Containerorchestrierung für den Software-Stack der psb, ist keine klassische Aufgabe der Nutzererfahrung oder Nutzeroberfläche, 
+Mein Arbeitsplatz befindet sich im Herz der PA INF GUI. Während der Name auf alleiniges Ausarbeiten von grafischen Nutzeroberflächen (Graphical User Interface, kurz GUI) vermuten lässt, ist diese Abteilung auch für die Integration der verschiedenen Backends selektron WMS, selektron MFCS, selektron RPS zuständig. Dies wird mithilfe des in der Abteilung entwickelten Kernmodul der selektron-Suite, selektron core, bewältigt. selektron core besteht dabei aus den Komponenten Administration, API Gateway, Authentification, Authorisation und Discovery. Jedes der Backends besteht ebenfalls aus mehreren Komponenten. Diese werden jeweils für Kundensysteme vom Basis-Entwicklungsstand einzeln angepasst und zugeschnitten, damit es perfekt auf deren Anforderungen ausgelegt ist. Oft haben Kunden jedoch gleiche oder ähnliche Bedürfnisse, welche im aktuellen System bei jedem Kunden extra und damit mehrfach Implementiert werden. Diese Implementationen betreiben oft die gleiche Aufgabe, sind jedoch anders Entwickelt. Durch diese resultierenden Redundanzen steigt der Wartungsaufwand. Ebenfalls steigt der Aufwand, die zugeschnittenen Systeme bei dem Kunden zu konfigurieren und einzusetzen, da jeder Kunde eine einzigartige IT-Infrastruktur hat, wodurch das Deployment händisch mit einer Ansammlung von über die Jahre entwickelten und gewachsenen Skripten und viel Filigranarbeit durchzuführen ist. Dieses Händische Deployment senkt die Wartbarkeit, da über die Jahre immer wieder Updates, Migrationen und sonstige kurzfristige Änderungen auftreten, welche nur zum Teil dokumentiert, und damit schwer Nachvollziehbar sowie absolut nicht Auditierbar sind. Ebenfalls ist die Einarbeitung von Servicemitarbeitern aufwändig, da alles über das Terminal mit Skripten und Befehlen verwaltet werden muss, und nicht alle Fälle von diesen existierenden Skripten übernommen werden können. Diese Servicefälle müssen dann im Schlimmsten Fall bis zum nächsten Arbeitstag warten, was für den Kunden verlorene Zeit und damit verlorenes Geld bedeutet. Ebenfalls existiert im aktuellen System keine automatische Ausfallsicherheit, welche den Service bei trivialen Fällen entlasten könnte.
+
+Jedes der zuvor genannten Module wurde innerhalb der letzten Jahre in Container-Images gebündelt und mit Containerverwaltungstools wie Docker oder Podman, als auch  durchgeführt, um das Deployment weitestgehend zu vereinfachen und Kunden-infrastruktur-unabhängiger zu gestalten. Trotzdessen bleiben ziemlich alle gennanten Probleme bestehen, da sie über die Containerisierung hinaus gehen.
+
+Mein Aufgabenbereich, das Evaluieren von Kubernetes als Containerorchestrierung für den Software-Stack der psb, ist keine klassische Aufgabe im Bezug auf die Nutzeroberfläche, ist in der Firmenstruktur trotzdem dieser Abteilung untergliedert. Kubernetes führt im Kern, ähnlich wie Docker und Podman, Container aus, geht jedoch weit über das Ausführen sowie Verwalten von diesen hinaus und wird daher aus als Orchestration bezeichnet. Lastverteilung, Selbstheilung, Ausfallsicherheit, Koordination, Skalierungsmöglichkeiten beschreiben die Möglichkeiten, die Kubernetes im Kern bietet. Kubernetes ist jedoch leicht erweiterbar, wodurch auch Versionierung und Rollbacking über Helm, automatisches Deployment durch FluxCD und HTTP Routing über GatewayAPI abgedeckt sind. \textbf{TODO: POTENTIELLE SECRET-INJECTION MIT ESO} Da die Firma aktuell noch keine Forschung über Kubernetes außer dem Fakt, dass es existiert und die aktuelle Problemlage Lösen könnte, betrieben hat sollte dies meine Aufgabe werden. Das Ziel ist es, einen möglichst automatisch deploybares "Walking Skeleton" aus dem aktuellen Basisprojekt zu gestalten, und dabei die verschiedenen Funktionieren und Erweiterungen die Kubernetes liefert, zu analysieren und zu überprüfen, ob diese konkret für das Projekt Sinn machen. Darüber hinaus soll geprüft werden, inwieweit Kubernetes eine Integration von Windows-basierten Systemen ermöglicht und welche technischen Einschränkungen dabei bestehen.
+
+Die gewonnenen Erkenntnisse dienen als Entscheidungsgrundlage für eine mögliche Migraton der bestehenden Systemarchitektur hin zu einer Kubernetes-basierten Lösung.
 
 
 \section{Methodik}
 
+
+
 \section{Erkenntnisse}
 
+
+
 \section{Evaluation}
 
+
 \section{Fazit}
 
 
+
 \end{document}