Anti-Muster bei der Verwendung von Ebenen mit Terraform

In der sich ständig weiterentwickelnden Landschaft des Cloud Computing und des Infrastrukturmanagements hat sich Terraform zu einer transformativen Kraft entwickelt, die es Unternehmen ermöglicht, ihre Infrastruktur als Code (IaC) zu definieren, bereitzustellen und zu verwalten. Die Vielseitigkeit von Terraform erstreckt sich auch auf die Projektstrukturierung. Es bietet eine Vielzahl von Ansätzen, von modularen Designs und Remote-Statusmanagement bis hin zur Verwendung von Arbeitsbereichen und Versionskontrolle, so dass die Benutzer ein breites Spektrum an Optionen haben, um ihre IaC-Projekte an unterschiedliche Bedürfnisse anzupassen. In Terraform besteht die typische Organisationsstruktur aus Modulen, d.h. wiederverwendbaren Codeeinheiten, die Infrastrukturkomponenten kapseln. Diese Module können zusammengesetzt werden, um eine komplexere Infrastruktur zu schaffen. In der Terraform-Dokumentation gibt es kein standardisiertes oder offizielles Konzept, das als "Terraform-Schichten" bezeichnet wird. Der Begriff hat jedoch in der Terraform-Community an Popularität gewonnen. Wenn Sie nach dem Begriff "Terraform-Schichten" suchen, werden Sie verschiedene Artikel finden, in denen das Konzept diskutiert wird.

Frühe Stadien der Terraform-Schichten

Einer der ersten Hinweise auf die Verwendung von Ebenen mit Terraform war ein Vortrag von Armin Coralic (Sie finden ihn hier). In seinem Vortrag ging Armin auf die Entwicklung der Verwendung von Terraform für IaC ein und stellte einen mehrschichtigen Ansatz vor, um Herausforderungen in verschiedenen Phasen zu bewältigen. Er hob drei wichtige Schichten im Terraform-Code hervor: die Bootstrap-Schicht, die sich auf die Einrichtung der Infrastruktur konzentriert, die Foundation-Schicht, die globale und grundlegende Aspekte behandelt, und die Service-Schicht, die für die Implementierung spezifischer Dienste verantwortlich ist. Diese Schichtenstrategie zielt darauf ab, Flexibilität zu bieten, das Testen zu vereinfachen und organisatorische Änderungen in großen und komplexen Umgebungen effektiv zu verwalten. Abschließend wies er darauf hin, wie wichtig es ist, sowohl die Tools als auch die organisatorischen Praktiken für eine erfolgreiche Implementierung von Terraform in unterschiedlichen Kontexten zu berücksichtigen. Der mehrschichtige Ansatz von Terraform kann in Szenarien, in denen die Infrastruktur und die organisatorischen Anforderungen komplexer und anspruchsvoller werden, hervorragend funktionieren. Dieser Ansatz ist besonders effektiv in mittleren bis großen Organisationen mit mehreren Teams, unterschiedlichen Verantwortlichkeiten und unterschiedlichen Lebenszyklen von Infrastrukturkomponenten. Er ist besonders vorteilhaft, wenn es darum geht, Arbeit und Verantwortlichkeiten zwischen Teams aufzuteilen, unterschiedliche Lebenszyklen zu verwalten und eine monolithische Struktur zu vermeiden. Das Layering-Konzept hat den Vorteil, dass es das Testen erleichtert, die Flexibilität fördert und die Anpassung an Änderungen ermöglicht, die in komplexen organisatorischen Umgebungen häufig auftreten. Daher eignet sich der mehrschichtige Ansatz am besten für Umgebungen, in denen der Umfang und die Komplexität der Infrastruktur einen strukturierten und modularen Ansatz für den Terraform-Code erfordern. Man könnte jedoch argumentieren, dass dasselbe mit der Verwendung mehrerer Repositories erreicht werden kann, indem die Verantwortung für jedes Modul abstrahiert und vollständig auf ein Team übertragen wird.

Entwicklung der Terraform-Schichten

Im Bereich der Terraform-Architektur gibt es zwei primäre Ansätze: den einzelnen Monolithen (ein einziges Repository/Modul) und mehrere Module, die entweder in verschiedene Repositorys oder in mehrere Schichten aufgeteilt sind. Jeder Ansatz hat seine eigenen Auswirkungen, die Sie unbedingt gegen die besonderen Anforderungen Ihres Projekts abwägen müssen. Wenn Sie die Feinheiten dieser Alternativen verstehen, können Sie fundierte Entscheidungen treffen, die auf den spezifischen Anforderungen der Größe Ihrer Zielinfrastruktur, der Dynamik Ihres Teams und dem gewünschten Grad der Unveränderlichkeit basieren.

Monolith

Der Single-Monolith-Ansatz bietet inhärente Vorteile wie Sicherheit, Lesbarkeit und einen unkomplizierten Implementierungsprozess. Er bietet eine solide Grundlage, die die Stabilität Ihres Infrastrukturcodes gewährleistet. Dieser Ansatz eignet sich gut für Szenarien, in denen Einfachheit und leichte Verwaltbarkeit im Vordergrund stehen. Mit dem monolithischen Ansatz können alle Verweise auf andere Ressourcen auf native Weise weitergegeben werden, ohne dass Werte in Umgebungsvariablen hart kodiert oder - noch schlimmer - über die verschiedenen Parameter- und Geheimhaltungsspeicher gemeinsam genutzt werden müssen.

Ebenen

Andererseits führt die Entscheidung für mehrere Ebenen eine neue Dimension in IaC-Projekte ein. Dieser Ansatz fördert die Zusammenarbeit, erhöht die Agilität und bietet Flexibilität, um zukünftigen Anforderungen gerecht zu werden. Durch die Verteilung der Verantwortlichkeiten auf mehrere Ebenen kann sich jedes Team auf einen bestimmten Aspekt der Infrastruktur konzentrieren, was die Spezialisierung und Effizienz fördert. Dieser Ansatz ist besonders wertvoll für größere Projekte, bei denen die Komplexität eine modularere und skalierbarere Lösung erfordert. Genau das haben wir im vorherigen Absatz besprochen, oder? Wo liegt also das Problem? In einer Zeit, in der monolithische Ansätze dem verteilten Cloud-Paradigma nicht gut zu stehen scheinen (zu Unrecht, wie dieses Beispiel zeigt), gibt es einen Trend, alles in Teilkomponenten aufzuspalten. Zu diesem Zweck haben viele Teams, die mit Terraform arbeiten, ihre monolithischen Projekte in Schichten aufgeteilt, um die Modularität zu erhöhen. In vielen Fällen verwenden die Teams verschiedene Schichten für ihre Netzwerk-, Rechen-, Datenbank- und Anwendungskomponenten. Es könnten aber auch viel mehr Schichten sein. Diese Schichten ([Unter-]Module?) haben unterschiedliche Zustände und es bestehen Abhängigkeiten zwischen ihnen, die als Verweise auf den weiter oben liegenden Zustand weitergegeben werden. Dies führt zu einer großen Komplexität während des Entwicklungsprozesses. Dies ist zum Beispiel der Fall, wenn Sie eine komplexe Änderung aufgrund einer neuen Funktionsanforderung vornehmen. Eine solche Anfrage könnte fast alle Schichten berühren. Aufgrund der Beschaffenheit der Ebenenstruktur und der Abhängigkeitszuordnung müssen die oberen Ebenen angewendet werden, bevor die unteren Ebenen geplant/angewendet werden können. Andernfalls können Verweise auf den Zustand nicht gefunden werden oder die eigentlichen Komponenten fehlen. Dies führt auch zu einem Problem bei der Durchführung der ersten Bereitstellung, die als Grenzfall behandelt werden muss, was die Bereitstellung in einer völlig neuen Umgebung umständlich macht. Zur Erinnerung: Die ursprüngliche Idee der Schichten war es, nur Komponenten in Schichten aufzuteilen, für die verschiedene Teams verantwortlich sind oder die völlig unterschiedliche Lebenszyklen haben. Und wie sich zeigt, kann eine starke Kopplung von Komponenten zwischen Schichten eine wirklich schlechte Idee sein. All dies erschwert auch den Build- und Deployment-Prozess, der sich mit CI/CD-Tools automatisieren lässt. Wenn Sie jede Schicht anwenden müssen, bevor Sie die nächste planen können, müssen Sie Ihre Änderungen auf mehrere Pull-/Merge-Anfragen aufteilen, wodurch neben dem IaC auch der Entwicklungsprozess fragmentiert wird.

Ein solider Anwendungsfall für die Verwendung von Ebenen

Trotz der oben genannten Punkte gibt es einige Randfälle, in denen der mehrschichtige Ansatz wirklich glänzen kann. Terraform plan and apply kann sehr lange dauern, wenn viele Ressourcenänderungen berechnet oder angewendet werden müssen. Stellen Sie sich eine Situation vor, in der sich Tausende von Ressourcen eines bestimmten Typs auf einmal ändern. Das können Tausende von Buckets oder DNS-Einträgen oder alles andere sein, was mit Terraform verwaltet wird. Wenn (und nur wenn) diese Ressourcen keine Verweise untereinander tragen, können sie in separate Schichten partitioniert werden, wobei ihr Name der Partitionsschlüssel ist. Wenn Sie dies mit den Möglichkeiten bestimmter CI/CD-Tools kombinieren, die die Unterordner mit den Änderungen identifizieren können, muss nur ein Teil der Infrastruktur geplant und angewendet werden, was die Dinge erheblich beschleunigt.

Fazit

Auf der Grundlage der obigen Ausführungen würde ich Ihnen raten, den mehrschichtigen Ansatz in einem einzigen Repository nur mit Vorsicht anzuwenden und nur dann, wenn er für den angestrebten Anwendungsfall viel besser geeignet ist als die alternativen Optionen. Wenn Sie über die Organisation der Infrastruktur in Terraform nachdenken, ist es wichtig, Ihren Ansatz an der Komplexität Ihres Projekts und der Dynamik Ihres Teams auszurichten. Bei einfacheren Projekten, die von einem einzigen Team verwaltet werden, ist die Entscheidung für einen monolithischen Ansatz oft die einfachste Wahl. Er bietet eine solide Grundlage für Stabilität und ermöglicht es, alle Verweise auf Ressourcen nativ zu verarbeiten, ohne dass komplexe Konfigurationen oder die Verwaltung von Umgebungsvariablen erforderlich sind. Im Gegensatz dazu sollten Sie bei größeren und komplexeren Projekten, an denen mehrere Teams beteiligt sind, die Verwendung separater Repositorys in Betracht ziehen, um die Zusammenarbeit, Spezialisierung und Effizienz in den verschiedenen Aspekten der Infrastruktur zu fördern. Letztendlich sollte die Entscheidung zwischen monolithischen und Multi-Repository-Ansätzen auf den einzigartigen Anforderungen Ihres Projekts, der Teamstruktur und den Skalierungszielen basieren. Halten Sie es einfach. Hauptbild von vectorjuice auf Freepik