bitegra Solutions Framework

Grundsätze und Methodik unserer Produkt-Entwicklung, Qualitäts-Sicherung und DevOps

Jürgen Haas - @jurgenhaas

11. März 2021

Agenda

  1. bitegra Solution Gospel
  2. API First - was heisst das
  3. ALM - Application Lifecycle Management
  4. Betrieb
  5. Entwicklung

Gospel

  • API first
  • break down problems into components
  • separation of concerns
  • find out “real” requirements
  • DRY: don’t repeat yourself
  • commit/deploy often & anytime
  • tests & tests & tests
  • configuration in code
  • automate everything
  • small incremental updates
  • proactive monitoring
  • never ignore alerts

Wir haben diese Grundsätze nicht selbst erfunden …

Jeder einzelne ist Best Practice und in vielen Lehrbüchern zu finden.

… aber wir füllen sie mit Leben und praktizieren diese!

Beispiel: Automatisierung

Lohnt sich das? Es ist schon ein sehr großer Aufwand, die verschiedenen Aufgaben zu automatisieren.

  • Welcher Manager eines kleinen Teams ist bereit, 1.000 Stunden (ca. 125 PT) interne Ressourcen zu investieren, um DevOp Prozesse zu automatisieren?
  • Als kleines Team haben wir in den letzten 30 Monaten rund 60.000 automatisierte Pipelines laufen lassen.
  • Wenn jede Pipeline nur 1 Minute Arbeitszeit eingespart hat, sind wir bereits pari.
  • Gewinn: höhere Zuverlässigkeit + weniger Fehler = Qualität

API First

Anforderungen

  • Klar definierte Schnittstellen
  • Saubere Implementierung
  • Kompatibilität erhalten
  • Versionierung bei Breaking Change

Ertrag für Kunde

  • was einmal funktioniert, funktioniert immer
  • risikolose Weiterentwicklung einzelner Komponenten
  • freie Wahl eingesetzter Systeme (Server, Client und Desktop)
  • es wird irrelevant, welche Software eingesetzt wird
    die Funktion rückt in den Mittelpunkt
  • eingesetzte Komponenten sind austauschbar
    kein Vendor-Lock-In mehr möglich

Beispiel 1: Website-Formular

  • Auf der Website gibt es verschiedene Formulare für Kontakt und gezielte Anfragen
  • Die von Kunden und Interessenten ausgefüllten und abgeschickten Formulare sollen in ein Backend-System geschrieben werden, damit die Anfragen gezielt abgearbeitet werden können
  • Abhängig von gemachten Angaben - z.B. Typ der Anfrage - sollen im Backend-System verschiedene Kategorisierungen vorgenommen und Workflows ausgelöst werden

Traditioneller Ansatz

Was soll schon schief gehen?

Lösung per API

  • Komplexität erheblich reduziert
  • Nutzung definierter Schnittstellen
  • Anzahl möglicher Fehlerquellen um mindestens 80% reduziert

Beispiel 2: Fahrplan-Info

Nutzung der API Open-Data-Plattform Mobilität Schweiz mit Abfahrts-/Ankunftsanzeiger (TRIAS 2020)

Effizienz bei Verwendung einer API

  • Daten von API einmalig zentral abholen und speichern
  • Jede Nutzungs-Art (hier: Stelen Mattenhof) bekommen speziell dafür aufbereitete Daten
  • Kurzfristiger API-Ausfall wird kompensiert
  • API-Änderungen erfordern nur Anpassung des Import-Prozess, einmalig und zentral, die Anwendungen bleiben gleich
<table class="timetable combined">
  <thead>
    <tr>
      <th class="line"><div>Zeile</div></th>
      <th class="time"><div>Departure</div></th>
      <th class="station"><div>Station</div></th>
      <th class="destination"><div>Ziel</div></th>
      <th class="diff"><div>departs in</div></th>
      <th class="bay"><div>Bay</div></th>
    </tr>
  </thead>
  <tbody>
      <tr class="even">
      <td class="line"><div><i class="ico bus"></i><span class="label">16</span></div></td>
      <td class="time"><div>09:23          <span class="delayed">+3</span></div></td>
      <td class="station"><div>Mattenhof Bus</div></td>
      <td class="destination"><div>Kriens, Busschleife</div></td>
      <td class="diff"><div>1 Min.</div></td>
      <td class="bay"><div></div></td>
    </tr>
      <tr class="odd">
      <td class="line"><div><i class="ico bus"></i><span class="label">16</span></div></td>
      <td class="time"><div>09:24          <span class="delayed">+3</span></div></td>
      <td class="station"><div>Sternmatt</div></td>
      <td class="destination"><div>Kriens, Busschleife</div></td>
      <td class="diff"><div>1 Min.</div></td>
      <td class="bay"><div></div></td>
    </tr>
      <tr class="even">
      <td class="line"><div><i class="ico train"></i><span class="label">S4</span></div></td>
      <td class="time"><div>09:26          <span class="delayed"></span></div></td>
      <td class="station"><div>Mattenhof Bahnhof</div></td>
      <td class="destination"><div>Luzern</div></td>
      <td class="diff"><div>3 Min.</div></td>
      <td class="bay"><div>2</div></td>
    </tr>
    </tbody>
</table>

Beispiel 3: Multi-Channel Publishing

Redakteure

  • konzentrieren sich auf Inhalte
  • unabhängig von
    • Darstellungsform
    • Verwendungszweck
    • Auslieferungs-Mechanismus

Segmentierung

Persona und Kanal

Publishing

  • HTML auf der Website
  • JSON für APIs and externe Systeme (z.B. Digital Signage)
  • Push auf weitere Kanäle wie native Apps, Email, SMS, etc.

ALM

  • Zentral-Einheit: GitLab
  • Staging für jedes Projekt
    • immer Live, Test und Develop
    • zeitweise auch Feature Branches
    • Code wandert immer Upstream
    • Content wandert immer Downstream

Pipelines

  • Voll-automatisierter Prozess zum Bauen, Testen und Deployen eines Projekts auf einen beliebigen Stage
  • Minimum: grüne Jobs
  • Optimum: zusätzlich die gelben Jobs, zwingend für Pipelines auf Produktiv-Stages
  • Links:

Maintenance

Updates

  • kleine Inkremente
  • täglich
  • voll automatisiert
  • protokolliert
  • dokumentiert

Alle Komponenten des Stack

  • Betriebs-System
  • alle Services (Libraries und Treiber)
  • jede Software (Web-Server, PHP, MySQL, etc.)
  • jede Anwendung mit allen Dependencies (Drupal, DataCore, Shop, etc.)

Backup / Desaster Recovery

  • Backups: 3-2-1 Regel
  • Desaster Recovery

Betrieb

  • Pipelines
    • Provisionierung
    • Maintenance
    • Deployment
  • Monitoring
  • Alerting
  • Incident Management

Monitoring und Alerting: Host

  • 6.171 Messwerte pro Sekunde
  • 1.440 Charts zur Visualisierung
  • 955 Alarm-Typen definiert

Monitoring und Alerting: Logs

  • über 500.000/d
  • rund 24.000/h
  • ständige maschinelle Analyse
  • automatische Alarm-Typen
  • Forensische Analysen nach Events

Monitoring und Alerting: Services

  • Website-Erreichbarkeit
  • Prüfung auf korrekte Inhalte
  • Prüfung SSL-Zertifikate
  • Performance
  • 99,96% Verfügbarkeit

Monitoring und Alerting: Analytics

  • Echtzeit Analytics
  • Auf Kunden-Server gehostet
  • DSGVO konform

Monitoring und Alerting: und viele mehr

Alle Anwendungen schreiben in die Logs und im Falle eines Fehlers wird gleichzeitig ein Alarm ausgelöst.

Zielsetzung

  • Logs von Fehlermeldungen befreien
  • Fehler erkennen und beseitigen, bevor sich diese zu Problemen entwickeln
  • Störungen erkennen und reagieren, bevor der Kunde selber merkt, dass etwas nicht richtig funktioniert

Kurze Reaktionszeiten

Monitoring und Alerting: für Mobimo

  • Infrastruktur: alle Logs sammeln, überwachen, ausgewerten, alarmieren
  • Anwendungen: DataCore, Drupal, etc. melden Fehler direkt als Alarm
  • Prozesse: automatisierte Pipelines sind überwacht und brechen bei Fehlern ab, so dass keine Folgefehler produziert werden.
    Beispiele:
    • Update der Daten vom CRM
    • APIs mit Zendesk und Sharepoint
    • Abspielen von Playlists auf DigSig Playern
  • Aktuelles Beispiel: Drupal Security Review (Read-only Filesystem)

Entwicklung

Aufgrund der zuvor beschriebenen Infrastruktur können sich Entwickler auf die eigentlichen Aufgaben konzentrieren

Die wichtigsten Disziplinen sowohl bei Produkten als auch bei Projekten sind

  • Herausfinden, was die wirkliche Anforderung ist - der Kunde kann nur sehr selten genau das formulieren, was er tatsächlich braucht
  • Zerlegen der Aufgabe in unabhängige Komponenten
  • Definition jeder Komponente
    • Aufgabe / Zielsetzung / Output
    • Dokumentation
    • Test schreiben
  • Schlussendlich ist dann die Programmierung eine reine Fleiß-Aufgabe

Beispiel: Website

Website als Zwiebel, zerlegt von aussen nach innen:

  • Optik / Design: für die meisten Menschen am interessantesten
  • Inhalte: werden erfasst und kontinuierlich gepflegt
  • Daten-Modell: Struktur in der Datenbank für die Inhalte
  • Technische Plattform: die Maschine im Hintergrund

Zwiebelschichten in umgekehrter Reihenfolge

Die Kosten und die Lebensdauer der genannten Schichten einer Website sind ganz innen am höchsten und reduzieren sich, je weiter wir nach aussen kommen:

  • Technische Plattform und Daten-Modell: wenn das gut gemacht ist, hält dies für die Ewigkeit
  • Inhalte: Texte und Bilder werden erstellt, erhalten, aktualisiert, archiviert, versioniert
  • Optik und Design: wie in der Mode, jede Saison braucht neue Kleider

Fazit Zwiebel-Modell

Wenn die Grundlagen richtig gelegt sind, dann kann das Marketing alle 1, 2 oder 3 Jahre ein Redesign der Website durchführen, ohne jedesmal von vorne beginnen zu müssen. Nur die äusserste Zwiebelschicht (Optik und Design) wird neu gemacht.

  • Separation of concerns
  • Zerlegen von Aufgaben in Komponenten

Nicht zum ersten Mal begegnen wir diesen Prinzipien, bei einer Website werden sie erneut offenkundig.

Fazit für Mobimo

Bei Mobimo ist der heraus gearbeitete Effekt noch sehr viel stärker.

  • Die beiden innersten Zwiebelschichten (Technische Plattform und Daten-Modell) sind bei allen Arealen und damit auch bei allen Websites und Portalen zu 90-100% identisch.
  • Damit sind die teuersten aber auch am längsten nutzbaren Komponenten nur ein einziges Mal zu erstellen, zu pflegen und weiter zu entwickeln.
  • Der Löwenanteil ist bereits geleistet - bei jeder zusätzlichen Instanz, die entwickelt und ausgerollt wird, profitiert Mobimo in erheblichem Umfang von den bereits getätigten Investitionen.