Ontwerpkeuze
Een beperkt aanbod met een groeipad
Rust op Twaalf dragende ontwerpkeuzes. Bevestigd door vdo89 op 26 september 2026. Bron in de atlas
- Vraag
- Waarom beginnen met clusters en databases?
- Leidend
- nee
Principes
Standaardiseer wat generiek is; hergebruik vóór kopen vóór maken; voorkom onnodige complexiteit; nieuwe diensten zoals een ontwikkelaarsportaal en AI.
Waarom niet eenvoudiger
Alleen virtuele servers leveren laat het samenstellen aan de teams over; alles tegelijk bouwen geeft varianten zonder beproefde basis.
Wat het oplevert
Clusters als dienst en beheerde databases beproeven samen de gemeenschappelijke basis: clusterbesturing, rekenkracht, gegevens, toegang en beheer. Latere diensten gebruiken diezelfde basis.
Wat het vraagt
Niet elke dienst is meteen beschikbaar. AI, virtuele servers en lichtere uitvoervormen volgen volgens de groeipadstappen en hun gereedcriteria.
- Lost op
- Uitgewerkt in
Onderwerpen die eruit volgen
De beheerde database als dienst
PostgreSQL met CloudNativePG als dienst in het applicatiecluster van het team, in een afgeschermd deel dat het platform beheert: waar de database staat, hoe zij uit sjabloon en dienstbeschrijving ontstaat, wie wat doet en hoe de dienst groeit.
Opgave en reikwijdte
Waarom RWS een gemeenschappelijk platform bouwt, wat binnen de reikwijdte valt en hoe wordt bepaald waar een toepassing draait, met het rijksbrede cloudbeleid als eerste kader.
Architectuurprincipes
De architectuurprincipes van RWS en de overheid waaraan het platform is getoetst, per bron en met hoe het platform ieder principe verwerkt, en de afwegingen waar principes met elkaar schuren.
De clusterdefinitie
Hoe een applicatiecluster uit de dienstbeschrijving ontstaat: het sjabloon met weinig keuzes, de onveranderbare velden, de koppeling met de werkervirtualisatie, de werkernetwerken en de route naar de opslag.
Exemplaren, overname en dienstniveaus
Bij ontwikkelen en beproeven heeft een database één exemplaar, in reguliere productie drie op verschillende werkers met automatische overname en uitsluiting van het oude schrijvende exemplaar. Met de dienstniveaus per profiel, de opslag, het gedrag bij uitval en de capaciteit in het quotum van het team.
Het vlootoverzicht
Het vlootbeheer haalt van alle clusters een vaste selectie samengevatte metingen op voor één overzicht van beschikbaarheid, capaciteit en gezondheid. Het overzicht is een aanvulling: valt het uit, dan werken de meldingen per cluster door.
Virtuele werkers en virtuele servers
Wat de werkervirtualisatie per applicatiecluster en per afnemer draagt: de infra-naamruimte, de virtuele werkers en hun maten, de beelden, de opslag, de virtuele servers als dienst, fysieke werkers en GPU-knooppunten.
Wat de samenhang oplevert
Het aanbod is gericht op gedeelde behoeften van teams; de winst zit in de samenhang tussen de voorzieningen, van minder overdrachten tot gezamenlijk onderhoud.
Catalogus en dienstsjablonen
De catalogus biedt teams gepubliceerde diensten met varianten, afspraken per profiel en documentatie. Iedere dienst en ieder sjabloon heeft een eigenaar en een versie; het aanbod groeit langs het groeipad.
Dienstverlening
Eén dienstbeschrijving stuurt levering en beheer over de hele levensduur van een dienst; een team combineert uit het aanbod wat het nodig heeft en kiest een dienstprofiel voor gebruik en continuïteit.
Netwerkbeleid en uitgaand verkeer
Binnen een cluster gaat het beleid van het platform vóór dat van het team: verkeer tussen naamruimten en afnemers is standaard geweigerd en uitgaand verkeer mag alleen naar vastgelegde bestemmingen. Daarbij horen de netwerkvarianten die een team kan kiezen en de weg naar een dienstennetwerk.
Invoering en overgang
Het platform wordt ingevoerd langs een groeipad in vier stappen: eerst één complete levering, dan uitval en aanval beproeven, dan herhalen en uitbreiden, met de afbouw van het oude als deel van de overgang.
Versies, onderhoud en levenscyclus
Welke versies de dienst gebruikt, hoe nieuwe versies via de toelatingsroute en uitrolgolven binnenkomen, hoe een nieuwe hoofdversie overgaat, en wat er gebeurt als de leverancier de stapel niet ondersteunt.
Beheer, uitval en herstel van de keten
Platformbeheer beheert de keten met smalle technische identiteiten. Uitval van een vlootbreed deel stopt alleen nieuwe vrijgaven; de keten komt terug uit code en herstelkern, en wordt bewaakt, beproefd en langs het groeipad opgebouwd.
De eerste levering door het ontwikkelteam
Hoe het ontwikkelteam de eerste levering bouwt en overdraagbaar maakt: wie waarover beslist, welke werkafspraken gelden, in welke omgevingen wordt gewerkt, hoe namen en versiebeheer zijn opgebouwd en hoe een nieuw team start.
Levenscyclus van een applicatiecluster
Van levering tot beëindiging: hoe een applicatiecluster in gebruik gaat, hoe het wordt bijgewerkt, wat per profiel wordt geleverd, hoe het aanbod gefaseerd groeit en wie welke taak heeft.
Uitrol, beproeving en fasering
Hoe platformwijzigingen cel voor cel worden uitgerold, welke omgevingen er naast productie zijn, wat vóór de ingebruikname van een cel wordt beproefd, welke draaiboeken en taken er zijn, en hoe de samenstelling langs het groeipad groeit.
Beproeving en oplevering
Hoe de eerste levering wordt geaccepteerd en aan platformbeheer overgedragen, met welke maatstaven de voortgang wordt gevolgd en hoe de aandachtspunten voor de uitbreiding worden beheerst.