Nadenken over mail, identity en samenwerking

De afgelopen maanden ben ik naast mijn dagelijkse werk weer eens iets “voor mezelf” gaan bouwen. Geen hobbyproject in de klassieke zin, maar ook geen concreet plan om iets te vervangen. Meer een exercitie in begrijpen.

Dit artikel is een introductie op dat project, dat ik voorlopig Mprjv65 noem.

Achtergrond

Ik werk inmiddels ruim 25 jaar in het onderwijs, grotendeels als systeem- en netwerkbeheerder bij een scholengemeenschap in Hoorn. In die periode heb ik meerdere generaties IT‑landschappen zien komen en gaan.

Waar we vroeger 19”‑rekken vol servers hadden staan – voor mail, bestanden, applicaties en virtuele werkplekken – zijn we inmiddels een cloud‑first organisatie geworden. Diensten die ooit lokaal draaiden, functioneren nu als SaaS of worden ergens in de cloud gehost. Dat heeft veel voordelen: minder fysieke afhankelijkheden, schaalbaarheid en minder operationele ruis.

Laat ik duidelijk zijn: dit artikel – en dit project – is geen afrekening met die ontwikkeling. Microsoft 365 werkt in de dagelijkse praktijk uitstekend en lost veel concrete problemen op.

Maar juist doordat zoveel complexiteit tegenwoordig wordt geabstraheerd, ontstaat op termijn een ander soort vraag.

Wat als…?

Wat als bepaalde diensten (tijdelijk) niet beschikbaar zijn?
Wat als wetgeving of beleid andere eisen gaat stellen?
Wat als je écht wilt begrijpen wat er onder die abstraherende lagen gebeurt?

Niet vanuit wantrouwen, maar vanuit vakmatige nieuwsgierigheid en professionele verantwoordelijkheid.
Ik wil niet overvallen worden door een vraag die ik alleen ad‑hoc kan beantwoorden, zonder echt te begrijpen wat er onder de motorkap gebeurt.

Die vragen vormden de aanleiding voor Mprjv65.

Twee doelen, één project

Het project heeft bewust een tweeledig doel.

Aan de ene kant wil ik beter begrijpen hoe een modern cloudplatform functioneel is opgebouwd. Niet op productniveau (“dit lijkt op Outlook”), maar op architectuurniveau: welke bouwstenen zijn er, wat doen ze, waar liggen de grenzen en waar ontstaan afhankelijkheden?

Aan de andere kant gebruik ik dit project om mijn ervaring met containers en container‑orchestratie te verdiepen. Technologieën als Docker en Kubernetes zijn inmiddels gemeengoed, maar echt begrip ontstaat pas wanneer je zelf keuzes moet maken over schaalbaarheid, redundantie en falen.

Door beide doelen te combineren ontstaat een leeromgeving die dicht bij de praktijk ligt, zonder dat er meteen productie‑eisen of organisatorische druk achter zit.

Geen vervanging, maar begrip

Mprjv65 is nadrukkelijk geen poging om Microsoft 365 één‑op‑één na te bouwen. Dat zou zinloos zijn – en eerlijk gezegd ook niet wenselijk.

Het doel is anders:
begrijpen hoe een samenwerkingsplatform is opgebouwd, door de afzonderlijke lagen weer expliciet te maken én zelf te beheren.

Dat betekent onder andere: - mail en filtering als losse diensten - identity en authenticatie als fundament, niet als bijzaak - samenwerking en bestanden als applicatielaag - containers als uitvoeringsvorm, niet als doel op zich

Door die onderdelen zelf te combineren, wordt zichtbaar welke problemen door een platform worden opgelost — en welke simpelweg verborgen worden.

Bewust klassiek, waar dat logisch is

Sommige technologieën zijn al decennia oud – mail is daar het bekendste voorbeeld van. SMTP en IMAP zijn fundamenteel anders ontworpen dan moderne cloud‑diensten, en dat merk je direct zodra je ze opnieuw inzet.

In plaats van die verschillen weg te poetsen, kies ik er in dit project juist voor om ze serieus te nemen. Klassiek waar het moet, modern waar het kan.

Dat betekent ook dat niet alles “cloud‑native” hoeft te zijn om zinvol of robuust te zijn.

Cloud‑agnostisch, maar niet naïef

Waar het platform uiteindelijk draait, is voor dit project bewust van ondergeschikt belang. Azure, een Europese cloud of eigen infrastructuur: het ontwerp moet overdraagbaar zijn. In de praktijk draait dit platform voorlopig op bescheiden infrastructuur; de precieze opzet licht ik in een later artikel toe.

Niet omdat alles overal moet kunnen draaien, maar omdat afhankelijkheid zonder begrip ongemakkelijk voelt.

Containers en Kubernetes zijn daarbij geen doel, maar een middel om dat overdraagbare ontwerp tastbaar te maken. Het past echter heel mooi in de evolutie die ik meegemaakt heb: van alles op ijzer naar we gaan virtualiseren en dan nu containers en Kubernetes.

Wat volgt

In de komende artikelen ga ik dieper in op onderwerpen zoals: - mailarchitectuur en filtering - identity en SSO buiten grote SaaS‑platformen - de rol van containers en orkestratie - en wat er gebeurt als onderdelen falen of veranderen

Dit is geen handleiding en geen blauwdruk. Het is een denk‑ en leerproces, hardop opgeschreven. Ik ga je hier niet vertellen hoe jij jouw cloudplatform zou moeten inrichten; dit zijn mijn gedachten, keuzes en overwegingen bij mijn eigen implementatie.

Mprjv65 is daarmee vooral een persoonlijk referentiekader — bedoeld om inzicht te krijgen vóórdat het nodig is, niet pas op het moment dat er antwoorden verwacht worden.