Cloud-native Software Development
Was ändert sich für Ihre Entwickler?
Cloud-native Shift Left
Unter „Shift Left“ verstehen wir das Verschieben von Qualitätsrisiken auf einen möglichst frühen Zeitpunkt im Entwicklungs-lebenszyklus. Moderne Cloud-Techniken wie Container-Technologien und das Everything-as-code-Mantra erlauben uns, diese auch schon im Entwickler-Test einzusetzen.
Cloud-native Shift Left geht bis ganz nach links, dorthin, wo der Code entsteht: auf dem Entwicklerarbeitsplatz sind alle Integrationen testbar zu machen, das Entwickeln in Integrationstests wird zur neuen Norm.
In der Cloud-nativen Arbeitsweise schieben wir den Testaufwand nach links: Fehler werden also von den Entwicklern direkt bearbeitet. Produktionsfehler werden wieder in die Entwicklungssituation geworfen, wo alle Werkzeuge zur Analyse bereit stehen und die Fähigkeiten, diese einzusetzen, bestens entwickelt sind.
Developer Experience
Wir nutzen Linux, Docker und Kubernetes lokal auf dem Entwicklerarbeitsplatz.
Was tun wir damit?
- Fehler lokal unter voller Kontrolle und mit allen Mitteln analysieren
- Alternative Cluster-Konfigurationen ausprobieren und messen
- Übertragbare Umgebungen verkürzen die Einarbeitung neuer Entwickler
.. und was gewinnen wir dazu?
- Die Fähigkeit völlig neue Architekturen auszuprobieren
- Die Unabhängigkeit von Bestellprozessen
- Kosteneffizienz bei software development & engineering
- Zufriedenheit in einem befähigten Teams mindert Mitarbeiterfluktuation
Die Schulung für Ihr Team!
S&N Invent bietet eine Schulung zur Einführung aller Cloud-nativen Techniken an. Die Grundlagen von Linux, Docker und Kubernetes werden eingeübt. Jeder Teilnehmer lernt das Übertragen von Umgebungen zu beherrschen. Diese Inhalte richten sich an alle Entwickler, egal ob Frontend, Backend, Middleware oder Full-stack. Am Beispiel gehen wir auf die klassischen Technologien ein, insbesondere Networking. Auf dem eigenen Arbeitsplatzrechner kommt es zum (Erst-)kontakt mit Cloud-Technologie.
Der zweite Tag gehört ganz dem mitgebrachten Beispielprojekt, das in seine Cloud-native Form gewandelt und lokal zum Laufen gebracht werden muss. Es besteht aus Angular Webcomponents, einem Java (Quarkus) REST Service mit Kafka Consumer und Producer, der erforderlichen Middleware Apache Kafka und PostgreSQL.
Zusätzliche Inhalte sind Monitoring, Performance- und Last-Tests, Service Mesh, Verteilte Architektur-Muster und event-driven Modularisierung in weiteren Service-Technologien (Springboot+Java, NestJS+Typescript).
Der Cloud Team Enabler
Cloud-native Arbeitstechniken unterstützen Vorhaben mit verteilten Teams, funktionieren aber genauso auch für das einzelne Team. Lernen und Perfektionieren braucht Zeit. Organisches Lernen mit dem ganzen Team schafft nachhaltige Werte. Dazu beraten und unterstützen unsere Cloud Team Enabler ihre Entwickler und üben mit ihnen – mit spürbarem Unterschied.
Der Cloud Team Enabler
- wird vom Projekt bestellt, üblicherweise für Build-Automatisierung oder Deployment-Tätigkeiten.
- bewertet die bisherige Arbeitsweise und das vorherrschende Skill-Set, beobachtet Störungen und rät zu konkreten Maßnahmen.
- erkennt Neigungen und weist auf Chancen für individuelles Wachstum hin, um aus dem ganzen Team ein Cloud-natives Team zu formen.
- kennt die beliebtesten IDEs und stellt sie auf maximale Wirkung ein.
- weiß vom Wunsch der agilen Softwareentwicklung und sorgt für autonome, cross-funktionale Teams.
Eine neue Ökologie in der Software-Entwicklung
Open Source-Teams zeigen, wie räumlich getrenntes und zeitlich versetztes Arbeiten auf festen Grundsätzen besteht: es muss einfach sein, dem Projekt beizutreten; Features und Bugs müssen für jeden reproduzierbar sein; Mitarbeit zu unterbrechen ist praktikabel; zentrale Builds führen zum Release, blockieren aber nicht das Entwickler-Team.
Die Image Registry sollte mit allen Komponenten gefüllt sein, die zur vollständigen Lösung dazu gehören, inklusive der Konfiguration und einigen Testdaten. Sie enthält die Grundlagen für autonome d.h. selbstwirksame Entwickler, die ihre Stärken auf den Code anwenden können. Die eingebauten Sicherheitsprüfungen einer Image Registry machen sie zur Drehscheibe einer Secure Supply Chain. CI/CD Pipelines können überall dort entstehen, wo die Teams sie brauchen.
