Ontwerpkeuze
Eén beschrijving per toepassing, die het platform uitvoert en bijhoudt
Rust op Twaalf dragende ontwerpkeuzes. Bevestigd door vdo89 op 26 september 2026. Bron in de atlas
- Vraag
- Wie houdt losse onderdelen op elkaar afgestemd?
- Leidend
- nee
Principes
Stuur digitaal werk declaratief; automatiseer van wijziging tot productie; houd wijzigingen gecontroleerd en reproduceerbaar; beschrijf de dienst nauwkeurig.
Waarom niet eenvoudiger
Een betere aanvraagroute verkort het invullen, niet de overdrachten. Een los script per team herhaalt de levering, maar bewaakt daarna niet vanzelf of de omgeving nog klopt.
Wat het oplevert
De goedgekeurde beschrijving verbindt cluster, database, netwerk en identiteit. Uitvoerende voorzieningen vergelijken de werkelijke toestand met die gewenste inrichting.
Wat het vraagt
De standaard, versies en uitzonderingen moeten zelf worden beheerd. Een noodmaatregel krijgt een einddatum en een expliciete tijdelijke opschorting van automatisch herstel.
- 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.
Het vaste leverpad
Iedere levering doorloopt dezelfde acht stappen, van beschrijven tot overdragen, met een normtijd per stap en één leverstatus in versiebeheer. Een stap is pas gereed als het onderdeel werkt; een onvolledige levering blijft zichtbaar en wordt zonder dubbele onderdelen hervat.
Signalering en meldingen
Ieder cluster bewaakt zichzelf en meldt rechtstreeks aan de verantwoordelijke; het vlootbeheer meldt alleen wat van buitenaf moet worden vastgesteld. Drempels, normtijden en reactietijden per dienstprofiel bepalen wanneer en bij wie een melding aankomt.
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.
Back-up per laag
Ieder onderdeel heeft een eigen back-up, zodat het consistent terug te zetten is: clusterobjecten en volumes, configuratiedatabases van besturingen, databases, geheimenbeheer, containerregistry en versiebeheer. Schema’s, buckets, meldingen en de softwarestapel liggen daarvoor vast.
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.
Dienstbeschrijving en toetsing
De dienstbeschrijving is de enige invoer van een team. Een toetspijplijn in de opslagplaats Afnemers toetst ieder voorstel, langs iedere ingang, aan de geldende regels: rol, velden, capaciteit, zones en instemming.
Uitrol van de gewenste inrichting
Het vlootbeheer rolt alleen ondertekende, beoordeelde inrichting uit Platform en Beleid uit, met één Argo CD in het pushmodel, begrensde projecten en identiteiten, en zet afwijkingen terug.
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.
Beleid en uitrolgolven
Beleid gaat eerst op melden en pas na een geslaagde proef per golf op afdwingen. Iedere wijziging en platformversie begint in de leeromgeving en de proefgroep en bereikt cel 1 vóór cel 2.
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.
Fysieke basis
Geregistreerde apparatuur op een vaste basislijn, gescheiden netwerken en één gecontroleerde route voor software, vastgelegd vóór de installatie van software, met de maatregelen voor apparatuur, fysieke toegang en tijd.
Inventaris en cryptografieoverzicht
De inventaris combineert de bestaande registraties tot één overzicht per dienst, met eigenaar, versies en einddatums, zodat iedere melding herleidbaar is tot dienst en eigenaar. Het cryptografieoverzicht legt per dienst en per pad vast welke cryptografie wordt gebruikt.
Wijzigen, bijwerken en beëindigen
Een wijziging is een nieuwe levering langs hetzelfde pad, en bijwerken levert een nieuwe versie in versiebeheer op die gespreid wordt uitgerold: eerst de proefgroep, dan in golven. Beëindigen loopt via de toestand in de dienstbeschrijving.
Wijziging, versies en draaiboeken
Hoe het basisdienstencluster en zijn basisdiensten alleen via code en beoordeelde wijzigingen veranderen, welke productversies gelden, in welke volgorde nieuwe versies uitrollen en welke draaiboeken beproefd moeten zijn.
Beheer, meting en herstel van het leverpad
Portaal, toetsing en leverwerkstroom komen uit code en versiebeheer en zijn opnieuw op te bouwen. Uitval stopt nieuwe leveringen maar geen draaiende toepassing, en iedere levering wordt gemeten tegen de nulmeting.
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.
Wat voor ieder onderdeel geldt
De regels die ieder onderdeel van het platform volgt: inrichting uit code, zelfstandig per cel, toegang op identiteit, alleen vrijgegeven software, logboeken naar het SOC, ondersteunde versies, beproefde draaiboeken en één eindverantwoordelijke.
Inrichting, netwerk en beproeving
Hoe de bewaking zelf wordt ingericht, verbonden, beschermd en beproefd: als code in de standaardinrichting, met een vastgelegde softwarestapel, vaste stromen in de zonematrix, een foutdomeinmodel, een taakverdeling, draaiboeken en een bewijsset per fase.