Der letzte Beitrag der Blog-Post Serie zur Cloud Native App Journey wird sich ganz darauf fokussieren aufzuzeigen, was notwendig ist um Teams eine ideale Experience im eigenen Arbeitsumfeld zu ermöglichen.
Dabei geht es nicht nur darum, dass Entwicklern "fancy" Tools zur Verfügung gestellt werden, sondern das diese in einer Art und Weise eingeführt werden, dass die kognitive Last sinkt, die Governance und Security-Vorgaben eingehalten werden und natürlich maximaler Spaß bei der Arbeit ermöglicht wird.
Viele Aspekte dieses Themas finden sich bereits im CNCF Platform Engineering Maturity Model wieder. Unser DevX-Team bei FullStackS besteht ausschließlich aus Kollegen welche jahrelange Erfahrung zu diversen Aspekten von DevSecOps vorweisen können. Somit können wir zu diesem Thema sogar ein breiters Spektrum abdecken, als aktuell im Platform Engineering definiert ist.
Was kann ich mir von diesem Zwischenstopp erwarten?
Im Experience-Zwischenstopp sind folgende Themen enthalten:
Cloud native Inner Dev-Loop
Internal Developer Portal (IDP)
Cloud Development Environment
SW-Project Management
Cloud Native Runtimes
Enablement & Blueprints
Documentation & Guides (docs-as-code)
Dieser Zwischenstopp fokussiert sich ganz auf eine ideale Experience um so friktionsfrei wie möglich seiner täglichen Arbeit nachgehen zu können. Es ist dabei wesentlich, die unterschiedlichen Bedürfnisse im Auge zu behalten, jedoch gleichzeitig immer innerhalb der Governance und Security-Vorgaben zu bleiben.
Mithilfe eines IDP (z.B. auf Basis von Backstage) ist es möglich genau diese Vorgaben bspw. mit standardisierten Projekt-Templates abzubilden und gleichzeitig die kognitive Last zu reduzieren. Aus Entwicklersicht kann man sich voll und ganz auf die Umsetzung der fachlichen Anforderungen konzentrieren, da Themen wie CI/CD oder auch Security-Checks bereits vorkonfiguriert sind.
Um nun tatsächlich mit der Arbeit am Source Code beginnen zu können, ist es sinnvoll das auch die Entwicklungsumgebung vorkonfiguriert bereit gestellt wird. An der Stelle kommt ein Cloud Development Environment wie bspw. Coder zum Einsatz. Dieses ermöglicht entweder die Bearbeitung des Codes direkt über eine Web-IDE oder durch die Auslieferung von Dev-Container um unabhängig vom Endgerät immer die gleiche Dev-Experience zu erhalten.
In einem solchen Container ist nicht nur das Tooling für den Entwicklungsstack enthalten, sondern auch das Inner-Dev-Loop Tooling - wie bspw. Tilt oder Telepresence - um direkt mit der Betriebsplattform zu interagieren. Das ermöglicht es so realtitätsnah wie möglich den eigenen Code auszuführen, ohne das man mühsam weitere Systeme wie Datenbanken oder Message Broker aufsetzen muss.
Warum soll ich bei diesem Zwischenstopp halt machen?
Das bloße einführen einer neuen Betriebsplattform löst noch keine Probleme, diese muss von einer breiten Basis akzeptiert und besser noch Lieben gelernt werden um nachhaltige Änderungen zu erreichen.
Akzeptanz wird durch eine ideale State-of-the-Art Experience mit dem neuen Tooling und Plattform erreicht. Das hat außerdem den netten "Nebeneffekt" von höhrere Motivation und wiederum daraus resultierender höherer Produktivität.
Eine State-of-the-Art Experience hilft außerdem dabei neue Talente für das eigene Team zu gewinnen und bestehende Kollegen weiterhin in ihrer Arbeitsumgebung zu begeistern.
Verfolgt man nun noch konsequent einen Self-Service bzw. "x-as-a-Service" Gedanken, entlastet das zusätzlich die Kollegen bspw. in der Plattform Entwicklung, da sich diese voll und ganz auf die Bereitstellung der Plattform als Produkt für die Entwicklung oder Applikationsbetrieb fokussieren können. Damit werden auch eventuelle Bottle-Necks entfernt, da eine höhere Unabhängigkeit zwischen unterschiedlichen Teams und Teamtypen erreicht wird.
Wie läuft dieser Zwischenstopp ab?
Obwohl mithilfe von diversen Tools viele Probleme gelöst werden können, ist der Fokus niemals ein Tool selbst, sondern immer die Herausforderungen die zu bewältigen sind. Am Beispiel Backstage als Plattform zur Erstellung eines Internal Developer Portals (IDP) wird diese Vorgehensmodell greifbar. Backstage ist nämlich kein fertiges Produkt, sondern eine Plattform mit deren Hilfe ein IDP mit vollen Fokus auf die Bedürfnisse eines Teams oder Unternehmens umgesetzt werden kann.
Wir wenden auch an der Stelle unsere bewährte CRAWL-WALK-RUN Methodik an, um in kleinen iterativen Schritten das bestmögliche Ergebnis für unsere Kunden zur Verfügung zu stellen.
Somit sind wir am Ende der Reise der Blog-Post Serie angekommen. Voriges Jahr gab es im Zuge des Lightning-Talks bei unserem DevOps-Roundtable bereits eine Übersicht zu allen Zwischenstopps, welchen wir gerne in diesem Kontext als Zusammenfassung teilen möchten: https://www.youtube.com/watch?v=jAuMzNEnOYE
Nun richten wir unseren Blick in die Zukunft und geben euch abschließend einen Teaser auf den diesjährigen DevOps-Roundtable, bei dem das FullStackS DevX-Team einen Ausblick zu diesem Zwischenstopp geben wird. Wir werden dabei nicht weniger als die Zukunft einer echten cloud nativen DevSecOps-Experience live vorstellen.
Commenti