Waarom ik bouw zoals ik bouw.

Mijn eerste project was een migratieproject naar een nieuw platform. Ik leerde snel wat het effect is van zogenaamde vendor lock-in: het verweven zijn van je basisinfrastructuur met één grote provider. Door het gebruik van providerspecifieke tools is het niet zomaar mogelijk om je spullen te pakken en te gaan. Het hele systeem moet ontweven worden. De eerste jaren is dit vaak geen probleem, maar door de snel veranderende wereld kun je opeens op verouderde technologie zitten. Migraties kunnen pijnlijk zijn, jarenlang duren en ongelofelijk duur uitpakken.

Een tool kan op papier aan alle voorwaarden voldoen en goed onderbouwd worden door consultancypartijen, maar mist vaak de realiteit waar een engineer mee te maken krijgt. Op dat niveau spelen andere belangen, die niet altijd stroken met hoe gebruikers, ontwikkelaars en zelfs de architecten van het platform er in de praktijk mee omgaan.

Enkele jaren geleden was er geen alternatief, maar inmiddels is er ongelofelijk veel gebouwd in het open source-gebied, en worden steeds meer standaarden opgepikt door gevestigde partijen. Ontwikkelingen gaan stap voor stap, maar het is duidelijk waar het heen gaat: open standaarden, werkbaar en inwisselbaar.

De weg gaat van bedrijfsspecifieke software naar modules die toegevoegd of verwijderd kunnen worden, afhankelijk van de behoefte van het bedrijf. De voordelen zijn duidelijk: ontwikkelaars convergeren steeds meer naar dezelfde open tools, waardoor het makkelijker wordt om geschikte expertise te vinden. En doordat het open source is, blijft software gegarandeerd jarenlang stabiel en onderhouden.

Ik probeer deze ontwikkeling tot zijn conclusie door te trekken. Bouwstenen van een data-infrastructuur moeten simpel zijn in gebruik en makkelijk te verwisselen. Elk onderdeel van het platform moet binnen een dag gemigreerd kunnen worden.