Bei cloudbasierten Softwareprojekten sollten mehrere Umgebungen zum Einsatz kommen. Diese Umgebungen haben normalerweise Namen wie dev
, qa
, staging
und prod
.
Es ist wichtig, dass diese Umgebungen vollständig voneinander getrennt sind. In der Regel haben sie auch sehr unterschiedliche Bedienerzugriffsberechtigungen.
Das Entwicklungsteam kann beispielsweise vollen Zugriff auf die dev
-Umgebung haben, aber nur eingeschränkten Zugriff auf die prod
-Umgebung. Alle Code-Deployments erfolgen dann nur über automatisierte Skripts. Außerdem müssen die Daten in den verschiedenen Umgebungen unbedingt voneinander getrennt bleiben.
Durch Nutzung mehrerer Google Cloud-Projekte werden diese Anforderungen perfekt erfüllt. Die Projekte bieten eine komplette Isolierung von Code sowie Daten und die Bedienerberechtigungen können getrennt verwaltet werden. Da App Engine die Bereitstellungsinstanzen automatisch skaliert, zahlen Sie nur für das, was Sie auch nutzen. Ein Beispiel: Wenn Ihre Staging-Umgebung immer nur eine von vier Wochen benötigt wird, bezahlen Sie in den übrigen drei Wochen nicht für eine Bereitstellungsinstanz. Beachten Sie jedoch, dass Ihnen in diesen Projekten gespeicherte Daten in Rechnung gestellt werden.
Umgebungen benennen
Wenn Sie Ihre Mikrodienstanwendung ausschließlich mit mehreren Diensten erstellen, können Sie für jede Umgebung ein eigenes Google Cloud-Projekt anlegen und die Umgebungen entsprechend benennen, z. B. web-app-dev
, web-app-qa
und web-app-prod
.
Wenn Sie Ihre Mikrodienstanwendung dagegen mit mehreren Projekten erstellen, können Sie die gleiche Trennung zwischen den Umgebungen erreichen, benötigen dafür jedoch mehr Projekte, z. B. web-app-dev
, web-app-prod
, user-service-dev
und user-service-prod
.
Sie müssen Codemuster verwenden, um dafür zu sorgen, dass die dev
-Projekte nur andere dev
-Projekte aufrufen und die prod
-Projekte nur andere prod
-Projekte aufrufen.
Nächste Schritte
- Überblick über die Mikrodienst-Architektur in App Engine
- Best Practices für den Entwurf von APIs zur Kommunikation zwischen Mikrodiensten
- Best Practices für leistungsfähige Mikrodienste
- Von einer monolithischen Anwendung auf Mikrodienste migrieren