In Fase 1 hebben we de voordeur op orde gebracht: wie er binnenkomt. Fase 2 gaat over wat er achter die deur zit. Hoe richt je het platform zo in dat teams vrij kunnen werken, terwijl een fout in ontwikkeling nooit productie kan raken?

In Databricks begint dat bij workspaces. Een workspace is de omgeving waar mensen code schrijven, jobs draaien en dashboards bouwen. Hoeveel je er hebt, en wat je in elke workspace zet, bepaalt hoe goed je teams en omgevingen van elkaar gescheiden zijn.

De vraag voor de directie

Kan een fout in ontwikkeling ooit productiedata raken?

Is het eerlijke antwoord “dat hangt af van wie er is ingelogd”, dan zijn je omgevingen alleen in naam gescheiden. Dat is een risico voor de datakwaliteit, voor compliance, en voor het vertrouwen dat het bedrijf in zijn rapportages heeft.

Waar het misgaat

We zien twee uitersten, en één valkuil die op een oplossing lijkt.

  • Alles in één workspace. Het begint als pilot en groeit door. Experimenten, ad-hocanalyses en productiepipelines komen naast elkaar te staan, met dezelfde clusters en dezelfde rechten.
  • Een nieuwe workspace voor elk team of project. Het voelt als een nette scheiding, maar na een jaar zijn er tientallen omgevingen met verschillende instellingen, zonder duidelijke eigenaar en met kosten die niemand kan verklaren.
  • Scheiding alleen in naam. Er is een dev- en een prod-workspace, maar beide kunnen dezelfde productiedata lezen en schrijven. De muren staan er, maar de deuren staan open.

Vijf bouwstenen

De workspace-richtlijnen van Databricks zelf wijzen naar hetzelfde patroon dat wij bij klanten inrichten.

1. Ontwikkeling, test en productie apart

Ontwikkeling en productie krijgen minimaal elk een eigen workspace, vaak met een test- of acceptatieomgeving ertussen. Nieuwe code en nieuwe instellingen worden eerst bewezen voordat ze productie bereiken.

2. Alleen splitsen met een echte reden

Een nieuwe workspace heeft een reden nodig die je niet op een andere manier kunt oplossen: sterk gereguleerde data met eigen controles, een regio waar data moet blijven, of een bedrijfsonderdeel dat volledig gescheiden moet zijn. Databricks raadt expliciet af om workspaces aan te maken voor losse teams of kleine projecten.

3. Catalogs voor teams, geen workspaces

Teams delen een workspace en krijgen een eigen catalog of schema in Unity Catalog. Zo heeft elk team zijn eigen ruimte voor data, zonder dat omgevingen, instellingen en kosten zich vermenigvuldigen.

4. Data gekoppeld aan zijn omgeving

Met workspace-catalog binding is een productiecatalog alleen bereikbaar vanuit de productie-workspace. Zelfs een gebruiker met de juiste rechten kan vanuit een ontwikkel-workspace niet bij productiedata.

5. Aangemaakt vanuit code, benoemd volgens vaste regels

Workspaces worden uitgerold via automatisering, zoals Terraform, met duidelijke naamconventies. Elke workspace is reproduceerbaar en heeft een eigenaar, en niemand maakt er een aan met een klik in een console. We komen hierop terug in Fase 7, Infrastructure as Code.

Vier checks voor je directieteam

Je hoeft het platform niet te openen om te weten of deze fase op orde is. Stel deze vier vragen:

  • Kan ontwikkeling bij productiedata?
  • Heeft elke workspace een eigenaar en een reden van bestaan?
  • Krijgt een nieuw team een catalog, of een nieuwe workspace?
  • Worden workspaces aangemaakt vanuit code, of met de hand?

Zijn de antwoorden nee, ja, een catalog en vanuit code, dan zijn je omgevingen goed gescheiden.

Volgende: Fase 3, Unity Catalog

Staan identiteiten en workspaces, dan is de volgende vraag wie welke data ziet, tot op tabel- en kolomniveau. Dat is Fase 3.

Dit artikel hoort bij onze serie Databricks in productie. Wil je weten waar je platform staat? Neem contact op met Ferdinand via LinkedIn.