Wat we ermee bouwen
Google Cloud is waar de containers die we bouwen daadwerkelijk ergens kunnen draaien. Beheerde Kubernetes, objectopslag, beheerde databases, loadbalancing en TLS-terminatie, plus de identiteits- en netwerklaag eromheen.
De reden om een beheerd platform te gebruiken is niet dat het per CPU goedkoper is — vaak is het dat niet. Het is dat upgrades van de control plane, certificaatrotatie en het patchen van nodes ophouden iemands taak te zijn. In een klein team is dat het verschil tussen infrastructuur als achtergrondzorg en infrastructuur als een persoon.
Waar het past
Onder het uitrolverhaal: containers gebouwd in CI, verpakt met Helm, toegepast op een beheerd cluster. De applicatiecode blijft overdraagbaar — niets erin weet op welke cloud hij staat, en dat is met opzet.
Wanneer we het aanraden
Voor producten die een echt cluster, autoscaling of beheerde datadiensten nodig hebben, en voor teams die de niet-onderscheidende delen van servers draaien liever niet in eigen beheer hebben.
We zijn niet dogmatisch over welke cloud. Het ontwerp waar we naar streven is er een waarin de keuze omkeerbaar is: containers, Kubernetes en Helm zijn overdraagbaar, dus een verhuizing is een migratie van beheerde diensten en geen herbouw. Zit je al bij een andere aanbieder, of wijzen je compliance-eisen ergens specifieks heen, dan is dat meestal het sterkere argument.
Voor één kleine service met gelijkmatig verkeer is een cluster van welke soort dan ook meer dan de klus vraagt — een beheerde containerruntime is minder om te beheren en minder om fout te doen.
