Produktionsbereit ist nicht benutzerfreundlich
Kontinuierliche Bereitstellung ist das vorletzte Ziel von Organisationen, die DevOps einführen. Dies ist nicht das ultimative Ziel, da dies einer kontinuierlichen Bereitstellung gleichkäme.
In den Gassen von DevOps wird viel Aufhebens um die Fähigkeit gemacht, zigmal am Tag produktionsreife Software auszuliefern.
Das ist schön.
Der Grund, warum ich mich darüber nicht allzu sehr freue, ist, dass in den meisten Unternehmensorganisationen – selbst denen, die DevOps einsetzen – die Bereitstellung nur der erste Schritt in der Markteinführungsphase eines Anwendungslebenszyklus ist. Nur wenige Anwendungen sind zum Zeitpunkt der endgültigen Build- und Release-Benachrichtigung für die Benutzer „bereit“. Es muss noch in die Produktion überführt werden, wo eine Reihe von Verfahren und Richtlinien die ordnungsgemäße Bereitstellung für die Benutzer sicherstellen.
Sehen Sie, kontinuierliche Bereitstellung ist (sollte, könnte, wird) das ultimative Ziel der Einführung von DevOps in Organisationen. Selbst wenn dies nicht der Fall ist, besteht ein größeres Problem darin, dass die bloße Bereitstellung für die Produktion nicht bedeutet, dass eine Anwendung an ihre Bestandteile „bereitgestellt“ ist. Dies erfordert die Bereitstellung in der Produktion zusammen mit allen erforderlichen Diensten zum Skalieren, Sichern und Beschleunigen der Anwendung, um sicherzustellen, dass sie den Benutzern – sowohl Unternehmen als auch Privatkunden – ein optimales Anwendungserlebnis bietet.
Dies könnte einen Lastenausgleich bedeuten, um Skalierbarkeit und Verfügbarkeit sicherzustellen. Es bedeutet mit ziemlicher Sicherheit Sicherheit – zumindest bei der Firewall, hoffentlich App-Sicherheit und möglicherweise mehr. Es kann auch Zugriff und Identität bedeuten. Dies gilt möglicherweise nicht für Apps für Verbraucher, aber für Apps für Unternehmen, die möglicherweise in SSO oder föderierte Richtlinien einbezogen werden müssen, um einen reibungslosen und problemlosen Zugriff zu gewährleisten. Auch Geschwindigkeit im Sinne einer Leistung kann erforderlich sein.
All diese Dinge müssen geschehen, bevor eine App für die Benutzer „bereit“ ist. Und die „Produktion“ weiß es. Von den 32 % der Befragten in unserem „State of Application Delivery“ von 2017, die in die Kategorie „Wir haben 1–10 dieser Dienste im Einsatz“ fielen, fiel die Mehrheit auf die Seite „Wir haben mehr als 5“ und 63 % gaben an, dass heute 6–10 dieser Dienste im Einsatz sind.
Unabhängig von Problemen mit der kontinuierlichen Bereitstellung sind diese Dienste von entscheidender Bedeutung, um sicherzustellen, dass Apps „bereit für Benutzer“ und nicht nur „bereit für die Produktion“ sind.
Zigmalige Lieferungen in die Produktion sind großartig, aber häufigere Lieferungen auf den Markt sind das eigentliche Ziel. Selbst wenn DevOps in die Produktion einsteigt (bitte rein, das Wasser ist wirklich schön!), um die App und ihre unmittelbare Infrastruktur zu verwalten, gibt es immer noch vorgelagerte Dienste, die bereitgestellt, konfiguriert und getestet werden müssen, bevor die App tatsächlich als „ausgeliefert“ betrachtet werden kann.
Eine häufigere Freigabe von Apps für die Produktion hat keinen wirklichen Einfluss auf den Bereitstellungszeitplan. Es gibt einen Grund, warum Open-Source-Projekte über einen „stabilen“ Zweig und eine Option zum „Nightly Build“ verfügen. Natürlich kann ich mir die neuste und beste Version holen, aber als Benutzer bevorzuge ich die „stabile“ Option, denn wenn Apps nicht funktionieren oder zufällig abstürzen, trägt das in keiner Weise zu einem positiven Anwendungserlebnis bei.
Der Bereitstellungszeitplan muss vom Unternehmen bestimmt und von der IT umgesetzt werden. Das bedeutet, dass die IT (alle vier Betriebsbereiche) mit ins Boot geholt werden muss, um mit der Automatisierung eines möglichst großen Teils des Prozesses zu beginnen. Denn eine App ist noch nicht benutzerbereit, sondern wird durch die sie umgebenden Dienste in der Produktion gesichert und beschleunigt.