Eine serverlose Plattform bietet die Möglichkeit, jedem Entwickler seine eigene separate Full-Stack-Umgebung auf einer AWS Konto, das sie für Entwicklungs- und Testaktivitäten nutzen können.
Dies ist möglich, ohne dass die Kosten erheblich steigen und andere beeinträchtigen. Oder ohne das Risiko, dass das Setup des Entwicklers versehentlich geändert wird.
Serverlose Architektur vermittelt einen anderen Blick auf die alten Probleme und ist in vielerlei Hinsicht positiv erfrischend. Der größte Vorteil besteht darin, dass Sie keine Administratoren mehr im Team benötigen, um bei der Ausführung umfassender Prozesse keine Abstriche machen zu müssen. Der andere Vorteil – jetzt auf das interne Entwicklungsteam statt auf das Geschäft ausgerichtet – besteht darin, dass es dem Entwicklungsteam unbegrenzte Bedingungen für seine Entwicklungsarbeit bieten kann.
Was das genau bedeutet, erklären wir Ihnen hier, nämlich:
- So erstellen Sie eine unbegrenzte Entwicklungsumgebung auf einer serverlosen Plattform.
- Was sind die Vorteile eines solchen Setups für das Team?
- Die wichtigsten Bereiche, auf die man bei einem solchen Setup achten muss, damit es im Laufe der Zeit nicht kaputt geht.
- Demonstrationsbeispiel eines solchen Setups.
A Road to Standalone Environment Stack for Each Developer
Sie können die Entwicklungsinfrastrukturen als einen evolutionären Prozess im Laufe der Zeit betrachten.
Am Anfang war ein Licht…
Die übliche Methode zum Verwalten von Umgebungen für Entwicklungskonten besteht darin, eine oder mehrere separate Entwicklungsumgebungen zu erstellen. Im besten Fall enthalten sie alle Komponenten der Produktionsumgebung. Auch das ist alles andere als Standard. Oft ist die Entwicklungsumgebung auf einige der wichtigsten Dienste beschränkt und der Rest fehlt.
Natürlich ist es in einem solchen Umfeld schwieriger, eine zuverlässige Lösung zu entwickeln. Der Einfluss auf die nicht präsentierenden Systemkomponenten fehlt einfach. Das Managementteam wird sagen, dass das Team dies später in Testumgebungen während des Systemtests herausfinden kann. In den Augen der Entwickler wird dies jedoch niemals eine Empathie-Erfolgstrophäe gewinnen.
Entwicklungsaktivitäten werden weniger genau sein. Entwickler verbringen mehr Zeit mit der Überarbeitung und Behebung von Problemen, und insgesamt sinkt ihre Motivation, einen perfekten Code zu erstellen. Außerdem schaffen Sie mit einem solchen Setup bereits zu Beginn eine inkonsistente und instabile Umgebung.
Abhängig von der Größe des Teams können mehrere Entwicklungsumgebungen erforderlich sein, um die kritischsten Konflikte bei paralleler Arbeit zwischen den Teams zu entschärfen. Da sie sich die Entwicklungsumgebungen teilen, beeinflusst ein Entwickler den anderen auf die eine oder andere Weise. Eine intensive Kommunikation zwischen den Teammitgliedern ist ein Muss.
Mehr Entwicklungsumgebungen bedeuten weniger Konflikte, aber der Sharing-Faktor ist immer noch da. Es mag praktikabel sein, aber es wird nie ein perfektes Setup sein. Meistens erstellen die Entwickler am Ende etwas (das bereits in Konflikt steht) lokal direkt auf den Laptop-Computern. Dies kann später beim Zusammenführen des Codes zu zusätzlichen Problemen führen. Das Verhalten auf dem Laptop-Computer kann sich von dem in der Cloud unterscheiden. Dies kann zu Problemen führen, nachdem der Code mit den bereits von anderen durchgeführten Entwicklungen zusammengeführt wurde.
Aber dann hat jemand die Welt erschaffen …
Die offensichtliche Frage ist nun – was ist es dann? Welches Setup würde den Sharing-Faktor entfernen und das Team nicht dazu motivieren, neben dem Cloud-Konto auch andere Aktivitäten durchzuführen?
Stellen Sie sich vor, jedes Teammitglied erhält einen separaten Umgebungsstapel, den es für seine eigenen Aktivitäten verwenden kann. Es würde aus den gleichen Komponenten wie das Produktionssystem bestehen. Ohne die volle Datenlast, denn das ist etwas, was Sie nicht einmal wirklich für Entwicklungsaktivitäten wollen.
Oder gehen wir eine Ebene höher – wie wäre es, wenn Sie für jede Aufgabe, an der der Entwickler arbeitet, einen solchen Stack erstellen?
Teuer – denken Sie vielleicht.
Nicht wirklich – würde ich sagen.
Wenn die Entwickler die Umgebungen und ihre Ressourcen aktiv nutzen, dann ist der Lastvergleich zwischen der parallelen Durchführung von allem in einer gemeinsam genutzten Umgebung und der Aufteilung in mehrere Umgebungen in Bezug auf die Kosten sehr wahrscheinlich gleich. Weil Sie eine serverlose Architektur haben und nur für die tatsächliche Nutzung bezahlen.
Wenn die Entwickler nicht aktiv sind und dennoch diesen vollständigen Stack (oder mehrere gleichzeitig) erstellt haben, sind die Kosten gleich null, da Sie eine serverlose Architektur haben. Nicht genutzte Dienste verursachen keine Kosten.
Lassen Sie uns näher auf die Vorteile eingehen.
Benefits That Only the Development Team Can Appreciate
Zunächst einmal ist eines ganz klar. Alle Vorteile, die dieses Setup bietet, können nur vom Entwicklungsteam selbst geschätzt werden. Kein Management oder Geschäftsanwender wird jemals einen Wert darin sehen. Ich meine, sie könnten verstehen, wo der Wert liegt. Aber höchstwahrscheinlich werden sie nie zugeben, dass sie es unbedingt brauchen. Sie nutzen es nicht, und sie sehen es nicht in ihrer täglichen Arbeit.
Aber wie schwer ist es wirklich zu verstehen, dass die besten Entwicklungsergebnisse nur in den besten Arbeitsumgebungen erzielt werden können?
Hier also die Vorteile:
- Der Entwickler hat die Gewissheit, dass niemand sonst die Umgebung ändern wird, an der er gerade arbeitet. Alle Komponenten werden eigens für diese Aufgaben- und Entwicklungstätigkeit neu erstellt.
- Die Entwicklungsumgebung ist eine exakte Kopie der Produktionsumgebung. Dies bedeutet, dass eine genaue Simulation des Verhaltens von Codeänderungen möglich ist
- Das Team entwickelt sich immer direkt im Cloud-Konto, da es keinen Sinn mehr macht, dies lokal zu tun.
- Angenommen, Sie haben gebaut DevOps Pipelines für die Umgebungserstellung und -aktualisierung, in die Sie sie integrieren können Jira oder ADO-Tools für die Stories- und Ticketverwaltung und zum Erstellen oder Beenden der Entwicklungsumgebung zusammen mit Stories-Fortschritt und -Abschluss. Dadurch erhalten Sie für jede Story eine separate Entwicklungsumgebung. Oder sogar eine Aufgabe innerhalb der Geschichte, was für Backtracking-Zwecke wirklich großartig ist.
- Immer wenn der Entwickler eine Änderung am Code-Repository festschreibt, aktualisiert die Pipeline die Umgebung mit dem neuesten Repository-Code. Dies bedeutet Bereitstellungsautomatisierung beim Erstellen von neuem Code und schnellere Unit-Testing-Prozesse.
- Eine regelmäßige Wartung von Entwicklungsumgebungen ist nicht wirklich notwendig. Jede Umgebung existiert nur für eine bestimmte kurze Zeit. Es wird immer aus dem neuesten Repository-Codestatus und dem neuesten Daten-Snapshot erstellt. Das Wartungsproblem löst sich in diesem Fall von selbst.
What Are the Drawbacks?
Ja, es gibt einige Einschränkungen, die Sie beachten sollten. Als Nachteile würde ich sie nicht explizit bezeichnen. Wenn Sie den folgenden Dingen jedoch keine angemessene Aufmerksamkeit schenken, ist es sehr wahrscheinlich, dass sie im Laufe der Zeit zu Ihren Gründen für Infrastruktur-Refaktorisierungsaktionen werden.
# 1. Achten Sie auf AWS-Limits
Hier ist das Ding. Wenn Sie für jede Person und Aktivität einen separaten Umgebungsstapel erstellen, werden Sie viele AWS-Objekte erstellen.
Denken S3 Eimer, Richtlinien, Rollen, Benutzer, Datenbanken, VPCs usw.
Dies ist ein Muss für Sie, um zu überwachen und zu überwachen. Wenn die Umgebungen nur erstellt werden und Entwickler immer mehr davon hinzufügen, ohne die alten oder die mit bereits abgeschlossenen Geschichten zusammenhängenden ordnungsgemäß zu löschen, werden Sie früher oder später auf Probleme mit dem Erreichen verschiedener AWS-Limits stoßen.
Einige von ihnen sind leicht zu erhöhen. Andere können Sie über den AWS-Support anfordern. Und dann gibt es noch ein paar harte Limits, an denen man nichts ändern kann, wenn man sie einmal erreicht hat.
In diesem Spiel geht es darum, die Gesamtzahl der verwendeten AWS-Objekte pro Objekttyp zu steuern. Es geht darum sicherzustellen, dass Sie nicht ständig am Limit tanzen. Sie wollen nicht die meiste Zeit im oberen Bereich der Limits sein. Das würde effektiv bedeuten, dass Sie sich vor jeder neuen Umgebungserstellung zunächst mit einigen manuellen oder automatischen Reinigungsvorgängen befassen müssen.
In jedem Fall wird dies nur dazu führen, dass die Entwicklungsaktivitäten insgesamt verlangsamt werden. Das Entwicklungsteam wird ständig damit beschäftigt sein, bestehende Umgebungen zuerst aufzulösen, bevor es eine neue erstellt.
Stattdessen ist es wirklich entscheidend, alle Limits proaktiv in Schach zu halten, indem man im Hintergrund ständig hauswirtschaftet. Idealerweise auf automatisierte Weise, damit ein Entwickler, wenn er das nächste Mal eine frische neue Umgebung benötigt, diese sofort ohne weitere Verzögerungen erstellt.
# 2. Halten Sie die Ausführungszeit der DevOps-Pipeline niedrig
Es klingt großartig zu sagen, dass jede neue Entwicklungsumgebung automatisch erstellt wird, sobald Sie mit der Arbeit an einer Story beginnen.
Es klingt schrecklich, wenn das in Wirklichkeit bedeutet, dass der Entwickler einige Stunden auf eine solche Umgebung warten muss. Und dann nicht nur für die Erstellung, sondern für jede nachfolgende Aktualisierung der Umgebung (direkt nach jedem Repository-Commit).
Setzen Sie es in eine zusammenfassende Formel und sehen Sie, wie viel Leerlaufzeit eine solche Situation erzeugen würde. Es ist für einen Entwickler nicht wirklich möglich, jedes Mal zu „etwas anderem“ zu springen, wenn er warten muss, bis die Umgebung bereit ist.
Das wäre so, als würdest du erwarten, dass du einkaufen gehst, während du beim Arzt auf deine geplanten Kontrollen wartest. Es wird einfach nicht passieren. Du sitzt da und wartest, weil es jede nächste Minute kommen könnte.
# 3. Stammdatensatz regelmäßig aktualisieren
Jede neue Umgebungserstellung muss über ein Verweisquellen-Dataset verfügen. Dies dient dazu, die Daten auf den gerade erstellten Umgebungsstapel zu kopieren. Der Datensatz muss regelmäßig (grundsätzlich nach jeder Produktionsfreigabe) aktualisiert werden. Dadurch wird sichergestellt, dass die Umgebung mit der neuesten Datensatzstruktur erstellt wird.
Es muss kein vollständiger Datenbank-Snapshot aus der Produktion enthalten sein, obwohl dies normalerweise der einfachste Weg ist. Das Datenmodell muss jedoch immer aktuell sein, damit jede neue Entwicklungsaktivität am richtigen Ausgangspunkt beginnt.
# 4. Bringen Sie Ihrem Team bei, „umweltbewusst“ zu sein
Umweltfreundlichkeit ist heute ein großes Thema und wird von allen großen Unternehmen erwartet. Ähnliche Erwartungen gelten auch für das Entwicklungsteam.
Wenn ein Entwickler mehrere Umgebungen parallel benötigt, weil dies die Effektivität deutlich erhöht, dann sei es so. Aber wenn der Entwickler andererseits mehrere Umgebungen parallel geöffnet hält, nur weil er faul ist, sie zu schließen, dann ist das so schnell wie möglich zu heilen.
Das Privileg, an einer privaten Sandbox zu arbeiten, muss mit einem angemessenen Maß an Verantwortung einhergehen. Wir erwarten nichts Geringeres als einen verantwortungsvollen und solidarischen Umgang mit diesen Vorteilen.
Example Setup
Wenn Sie nun alles zusammenfassen, ist hier, was Sie von einem solchen serverlosen Setup mit mehreren Umgebungen erwarten können.
- Sie können die DevOps-Pipeline verwenden, um die Erstellung, Aktualisierung und Beendigung neuer Umgebungen zu automatisieren.
- Dann wird der Entwickler an der Entwicklungsumgebung arbeiten und diese aktualisieren, während er in der Entwicklung voranschreitet.
- Sobald der Entwickler mit Codeänderungen fertig ist und Unit-Test, schließen Sie die Aktivität in dieser Umgebung ab, indem Sie den Code mit dem Master-Repository-Zweig zusammenführen.
- Da dies viele Entwickler gleichzeitig tun können, sind Code-Merging-Aktivitäten notwendig, um sicherzustellen, dass alle Änderungen aus den Entwicklungsumgebungen an den Single Place of True – den Master-Branch – übertragen werden.
- Aktualisieren Sie die zentrale Testumgebung mit diesem Master-Branch-Repository-Status, sodass die Systemtestaktivitäten über den zusammengeführten Code aller Entwickler ausgeführt werden können.
- Verwenden Sie eine dedizierte Fehlerbehebungsumgebung, um alle laufenden Probleme zu beheben. Diese Umgebung kann mit denselben bereits vorhandenen DevOps-Pipelines erstellt werden (behandeln Sie sie einfach als eine weitere temporäre Entwicklungsumgebung).
- Fahren Sie schließlich mit dem QA-Test und der Produktionsfreigabe fort.
Wie Sie sehen, können Sie durch die Wiederverwendung derselben DevOps-Pipeline auf verschiedenen Stufen der Architektur schnell eine flexible serverlose Plattform mit so vielen eigenständigen Entwicklungs- oder Testumgebungen wie nötig erstellen. Das Beste daran ist, dass alle Vorteile nicht mit Kosten verbunden sind.
Das könnte Sie auch interessieren Serverless-Computing-Plattformen um Ihren Code auszuführen.
