Heroimage
Smarte Lösungen für effizientes Logistikmanagement

INTELLIWAY ISEA – LOGISTIK-SOFTWARE IN DER CLOUD

Jedes Unternehmen, das heute Waren zu Märkten transportiert, ist auf reibungslos funktionierende logistische Prozesse angewiesen. Software-seitige Stabilitäts- und Performance-Probleme sind für die Kunden nicht akzeptabel. Wie sorgten wir also dafür, dass der Logistikberater intelliWay zu einer ausfallsicheren Plattform kam? Was unterschied dieses Projekt von anderen Lift&Shift-Projekten? Und aus welchen Gründen entschieden wir uns für die Open Telekom Cloud (OTC)?

Kontaktiert uns!

Fakten & Eckdaten

Technologien
Open Telekom Cloud,
Terraform, .NET, Microsoft SSRS, MS SQL, Flyway,
Gitlab-CI, Pager Duty
Team-Setup
2 Cloud Backend Engineers
Laufzeit
Juli 2020 – Oktober 2020
Das iSEAportal ist eine webbasierte Transportmanagement-Plattform. Jeden Tag arbeiten mehrere Tausend Benutzer mit dem System, schreiben Leistungen aus, buchen Transporte und laden Versanddokumente hoch. Logistikdienstleister bestätigen die Aufträge und informieren zeitnah über Änderungen. Warum wollte intelliWay die stark frequentierte Plattform modernisieren und in die Cloud migrieren? Es ist natürlich nie verkehrt, die eigene Anwendung hin und wieder auf den Prüfstand zu stellen und Stellschrauben für eine bessere Performance zu identifizieren. Insbesondere wenn man, wie intelliWay mit iSEAportal, die Ambition hat, zu wachsen und neue Funktionen zu implementieren. Doch bis vor Projektbeginn hatte die Anwendung insbesondere während des Reportings häufig auftretende Performance-Probleme. Diese wollte intelliWay unbedingt beheben. Wie bei einem Anbau am Haus kann man auch hier nicht einfach loslegen. Zunächst haben wir also unter den Putz geschaut und festgestellt, welche Ursachen hinter den Performance-Problemen der Plattform steckten.

Zerlegung einer monolithischen Anwendung

Ursache Nummer 1 war das Reporting: Bislang war es ins Live-System integriert. Jeder Report hatte Auswirkungen auf die Performance des Portals. Daher war unser erster Schritt, um das gesamte Tool in einen stabilen Zustand zu überführen, die Auslagerung des Reportings in Microsoft SSRS. Dabei bauten wir auch Aktualisierungen und ein Versionierungssystem ins Reporting ein, damit Änderungen nachvollziehbar werden. Für künftige Änderungen an den Reports setzten wir eine eigene Pipeline auf.

Da wir gerade schon an der Substanz des Portals arbeiteten, modernisierten wir auch einige grundsätzliche Aspekte der Plattform. Ein Monitoring-Konzept, das bei Ausfällen schnell und zuverlässig Alarm schlägt, ist eine wichtige Voraussetzung für durchgängige Verfügbarkeit. Wie so oft bei Plattformen mit breiter Nutzerbasis und wenig Ausfalltoleranz setzten wir bei iSEAportal auf Pager Duty.

Wir hatten hier also kein reines Lift&Shift-Projekt, sondern haben die monolithische Anwendung an mehreren Stellen in einzelne Deployment-Einheiten zerlegt. Diese Einheiten können künftig unabhängig voneinander aktualisiert und erweitert werden.

So wurde also zunächst die große Anwendung leichtgewichtiger, weniger fehleranfällig und stabiler. Nun ging es an den nächsten Schritt: das Hosting.
iSEA Dashboard KundenüberblickiSEA Ad hoc Angebotsliste

Neue Cloud-Technologie: Die Open Telekom Cloud (OTC)

Ursache Nummer 2 für die Performance-Probleme war das bisherige Hosting. Das iSEAportal lag zuvor in einer Virtuellen Maschine bei einem deutschen Hosting Provider. Leider kämpfen viele der klassischen Hoster mit dem Noisy-Neighbour-Prinzip: Wie in einer Altbauwohnung, in der der Wasserstrahl der Dusche schwächer wird, wenn in der Nachbarwohnung jemand Geschirr spült, graben sich die auf derselben physischen Hardware gehosteten Anwendungen manchmal gegenseitig das Wasser bzw. die Prozessorzeit oder den Speicher ab. Somit wird die eigene Anwendung im Extremfall durch Downtimes gebeutelt, die gar nichts mit der eigenen Software oder der Auslastung auf der eigenen Anwendung zu tun haben, sondern mit der von benachbarten Anwendungen. Bei den großen Cloud Providern haben wir diesen Effekt noch nicht beobachtet – alle Applikationen laufen unabhängig voneinander und stören sich nicht.

Martin Denker, Geschäftsführer bei intelliWay, hatte zwei zentrale Wünsche: Dass sein System weniger häufig ausfällt und dass er schnell Bescheid weiß, falls das doch einmal passiert. Die Ausfallsicherheit erhöhten wir mit dem Umzug in die Cloud. Denn dort werden neue Server schnell und automatisiert provisioniert. Falls hier mal ein Server wegbricht, wird direkt ein Neuer gestartet. Für die Datenbank setzten wir einen Managed Service ein. Bei Managed Services in der Cloud kümmert sich der Anbieter um den Betrieb, weshalb oft weniger Wartungsaufwand anfällt als bei klassischen Hostern, was vor allem für Unternehmen in der Größenordnung von intelliWay relevant ist. Das eingebaute Monitoring sorgt ab sofort für die schnelle Benachrichtigung, falls es noch mal zu einer Downtime kommt.

Die Entscheidung für die Cloud war also leicht getroffen. Die optimale Cloud musste mehrere Voraussetzungen erfüllen:
•
Sie musste uns eine Managed-Service-Datenbank mit Microsoft SQL Server liefern,
•
benötigte eine virtuelle Maschine, auf der wir die .NET-Anwendung hosten konnten.
•
Außerdem wollten wir Infrastructure as Code mit Terraform verwenden und
•
ein flexibles Abrechnungsmodell haben.
Eine zusätzliche Anforderung an den Cloud-Anbieter war, dass intelliWay seinen Kunden vertraglich zugesichert hat, ausschließlich bei Unternehmen zu hosten, die dem deutschen Datenschutzrecht unterliegen. Somit sortierten wir alle Cloud-Anbieter aus, deren Hosting außerhalb von Deutschland liegt. Die einzige Cloud, die in unseren Augen alle Anforderungen erfüllte, war die Open Telekom Cloud (OTC).

Historisch haben wir die meisten Erfahrungen mit der AWS Cloud. Dennoch war die OTC kein absolutes Neuland für uns. In der Vergangenheit haben wir schon für das ein oder andere Projekt einen Proof of Concept für die Open Telekom Cloud erstellt. AWS ist natürlich der Vorreiter in Sachen Cloud Services und bereits seit 2006 am Markt. Die OTC gibt es seit 2016 und hier sind mittlerweile die meisten gängigen Services verfügbar, die die AWS Cloud auch anbietet. Da die Architektur und die Begrifflichkeiten sehr ähnlich sind, hatten wir bei unserem ersten Projekt in der OTC keine lange Anlaufphase, sondern konnten direkt durchstarten.

In etwa vier Monaten operativer Arbeit haben wir eine bestehende Software auf .NET-Basis in die Cloud überführt. Den bestehenden Monolithen haben wir dafür schon teilweise zerlegt und modularisiert. Genau das machte dieses Projekt für uns besonders interessant: Wir haben ein wohl überlegtes Lift&Shift vorgenommen, da wir Zugriff auf den Applikations-Code hatten und die Anwendung neu schneiden konnten, statt einfach nur den Monolithen unverändert in die Cloud zu migrieren.
Funktionsumfang
•
Lift&Shift-Projekt mit Zerlegung einer monolithischen Anwendung in einzelne Deployment-Einheiten
•
Auslagerung des Reportings in Microsoft SSRS inklusive Versionierungssystem
•
Modernisierung der Plattform mit Einführung eines Monitoring-Konzepts Pager Duty
•
Umzug der Software auf .NET-Basis in die Open Telekom Cloud
light mode button