• Zur besseren Einteilung von Kunden bei Besuch des Webshops (Salesforce Commerce Cloud) werden Segmente genutzt. Der Webshop benötigt für jeden Besuch die Segmente, in denen sich ein Kunde befindet, aber kann diese auf Grund von Limitationen nicht lokal bereithalten. Eine direkte Anfrage an die Salesforce Data Cloud war aus Kostengründen nicht möglich.
• Der Mitarbeiter schlug eine Middleware vor, die die Daten aus der Data Cloud regelmäßig abfragt, zwischenspeichert und dem Webshop zur Verfügung stellt.
• In einer ersten Iteration entwickelte er eine FastAPI Applikation, welche die Daten als Function App abfragt und in einem Table Storage speichert. Zusätzlich läuft die Applikation als Container und bietet ein Rest Interface für den Webshop an.
• In einer weiteren Iteration wurde der Azure Table Storage optimiert, sodass der Webshop den Table Storage ohne einen zusätzlichen Container direkt abfragen kann.
• Aktuell leistet der Mitarbeiter Support für den Betrieb.
  

Aufgaben:

• Entwurf der Systemarchitektur
• Auswahl der benötigten Technologien
• Entwicklung einer FastAPI Applikation als Function App und Container
• Optimierung der Datenstruktur
• Anpassungen der Softwareplattform
• Technischer Ansprechpartner

• Im Rahmen einer Spendenaktion eines großen deutschen Lebensmitteleinzelhändlers musste die bestehende Spendenplattform in einer StackIT Cloud Umgebung zur Verfügung gestellt werden. Im Rahmen der Aktion wurden bei jedem Einkauf Votingcodes ausgegeben, mit denen Kunden für ihre Projekte abstimmen konnten.
• Der Mitarbeiter setzte die bestehende Spendenplattform in einer StackIT Umgebung lauffähig auf. Hierbei war der  wichtigste Aspekt die Hochverfügbarkeit der Plattform. Da die StackIT Cloud Plattform parallel im Aufbau war, wurden in Abstimmung mit StackIT die benötigten Services in einem Kubernetes Cluster aufgebaut. Zu diesem
  Zweck wurden Compute Instanzen, S3 Compatible-Storage, Redis und Postgres genutzt. Alle Services wurden skalierbar angelegt, damit die Plattform auch nach größeren Social Media Aktionen aktiv gehalten werden konnte.
• Um die Spendenplattform mit den StackIT Diensten kompatibel zu machen, konnte der Mitarbeiter auf der Arbeit eines vorherigen Projekts zurückgreifen.

Aufgaben:

• Entwurf einer Systemarchitektur in StackIT
• Implementierung der Architektur
• Aufbau eines hochverfügbaren Kubernetes Clusters
• Technischer Ansprechpartner
  

• Ziel des Projekts war eine leistungsstarke und skalierbare Backend-Infrastruktur für ein neu zusammengestelltes App-Entwicklungsteam zu entwerfen und aufzubauen. Die Infrastruktur stellte dabei die Grundlage, Container in Azure skalierbar zur Verfügung zu stellen. Der Fokus des Projekts lag auf der Sicherheit der Daten und kurze Antwortzeiten. Die Entwicklung fand im engen Austausch mit den Entwicklern und der IT Security statt.
• Der Mitarbeiter nutzte für das Projekt Azure Container Apps in einer isolierten Umgebung. Die Backend Container sollten sowohl von mobilen Applikationen als auch von IoT Modulen aus Fahrrädern der Kunden erreichbar sein. Die Umgebung wurde über Terraform implementiert.
• Für das Projekt wurde zusätzlich ein CI/CD Template für die Container entwickelt und in Azure DevOps implementiert.
• Aktuell leistet der Mitarbeiter Support für den Betrieb.

• Im Rahmen einer Spendenaktion eines großen deutschen Discounters musste die bestehende Spendenplattform kurzfristig in einer AWS Umgebung zur Verfügung gestellt werden. Im Rahmen der Aktion wurden bei jedem Einkauf Votingcodes ausgegeben, mit denen Kunden für ihre Projekte abstimmen konnten. Insgesamt nahmen über 3.000 Filialen und über 7.000 Organisationen an der Aktion teil. Es wurden im sechswöchigen Abstimmungszeitraum etwa 5 Millionen Votingcodes eingelöst.
• Der Mitarbeiter setzte die bestehende Spendenplattform in einer AWS Umgebung lauffähig auf. Hierbei war der wichtigste Aspekt die Hochverfügbarkeit der Plattform. Zu diesem Zweck werden EC2 Instanzen, S3 Storage, ElastiCache und RDS for PostgreSQL genutzt. Es wurden sowohl die EC2 Instanzen als auch die Datenbank skalierbar angelegt, damit die Plattform auch nach größeren Social Media Aktionen aktiv gehalten werden konnte.
• Um die Spendenplattform mit den AWS Diensten kompatibel zu machen, passte er auch die Spendenplattform selbst an.

• Im Rahmen der Tätigkeit wurde eine bestehende Spendenplattform, geschrieben in Django, erweitert. Zu den Hauptaufgaben zählten der Umbau auf eine Restful Applikation. Zu diesem Zweck wurde das Django Rest Framework genutzt, um Funktionalitäten über eine Rest API anzubieten. Der Mitarbeiter hat dabei hauptsächlich Backendaufgaben im Rahmen von Proof of Concepts übernommen, aber auch Frontend Views in VueJS gebaut.
• Neben der Entwicklung von neuen Features war er auch daran beteiligt, neue Feature Requests mit Kunden & Stakeholdern zu besprechen und die Machbarkeit festzustellen.
• Darüber hinaus hatte er als technischer Teamlead die Verantwortung über abschließende Code Reviews. Zusätzlich kümmerte er sich um das Release Management und kommunizierte abteilungsübergreifend über Neuerungen und Änderungen der Plattform.

• Für den Betrieb einer Spendenplattform im Whitelabel Betrieb wurde ein zentrales Monitoring und Alerting System entworfen, implementiert und betrieben. Das Monitoring Konzept erfasste die Infrastruktur vollumfänglich:
  • Erfassung von Systemmetriken über Prometheus
  • Erfassung aller relevanten Logfiles über rsyslog
  • Erfassung von Metriken der Softwareplattform über Prometheus
  • Erfassung von HTTP Responses über OpenResty
  • Erfassung von Backend & Frontend Softwarefehlern über Sentry
  • Darstellung der Daten über Grafana
  • Alerting über Grafana und Alertmanager
• Der Prometheus und Grafana Stack läuft in redundanten Docker Containern auf geographisch getrennten Servern. Die Alerts werden in verschiedenen Kategorien unterteilt. Basierend auf dem Schweregrad des Alerts wurden Mitarbeiter über verschiedene Kanäle (von Email über Slack bis hin zu kritischen iOS/ Android Benachrichtigungen) informiert.
• Zusätzlich werden die Daten in Grafana in verschiedenen Dashboards dargestellt. Dies umfasst eine Management Summary, einen Uptime Report für Kunden der Whitelabel Plattform bis hin zu detaillierten Grafiken für die IT Abteilung.

• Entwurf der Systemarchitektur für das Monitoring System
• Auswahl der Technologien und Tools für die Implementierung
• Implementierung der Benutzeroberfläche für das Monitoring Dashboard
• Implementierung von Alerts und Benachrichtigungen
• Aufbau von Continuous Integration/ Delivery Pipelines
• Bereitstellung von 3. Level Support für technische Probleme

• Im Rahmen eines internen Hackathons wurde ein neues Onboarding & Monitoring System entwickelt. Ziel des Systems war es Kernfunktionalitäten einer Whitelabel SaaS-Lösung zu Abstrahieren und in einem Dashboard darzustellen. Über das in PHP geschriebene Produkt war es möglich, den Status der Whitelabel Plattformen zu erfassen. Auch konnten Grundeinstellungen der Whitelabel-Plattform vorgenommen werden
• Das Projekt wurde nach dem Hackathon fortgeführt und der Mitarbeiter erweiterte es um die Möglichkeit das Onboarding für Kunden abzuwickeln. Daten die von dem Tool erfasst wurden, konnten genutzt werden, um automatisiert die Whitelabel Plattform zu erstellen.
  

Aufgaben:

• Planung und Führung eines Hackathons
• Anforderungsanalyse
• Umsetzung der Anforderungen in PHP
• Aufbau von Continuous Integration/Delivery Pipelines
• Bereitstellung von 3. Level Support für technische Probleme
  

• Für das Projekt wurden Server und Clients hinsichtlich installierter Software und verwendeter Hardware untersucht. Zu diesem Zweck wurden Skripte geschrieben, die über einen Agenten (?C?) oder ?Agentless? (SSH/Shell) auf dem Zielsystem ausgeführt werden konnten. Die gesammelten Daten wurden in einer zentralen Software gesammelt und ausgewertet.
• Der Fokus lag auf der Erkennung von Oracle Produkten, um kostspielige Nachlizensierungen seitens Oracle zu vermeiden. Zu diesem Zweck war es beispielsweise auch möglich Datenbankabfragen zu stellen, um die von Oracle gestellten Kriterien zu erfüllen. Die entwickelte Software war eines von nur drei Oracle verifizierten Tools zur Lizenzkostenberechnung.

• Anforderungsanalyse
• Entwurf der Architektur der Applikation und Skripte, einschließlich der Verteilung der Softwareagenten
• Tests und Qualitätskontrolle
• Dokumentation
• 3. Level Support