Cloud-onafhankelijkheid begint bij je bouwstenen
De vrijheid om van provider te wisselen zit niet in wélke cloud je kiest, maar in waaróp je bouwt.
Onze eigen build-infrastructuur is in een paar jaar drie keer verhuisd: van Google naar Amazon, van Amazon naar DigitalOcean, en onlangs naar het Europese Scaleway. Elke verhuizing kostte dagen. Niet omdat we zo snel zijn, maar omdat we geen enkele provider ooit z’n haken in onze stack hebben laten zetten.
Dat blijkt opeens veel waard. Sinds een uitspraak van het Amerikaanse hooggerechtshof staat de EU-VS-dataoverdracht weer op losse schroeven, en de vraag “waar staat onze data, en hoe snel kunnen we weg?” is van theoretisch naar urgent gegaan. Toen we laatst bij een grote publieke opdrachtgever voorstelden om naar een Europese provider te verhuizen, kregen we “ja” nog voordat we het probleem hadden uitgelegd. Aan de pitch kwamen we niet eens toe.
Want de meeste organisaties zitten niet vast aan een cloud. Ze zitten vast aan de proprietary diensten die ze erbovenop hebben gebouwd. En precies daar zit het verschil tussen een verhuizing van dagen en een van maanden.
De keuze is niet “zelf hosten of de cloud in”
Dat is het grootste misverstand. Elke serieuze provider levert managed services: je hoeft niks zelf te beheren. De echte keuze is: neem je de provider-eigen dienst, of de standaard dienst die overal draait? Je houdt het gemak van managed; je kiest alleen de portable variant.
Compute. Kubernetes draait overal: Amazon (EKS), Google (GKE), Azure (AKS) én bij vrijwel elke kleinere provider, allemaal managed. Kies je in plaats daarvan Amazon’s ECS of Azure’s ACS, dan schrijf je je applicatie vast aan die ene leverancier. Iedereen heeft Kubernetes; alleen Microsoft heeft ACS.
Database. PostgreSQL en MySQL krijg je bij iedereen, managed. Kies je Amazon Aurora, dan zit je aan Amazon vast. En zit je nu op Oracle of MS SQL, dan klinkt “migreren naar Postgres” misschien als een schrikbeeld en zie je de migratiekosten al voor je. Maar met een fatsoenlijke datalaag (Spring Data, Hibernate, jOOQ) valt dat enorm mee. Wij verhuisden een klant van MS SQL naar MySQL in een paar dagen, simpelweg omdat alles op JPQL draaide en gewoon bleef werken. Bij een andere klant draaiden oude applicaties op Oracle in productie, maar op een goedkopere database in test. Dezelfde code, een andere database eronder.
Storage. De S3-API is van oorsprong een Amazon-standaard, maar zo breed overgenomen dat ‘ie de facto standaard is geworden: Scaleway, MinIO, Cloudflare, Backblaze spreken ‘m allemaal. Eén code-pad, vele providers. Google en Azure doen bewust niet mee: die hebben hun eigen opslag-standaard, en daar zit je dan aan vast.
En dit zijn nog maar de drie zichtbare lagen
De meeste teams consumeren óók IAM, observability, messaging, search, caching en application firewalls rechtstreeks van hun provider. Stuk voor stuk plekken waar je je opnieuw kunt vastbouwen, of juist voor een standaard kunt kiezen: Elastic/OpenSearch, Redis/Valkey, MongoDB, Kafka, ClickHouse. Voor elk daarvan bestaat een portable, managed variant die je bij meerdere providers krijgt. Sommige providers laten je zelfs eigen LLM’s draaien tegen pay-per-use. Ook je AI-laag hoeft geen lock-in te zijn.
Wat lever je in?
Eén ding: de specifieke extra’s van een provider-eigen dienst, zoals de slimme auto-scaling van Aurora of díe ene integratie die alleen bij die hyperscaler zit. Voor sommige teams weegt dat op tegen de vrijheid, en dat is een legitieme keuze, zolang je ‘m bewust maakt. Wat je met de standaard-variant er gratis bij krijgt: je kunt Kubernetes, PostgreSQL en de rest desnoods óók zelf draaien. Een provider-eigen dienst nooit.
Waarom onze verhuizingen dagen kostten
Terug naar onze eigen infrastructuur. Die begon bij Google. Na een maand of twee besloten we te consolideren naar Amazon, tot de eerste volle maandrekening van Amazon binnenkwam, waarna we naar DigitalOcean verhuisden. En nu dus naar Scaleway. Drie migraties, elke keer een kwestie van dagen. Niet omdat verhuizen makkelijk is, maar omdat er nooit iets in onze stack zat dat aan één provider vastzat.
Hoe die laatste verhuizing naar Scaleway er precies uitzag, en waarom een Europese provider nu extra logisch is, lees je in de volgende blog.
Benieuwd hoe portable jouw stack eigenlijk is? Kun je binnen een week weg bij je provider? We denken er graag een keer vrijblijvend over mee. → Neem contact op
Nieuwsgierig of maatwerk voor jou het verschil kan maken?
Neem contact met ons op voor maatwerkoplossingen in Java, geleverd door een ervaren team dat stabiliteit, continuïteit en optimalisatie garandeert voor jouw bedrijfsprojecten.