Fallstudie

Vom Keller in die Cloud

Wie ein Monolith fliegen lernte und es bis in die Wolken schaffte

Ausgangslage

Bereits vor vielen Jahren hatte ein Unternehmen des Mittelstands eine Software selbst entwickeln lassen. Sie war genau auf die Bedürfnisse des Unternehmens zugeschnitten und hatte bereits über Jahre gute Dienste geleistet. Die Software war so ausgelegt, dass sie im hauseigenen Rechenzentrum lief. Weiterentwicklungen und Wartungen erfolgten durch ein externes Softwarehaus und eigene Mitarbeiter vor Ort.

Ein wenig problematisch wurde es über die Zeit, weil erste Mitarbeiter vom Homeoffice arbeiten sollten und somit der Zugriff auf das System nur über eigene virtuelle private Netzwerke (VPNs) möglich war, was eine zusätzliche Komplexität des Systems bedeutete.

Weiterentwicklungen und neue Funktionen mussten immer im System selbst erfolgen, weshalb es in regelmäßigen Zyklen Releasewechsel gab, die das gesamte System angepasst haben.
Mit der Zeit wurde das System mehr und mehr inflexibel, schwerer wartbar und zudem teurer.

Die Lösung

Geplant war, den Monolithen in die Cloud zu heben und so einfacher zugänglich und wartungsfreundlicher zu machen. Dazu sollte die monolithische Struktur in eine Microservice Architektur transformiert werden.Hierzu waren mehrere Schritte notwendig. Zunächst wurde geplant, eine API Schicht vor die bisherige Lösung zu bauen, die die Funktionen 1:1 weitergab.

Es war zunächst eine Analyse aller genutzten Funktionen notwendig, die dann über die API Schicht repliziert wurden. In einem nächsten Schritt wurden die Funktionen auf Microebene heruntergebrochen, um eine disjunkte Liste aller Microfunktionen zu erhalten. Alle Funktionen wurden einzeln spezifiziert und dokumentiert.So entstanden viele einzelne, in sich abgeschlossene Microfunktionen, die direkt in der Cloud ohne separate Server lauffähig waren.

Alle Funktionen wurden nach und nach ausgetauscht, so dass am Ende die Server und Software im Rechenzentrum abgeschaltet werden konnten und das gesamte System in der Cloud lief.Als IT Infrastruktur kam Amazon AWS zum Einsatz, da diese zum einen sehr robust und zum anderen auf Security-by-Design basiert.

Das Ergebnis

Die Transformation konnte bis auf wenige Unterbrechungen (für den Umzug der Datenbanken) fließend gestaltet werden. Ein harter Wechsel vom alten auf das neues System wurde so vermieden. Fehler konnten schnell erkannt und wegen der Microfunktionen schnell behoben werden.Die Entwicklung erfolgte mit Hilfe von Off-Shore Entwicklern. Eine Einarbeitung war nicht erforderlich, weil die notwendigen Spezifikationen nur für einzelne Funktionen erfolgte und diese einzeln getauscht werden konnten.

Neue Funktionen können auf die gleiche Art jederzeit hinzugefügt werden, ohne den laufenden Produktionsbetrieb zu stören.Es liegt eine jederzeit aktuelle Dokumentation vor, so dass Änderungen jederzeit von unterschiedlichen Entwicklern umgesetzt werden können. Die neue Anwendung ist so zukunftssicher.Die Kosten des Betriebs konnten deutlich gesenkt werden, da nur noch die benötigten Funktionen und Ressourcen berechnet werden statt eines ganzen Rechenzentrums.

Spätere Weiterentwicklung

Zu einem späteren Zeitpunkt wurde noch eine Konfigurationsmöglichkeit für externe Kunden hinzugefügt. Diese baute auf der zuvor geschaffenen Architektur auf und nutzte von Anfang an die Funktionen der API. Der Administrationsaufwand konnte weiter reduziert werden, weil Partner nun ihre Daten selbst pflegen konnten.

Genutzte Methoden/Skills

  • Business Analyse
  • Business Spezifikation
  • Change Management
  • Projektmanagement

Genutzte Tools

  • Amazon Web Services
crossmenu