Eine vollständige Überarbeitung der Infrastruktur ist eine der anspruchsvollsten Initiativen, die jedes Technologieteam unternimmt. Oftmals hat das Team hinter einem bestimmten Stack das Team verlassen, was zu vielen unvorhergesehenen Umständen geführt hat. Bei mPharma war dies jedoch nicht der Fall. Im Laufe der Jahre hatten wir einen ausreichenden Wissenstransfer über kritische Teile des Systems hinweg. In diesem Artikel möchte ich erzählen, wie es uns gelungen ist, unsere Kerninfrastruktur von Marathon/Mesos auf Kubernetes zu migrieren.

Im Laufe der Jahre haben wir aktiv eine Reihe von Produkten entwickelt, die auf den ständig wachsenden Bedürfnissen eines Patienten in Afrika basieren. Um nur einige aufzulisten;

1. Wir haben Bloom , unsere proprietäre Anwendung zur Verwaltung der modernen Apotheke, erfolgreich in 9 Ländern skaliert (zum Zeitpunkt der Erstellung dieses Artikels ist diese Zahl auf 10 gestiegen).
2. Außerdem haben wir myMutti gestartet , eine E-Commerce-Plattform für den Online-Kauf von rezeptfreien Medikamenten (OTC) und deren Lieferung nach Hause.
3. Wir haben eine Lager- und Logistikanwendung entwickelt und eingeführt, um die Bewegung von Produkten von unserem Lager zu Partnerapotheken und Krankenhäusern, bekannt als Marketplace, besser zu verfolgen.
4. Wir haben eine Last-Mile-Lieferanwendung eingeführt, um den Transport von Medikamenten weiter zu digitalisieren.
5. Wir haben auch damit begonnen, Diagnosedaten innerhalb von Bloom zu sammeln, um unser Mutti-Ärzteprogramm zu erweitern .

Das Ingenieurteam hatte im Laufe der Jahre über die Möglichkeit einer Migration unserer Kerninfrastruktur nachgedacht. Unser explosives Wachstum als Unternehmen führte jedoch dazu, dass wir Bauprodukten den Vorrang einräumten, statt unsere Kerninfrastruktur neu zu erfinden. Im Januar 2021 wurde uns klar, dass wir unsere Infrastruktur neu erfinden müssen, sonst können wir das Wachstum, das wir als Unternehmen und Team erlebten, nicht unterstützen.

Die Kerninfrastruktur bei mPharma hatte im Laufe der Jahre verschiedene Phasen durchlaufen. Dies war jedoch unser erster Versuch einer vollständigen Überarbeitung und der Sicherstellung, dass unsere Infrastruktur dem Wachstum des Unternehmens und des Teams als Ganzes entspricht.

Unsere Gespräche begannen mit der Konzentration auf das Problem, das wir lösen wollten. Dies trug dazu bei, dass wir jegliche Voreingenommenheit bei der Auswahl eines bestimmten Tools reduzieren und uns auf die beste Lösung konzentrieren konnten. Eine wichtige Frage, die wir uns gegenseitig stellten, war: „Welcher Stack wird uns beim Wachstum helfen?“ Wir haben uns zunächst auf fünf Schlüsselbereiche konzentriert;
1. Skalierbarkeit
2. Entwicklererfahrung
3. Community-Support
4. Sicherheit
5. Kosten

Basierend auf dem oben Gesagten und einigen hitzigen Debatten haben wir uns für Kubernetes entschieden.

Was ist Kubernetes?

Laut Kubernetes.io ist Kubernetes, auch bekannt als K8s, ein Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von Containeranwendungen. Es gruppiert Container, aus denen eine Anwendung besteht, in logische Einheiten, um die Verwaltung und Erkennung zu erleichtern. Kubernetes basiert auf 15 Jahren Erfahrung in der Ausführung von Produktions-Workloads bei Google, kombiniert mit den besten Ideen und Praktiken der Community.

Migrationsprozess

Jede Migration dieser Größenordnung führt in der Regel zu Serviceausfällen. Unser Ziel war es, diese entweder vollständig zu vermeiden oder ihr Auftreten zu minimieren. Unser erster Schritt bestand darin, ein Projektteam unter der Leitung eines Projektleiters zu bilden. Der Projektleiter war für das End-to-End-Management der Migration verantwortlich und stellte sicher, dass alle relevanten Interessengruppen über den Fortschritt verschiedener Initiativen auf dem Laufenden gehalten wurden. Einige davon umfassen:
1. Wie hoch sind die zusätzlichen Kosten für die Einrichtung zusätzlicher Server?
2. Was ist der beste Weg, um Anwendungen einfach auf Kubernetes bereitzustellen, ohne dass es zu Unterbrechungen des Entwicklungsworkflows kommt?
3. Wie messen wir den Erfolg der Bereitstellung?
4. Wie werden wir den Datenverkehr nach der Migration effizient von unseren alten Servern auf die neuen umleiten?

Wie hoch sind die zusätzlichen Kosten für die Inbetriebnahme zusätzlicher Server?

Als Team ist es einer unserer Hauptschwerpunkte, die Kosten zu senken, da diese Einsparungen dazu führen, dass mPharma als Unternehmen den Patienten niedrigere Arzneimittelkosten anbieten kann. Wir wollten mit unserem Cloud-Anbieter sprechen, um herauszufinden, ob er über ein Programm für Proof-of-Concept-Projekte (POC) verfügt. Es gelang uns, unseren Cloud-Anbieter dazu zu bringen, die Kosten für unsere Migration zu übernehmen, bis wir in einer stabilen Position waren. Aus diesem Grund haben wir in den ersten Wochen unserer Migration im Wesentlichen 0 US-Dollar ausgegeben.

Was ist der beste Weg, Anwendungen einfach auf Kubernetes bereitzustellen, ohne den Entwicklungsworkflow zu unterbrechen?

Wir wollten eine Möglichkeit, diese Migration durchzuführen, ohne den Softwareentwicklungslebenszyklus der Ingenieure zu unterbrechen. Ein wichtiger Punkt ist, dass wir während der Migration weiterhin Produkte für Patienten entwickelten und das Geschäft weiterhin mit alarmierender Geschwindigkeit wuchs. Vor dieser Migration verfügten alle unsere Dienste über eine .yaml-Datei, die Bereitstellungsanweisungen enthielt. Wir wollten die Ingenieure nicht mit dem Schreiben neuer Bereitstellungsanweisungen überfordern. Aus diesem Grund haben wir uns entschieden, unser Bereitstellungsskript in GitLab zu zentralisieren. In diesem Skript gab es Abschnitte, die Code sowohl für Marathon/Mesos als auch für Kubernetes bereitstellten. Dadurch wurde sichergestellt, dass die Arbeit der Ingenieure während dieser Migrationsphase nicht beeinträchtigt wurde.

Wie können wir den Datenverkehr nach der Migration effizient von unseren alten Servern auf die neuen umleiten?

Dies war die schwierigste und schwierigste Phase unserer Migrationsstrategie. Unser Fokus lag darauf, welcher Weg zu keiner Beeinträchtigung der Servicequalität führt. Die Umstellung des Datenverkehrs auf die neuen Server war für uns schwierig, da wir bei dieser Migration die Art und Weise der Authentifizierung und Autorisierung überarbeitet hatten. Dies machte es uns unmöglich, eine schrittweise Migration durchzuführen. Wir mussten alle Dienste auf einmal migrieren. Nach einigen Diskussionen tendierten wir dazu, diese Entscheidung anhand von Verkehrsdaten zu treffen. Wir haben den Verkehr zu unseren Anwendungen untersucht, um den besten Zeitpunkt für eine Verkehrsumschaltung zu ermitteln. Nachdem wir uns die Daten unseres API-Gateways angesehen hatten, entschieden wir uns für Samstagabend. Dies lag daran, dass wir sonntags weniger Verkehr auf unserem Netzwerk hatten, sodass etwaige Störungen einen sehr kleinen Explosionsradius haben. Wir haben uns auch für die Arbeit im Büro entschieden, um die Reibungsverluste bei der Kommunikation zu reduzieren. Wir bestellten eine Menge Pizza, denn wir wussten, dass die Aufgabe nicht einfach sein würde. Um 23:00 Uhr GMT fuhren wir mit der Verkehrsumschaltung fort.

Wie messen wir den Einsatzerfolg?

Eines der Teams, von dem Sie wenig hören, ist unser Qualitätssicherungs- und SRE-Team. Diese beiden Teams stellen sicher, dass die von uns hergestellten Produkte den höchsten Standards entsprechen. Isaac, der QA-Leiter, wird jedoch immer sagen: „Die Qualität der Produkte liegt nicht nur in der Verantwortung des QA-Teams.“ Wir haben beschlossen, nach der Migration alle mitzuhelfen, um verschiedene Teile der Anwendung zu testen, um sicherzustellen, dass alles reibungslos lief. Ein weiterer wichtiger Bereich, den ich nicht hervorgehoben habe, war, dass wir vor der Bereitstellung in der Produktion unsere Test- und Staging-Umgebungen auf Kubernetes migriert haben. Dies gab uns die Gewissheit, dass alles ordnungsgemäß getestet wurde und wie erwartet funktionierte.

gewonnene Erkenntnisse

1. Den Nutzungsmetriken keine Beachtung schenken

Kurz nach der Bereitstellung auf Kubernetes stellten wir fest, dass unsere Benutzer eine Reihe von Problemen mit Anwendungsausfällen meldeten. Bei der Migration unserer Anwendungen haben wir uns auf Kostensenkungsmaßnahmen konzentriert und die Menge an Speicher und CPU begrenzt, die einem bestimmten Container zugewiesen werden kann. Dies führte dazu, dass Container abstürzten oder neu gestartet wurden, wenn sie ein Speicher- oder CPU-Limit erreichten. Eine wichtige Lektion für uns war, dass wir nicht auf die Container-Nutzungsmetriken unserer alten Infrastruktur geachtet haben und diese nicht für die Entscheidung verwendet haben, wie wir den einzelnen Diensten Ressourcen zugewiesen haben.

2. Fehlkonfiguration von Diensten durch Dienstinhaber

Ein weiterer Fehler, der uns auffiel, waren Fehlkonfigurationen durch Dienstinhaber. Das Einrichten von Umgebungsvariablen für Dienste war mit viel manueller Arbeit verbunden, was dazu führte, dass Ingenieure Fehler machten. Daran arbeiten wir aktiv und finden heraus, wie wir Variablen am besten verwalten können, um die Anzahl der Fehler zu begrenzen.

3. Fehlende Unit- und End-to-End-Tests

Aufgrund der Art und Weise, wie wir die Authentifizierung in unserer alten Infrastruktur gehandhabt haben, und der Notwendigkeit, so schnell wie möglich zu migrieren, haben wir in unserer CI/CD-Pipeline auf Unit-Tests und End-to-End-Tests verzichtet. Dies führte zu mehreren Fehlern, die abgefangen worden wären. Für den Fall, dass wir eine weitere Migration durchführen, stellen wir immer sicher, dass diese Phase in den CI/CD-Prozess einbezogen wird.

4. Verkehr wechseln:

Die Umstellung des Datenverkehrs zwischen unserer alten und unserer neuen Infrastruktur hätte anders gehandhabt werden können. Anstatt 100 % des Verkehrs zu verlagern, hätten wir uns darauf konzentrieren können, dies schrittweise vorzunehmen, um den Explosionsradius zu verringern.

Es hat ungefähr sechs Monate gedauert, diesen Artikel zu schreiben, da sich das Team darauf konzentriert hat, sicherzustellen, dass die Migration nicht zu einer Verschlechterung der Servicequalität führt, und sich auch auf die Entwicklung/Verbesserung von Produkten konzentriert hat, mit denen unsere Kunden interagieren. Aufgrund der Interaktion mit verschiedenen wichtigen Stakeholdern innerhalb und außerhalb des Unternehmens kann ich sagen, dass die Migration ein Erfolg war. Wir verbessern unsere Dienstleistungen weiterhin, um unsere Kunden besser zu bedienen und sicherzustellen, dass wir es den Patienten leicht machen, von den enormen Infrastrukturinvestitionen zu profitieren, die mPharma im Gesundheitswesen tätigt.