Technical Proof of Concept (PoC)

In der Phase Technical Proof of Concept (PoC) wird aus deiner Architekturplanung Realität. Ziel dieser Phase ist es, eine funktionierende Version deiner Anwendung auf STACKIT zu deployen, um technische Machbarkeit, Performance und Kosteneffizienz zu validieren, bevor du in Richtung Produktionsreife weitergehst.

Deployment-Strategie & Landing Zone

Eine zentrale Entscheidung vor dem Rollout deiner Infrastruktur ist die Festlegung deiner Tenant-Strategie. Sie wirkt sich stark auf deine STACKIT-Organisation-, Folder- und Projektstruktur aus:

• Multitenant-Strategie: Mehrere Kunden teilen sich dieselbe Infrastruktur und Anwendungsinstanz, logisch getrennt.

  

• Customer Dedicated (Single Tenant): Jeder Kunde erhält ein isoliertes STACKIT-Projekt und eine isolierte Infrastrukturumgebung.

  

Beschleunige dein Setup. Um einen schnellen, automatisierten und standardisierten Rollout deiner Cloud-Umgebung zu unterstützen, stellt STACKIT Infrastructure-as-Code (IaC)-Assets bereit:

• Landing Zone Accelerator — Best-Practice-Templates zum Aufbau deiner STACKIT-Umgebung. Dedizierte Landing-Zone-Repositories, speziell zugeschnitten auf die Multitenant- und Customer Dedicated-Modelle, sind geplant: github.com/stackitcloud/stackit-landing-zone
• STACKIT GitHub Repositories — Open-Source-Projekte, Terraform Provider und SDKs: github.com/stackitcloud

Resilienz, Skalierung und Compliance

Beim Bau deines PoC musst du Wachstum, Stabilität und Sicherheit von Anfang an mitdenken:

1. Skalierung: Wie skaliert die Architektur deiner Anwendung, um plötzliches Nutzerwachstum oder erhöhte Auslastung ohne Performance-Einbußen zu bewältigen?
2. Redundanz & Hochverfügbarkeit (HA): Definiere deine Verfügbarkeitsanforderungen. Benötigt deine Anwendung ein Single-Region-Setup, oder brauchst du eine Multi-Region-Architektur, um Ausfälle zu vermeiden?
3. Compliance (TOMs): Mit der Unterzeichnung des Partner Base Agreement (PBA) hat sich deine Organisation technisch zu den Technischen und Organisatorischen Maßnahmen (TOMs) in Annex 2 verpflichtet. Deine PoC-Architektur muss diese Sicherheits- und Datenschutzstandards abbilden und umsetzen.

Architektur-Blueprinting & Zieldesign

Sobald du dein Deployment-Modell, deine Isolationsstrategie und deine Resilienzanforderungen festgelegt hast, überführst du diese Spezifikationen in einen formalen Architektur-Blueprint.

Wenn du deine Software-Komponenten (Microservices, zustandsbehaftete Daten, Caching-Layer, externe Schnittstellen) direkt auf STACKIT-Services abbildest — etwa SKE, PostgreSQL Flex, Object Storage und STACKIT Network Area — entsteht eine klare Zielarchitektur. Dieser Blueprint ist die Grundlage für eine präzise Kostenmodellierung und die anschließende Automatisierung über IaC.

Infrastrukturkalkulation & Kostenverfolgung

Mit deinem definierten Architektur-Blueprint modellierst und verfolgst du deinen Ressourcenverbrauch gegenüber deinen ursprünglichen Business-Case-Schätzungen:

• Computing Calculator — modelliere deinen geschätzten monatlichen Compute-, Netzwerk- und Storage-Bedarf für die Ziel-PoC-Architektur: calculator.stackit.cloud/computing
• STACKIT-Preisliste — Referenz für einen vollständigen Überblick über alle SKUs, da manche neueren Plattform-Services im Calculator noch nicht abgebildet sein könnten.

Mögliche finanzielle Unterstützung & PoC-Credits

Auf Basis deiner Infrastrukturschätzung und des gemeinsamen Geschäftspotenzials können qualifizierte ISVs finanzielle Unterstützung über STACKIT PoC-Infrastruktur-Credits beantragen. Teile deine Calculator-Schätzung mit deinem STACKIT Partner Manager, um zu prüfen, ob es für deine Testphase Förderoptionen gibt.

Infrastructure as Code (IaC) & CI/CD-Pipelines

Für produktionsreife Software solltest du auf manuelle Provisionierung über das Portal verzichten — sie kostet Zuverlässigkeit und erzeugt laufenden Betriebsaufwand. Infrastructure as Code (IaC) ist der Industriestandard für cloud-native Deployments.

Infrastructure as Code

Der Einsatz deklarativer Tools stellt sicher, dass deine Infrastruktur wiederholbar, versionskontrolliert und auditfähig ist:

• Primäres Tooling: Nutze den offiziellen STACKIT Terraform Provider, um Compute, Storage, Netzwerk, SKE (Kubernetes) und Datenbank-Ressourcen zu deklarieren: registry.terraform.io
• Automation-First: Verwalte alle IaC-Skripte in der Versionskontrolle (z. B. GitHub, GitLab, STACKIT GIT).
• STACKIT-Git-Pipelines: Wenn du deine Repositories auf STACKIT Git hostest, laufen die integrierten Pipelines für deine IaC- und Build-Workflows direkt neben dem Code — der First-Steps-Guide führt durch das erste Runner- und Workflow-Setup: docs.stackit.cloud — Pipelines first steps

Empfohlene CI/CD-Pipeline-Architektur

Eine standardisierte Continuous-Integration-/Continuous-Deployment (CI/CD)-Pipeline automatisiert den Lebenszyklus sowohl deiner Infrastruktur als auch deiner Anwendungs-Workloads.

1. Code Commit & Trigger: Änderungen am Anwendungscode oder an IaC-Templates lösen die automatisierte Pipeline aus.
2. Linting & statische Sicherheitsanalyse: Validiere Terraform-Konfigurationen (terraform validate, tflint) und scanne Container-Images auf Schwachstellen — entweder indem du Trivy direkt als Pipeline-Schritt ausführst, oder indem du dich auf die Schwachstellenscans verlässt, die die STACKIT Container Registry bei gepushten Images durchführt. Beides zusammen ergibt sowohl ein Gate in der Pipeline als auch ein fortlaufendes Rescanning bereits gespeicherter Images.
3. Infrastruktur-Provisionierung (IaC-Schritt): Führe terraform plan zur automatisierten Verifikation aus, gefolgt von terraform apply, um STACKIT-Ressourcen in der Ziel-PoC-Umgebung zu provisionieren oder zu aktualisieren.
4. Workload-Deployment: Deploye Anwendungscontainer auf die STACKIT Kubernetes Engine (SKE) mit Helm als Paketierungsformat — entweder pipeline-gesteuert über den Terraform Helm Provider (Infrastruktur und Workload bleiben in einem deklarativen Lauf) oder pull-basiert über eine GitOps-Engine wie Argo CD oder Flux, die den Chart aus deinem Git-Repository abgleicht. Vermeide imperative kubectl apply-Schritte, da sie keinen abgleichbaren Sollzustand hinterlassen. PaaS-Anwendungen werden über Cloud Foundry (cf push) deployt.
5. Automatisierte Integrationstests: Führe Smoke-Tests gegen die frisch deployten Endpunkte aus, um die Verfügbarkeit der Services zu prüfen.
6. Secrets Management: Stelle sicher, dass Pipeline-Runner über kurzlebige API-Tokens oder die Integration mit dem STACKIT Secrets Manager auf STACKIT-Service-Accounts zugreifen — hinterlege niemals API-Keys oder Zugangsdaten fest im Repository.
7. STACKIT Container Registry: Zentrale Registry für deine Build-Artefakte, inklusive Schwachstellenscans gepushter Images: docs.stackit.cloud — Container Registry

Abschlusskriterien der Phase

Die PoC-Phase ist abgeschlossen, wenn folgende Punkte bestätigt sind:

• Ziel-Architektur-Blueprint erstellt und auf STACKIT-Services gemappt.
• Anwendung erfolgreich im STACKIT-PoC-Projekt deployt und lauffähig.
• Infrastruktur-Provisionierung mittels IaC automatisiert (z. B. Terraform / Landing Zone Accelerator).
• Tenant-Isolationsstrategie (Multitenant oder Customer Dedicated) in der Folder-/Projekthierarchie umgesetzt.
• PoC-Umgebungskosten berechnet und mit dem Partner Manager besprochen.
• Automatisierte CI/CD-Deployment-Pipeline eingerichtet.
• Sicherheits- und Compliance-Kontrollen (PBA Annex 2 TOMs) technisch validiert.
• Meilenstein erreicht: PoC validiert — bereit für das ES³ Self Assessment.

Support & Kontakt

Nutze während der PoC-Phase folgende Ressourcen zur Unterstützung deiner Entwicklung:

• STACKIT Knowledge Base — technische Dokumentation, API-Referenzen und praktische Tutorials: docs.stackit.cloud
• STACKIT Status Page — Echtzeitinformationen zur Plattformverfügbarkeit und Systemwartungen: status.stackit.cloud

Brauchst du Unterstützung? Wenn du während deines PoC auf technische Blocker stößt, kontaktiere deinen Partner Manager oder das ISV-Factory-Team unter isv-sales@digits.schwarz.