Platformafhankelijkheden per cloudplatform
Moderne applicaties zijn opgebouwd uit kant-en-klare bouwstenen van een cloudplatform. Elke bouwsteen is een afhankelijkheid. Sommige zijn eenvoudig te vervangen door een alternatief buiten het platform. Andere zijn zo propriëtair dat overzetten neerkomt op herbouwen.
Deze pagina is een referentie bij de inventarisatie voor een exit-strategie: welke platformspecifieke diensten gebruikt een oplossing, en welke daarvan kennen een reëel alternatief? De tabellen zijn geen pleidooi tegen platformdiensten; ze maken afhankelijkheden zichtbaar, zodat de keuze ervoor een bewuste is. De beoordeling per component is indicatief. Hoe dieper een component in de architectuur is verweven, hoe groter de feitelijke afhankelijkheid. De tabellen zijn een momentopname (juli 2026); clouddiensten veranderen.
Microsoft Azure
| Component | Rol in de applicatie | Laag | Alternatief buiten Azure? |
|---|---|---|---|
| Azure App Service | draait de webapplicatie | PaaS | ja, redelijk (container of VM) |
| Azure Functions | losse, eventgedreven code | PaaS | beperkt (bindings zijn propriëtair) |
| Azure SQL Database | relationele database | PaaS | ja (T-SQL is overdraagbaar) |
| Cosmos DB | NoSQL-database | PaaS | beperkt (alleen via compatibiliteits-API’s) |
| Azure Blob Storage | bestandsopslag | PaaS | ja (S3-achtige alternatieven) |
| Azure Service Bus | berichtenwachtrij | PaaS | beperkt |
| Azure Event Grid / Event Hubs | eventdistributie en streaming | PaaS | beperkt |
| Logic Apps | workflows zonder code | PaaS | nee |
| API Management | API-gateway, throttling, keys | PaaS | ja (Kong, NGINX) |
| Azure Key Vault | secrets en certificaten | PaaS | ja (Vault) |
| Microsoft Entra ID | authenticatie en autorisatie | PaaS | ja, maar ingrijpend |
| Azure Virtual Network | netwerktopologie | IaaS | ja |
| Application Gateway / Front Door | loadbalancing, WAF, TLS | IaaS | ja |
| Azure Firewall / NSG’s | netwerkfiltering | IaaS | ja |
| Azure Monitor / Application Insights | logging en telemetrie | PaaS | ja |
| Bicep / ARM-templates | infrastructuurdefinitie | — | nee, Azure-specifiek |
De zwaarste afhankelijkheden zitten in de regel bij Cosmos DB, Logic Apps, Entra ID en Bicep/ARM.
Amazon Web Services (AWS)
| Component | Rol in de applicatie | Laag | Alternatief buiten AWS? |
|---|---|---|---|
| Elastic Beanstalk / App Runner | draait de webapplicatie | PaaS | ja, redelijk (container of VM) |
| AWS Lambda | losse, eventgedreven code | PaaS | beperkt (triggers en integraties zijn propriëtair) |
| Amazon RDS / Aurora | relationele database | PaaS | ja (RDS: standaard engines; Aurora beperkter) |
| DynamoDB | NoSQL-database | PaaS | nee, geen praktisch equivalent |
| Amazon S3 | bestandsopslag | PaaS | ja (de S3-API is de facto standaard) |
| SQS / SNS | berichtenwachtrij en pub/sub | PaaS | beperkt |
| EventBridge / Kinesis | eventdistributie en streaming | PaaS | beperkt (voor Kinesis is Kafka een alternatief) |
| Step Functions | workflows | PaaS | nee |
| API Gateway | API-gateway, throttling, keys | PaaS | ja (Kong, NGINX) |
| Secrets Manager / KMS | secrets en sleutels | PaaS | ja (Vault) |
| IAM / Cognito | authenticatie en autorisatie | PaaS | ja, maar ingrijpend |
| Amazon VPC | netwerktopologie | IaaS | ja |
| ALB / CloudFront | loadbalancing, CDN, TLS | IaaS | ja |
| Security Groups / AWS WAF | netwerkfiltering | IaaS | ja |
| CloudWatch | logging en telemetrie | PaaS | ja |
| CloudFormation / CDK | infrastructuurdefinitie | — | nee, AWS-specifiek |
De zwaarste afhankelijkheden zitten in de regel bij DynamoDB, Step Functions, de Lambda-integraties en CloudFormation/CDK.
Google Cloud
| Component | Rol in de applicatie | Laag | Alternatief buiten Google Cloud? |
|---|---|---|---|
| Cloud Run / App Engine | draait de webapplicatie | PaaS | Cloud Run: ja (containers); App Engine: beperkt |
| Cloud Functions | losse, eventgedreven code | PaaS | beperkt (triggers zijn propriëtair) |
| Cloud SQL | relationele database | PaaS | ja (standaard engines) |
| Firestore / Bigtable / Spanner | NoSQL en gedistribueerde databases | PaaS | nee, geen praktisch equivalent |
| Cloud Storage | bestandsopslag | PaaS | ja (S3-compatibele API) |
| Pub/Sub | berichten en events | PaaS | beperkt (Kafka als alternatief) |
| Workflows | workflows | PaaS | nee |
| Apigee / API Gateway | API-gateway | PaaS | ja (Kong, NGINX) |
| Secret Manager / Cloud KMS | secrets en sleutels | PaaS | ja (Vault) |
| Cloud IAM / Identity Platform | authenticatie en autorisatie | PaaS | ja, maar ingrijpend |
| VPC | netwerktopologie | IaaS | ja |
| Cloud Load Balancing / Cloud CDN | loadbalancing, CDN, TLS | IaaS | ja |
| Cloud Armor / firewallregels | netwerkfiltering | IaaS | ja |
| Cloud Monitoring / Cloud Logging | logging en telemetrie | PaaS | ja |
| Deployment Manager | infrastructuurdefinitie | — | nee, Google Cloud-specifiek |
De zwaarste afhankelijkheden zitten in de regel bij Firestore/Spanner, Workflows en Deployment Manager.
Hoe gebruik je deze tabellen?
- Bij de inventarisatie voor een exit-strategie: welke componenten zijn in gebruik en welke daarvan kennen geen reëel alternatief? Dat bepaalt wat er nodig is om de dienst elders voort te zetten.
- Als ontwerpkeuze: wie binnen één platform bewust kiest voor componenten met een alternatief, bouwt de exit-strategie in de architectuur in. Een platformoverstijgende infrastructuurdefinitie (bijvoorbeeld Terraform) verkleint daarbij de afhankelijkheid van platformspecifieke templates. De onderliggende diensten blijven wel platformgebonden.
- Bij het inrichten van een depot: een depot wordt pas compleet wanneer naast de broncode ook de infrastructuurdefinities, de configuratie en een beschrijving van de gebruikte platformdiensten zijn vastgelegd. Voor oplossingen met zware platformbindingen regelt CloudSecure® de continuïteit van de volledige draaiende clouddienst.
Exit-strategie en digitale soevereiniteit → Cloud escrow of CloudSecure? →