De grote serververhuizing - Dag True, hallo Exonet! - Tweakers-vlog #20

NodeJS geloof ik ook zo? Van PHP composer weet ik het niet.

Die hebben beide lock files waar de exacte versies in staan die zijn gebruikt, op basis waarvan je in je pipeline achteraf dezelfde versies kan bouwen. Dat is dus wel aardig geregeld.

Oke, jij hebt gewoon een governance issue en niet per se issues met dependencies. Van wat je nu schetst kun je lezen dat je lifecycle- en dependency management duidelijk beter moeten om dit soort zaken te kunnen doen. Jij ziet variatie als probleem, maar stipt vervolgens alleen issues aan waar je governance gewoon niet voldoende blijkt.

3x zoveel verschillende talen, betekent 3x zoveel verschillende frameworks en libraries, met 3x zoveel mogelijke kansen dat er ergens een breaking change wordt doorgevoerd.

Maar ook 1/3e kans dat 1 groot issue je hele bedrijfsvoering platlegt . Moderne organisaties werken met polyglot architecturen. "The right tool for the job". Hier zie je juist vaak dat er een aantal talen zijn (die ook redelijk gestandaardiseerd blijven hoor) waar dan uit "gekozen" kan worden. Dus bijvoorbeeld Go voor high concurrency, Python voor data, Java of .NET for backend services. Bedrijven standaardiseren dan juist op platformen met duidelijke boundaries en vaak per domein.

Ik vind dit altijd een van de vervelendste zaken van backend ontwikkeling. "Het stond in de changelog". Dat zal, maar die moet dan wel gelezen zijn.

Tsja. Als je je lifceycle management niet op orde hebt dan maakt het niet heel veel uit of je nu 1 of 5 talen gebruikt. Als je dan dergelijke fouten hebt, heb je dan je tests wel op orde?

Als "het staat in de changelog" een valide reden is, is de kans groot dat je spul niet eens meer compileert of bouwt. Dus wat ben je dan aan het doen?

Je verwart complexiteit met onbeheersbaarheid. Breaking changes zijn geen probleem als je:

• dependencies pinned
• CI/CD + tests hebt
• releases beheerst

Wat je nu zegt is echt heel erg pre-devops, waar je geen contract testing hebt, geen Renovate of Dependabot, geen CI/CD tests en slecht gebruik van lockfiles. Dan kan het inderdaad een puinhoop worden ja, maar daar heb je dus gewoon oplossingen voor.

In tegenstelling tot Python's requirements waarbij vaak je "vanaf versie" of "tot versie" ziet, en er dus kans is dat er iets stuk kan gaan. NodeJS geloof ik ook zo? Van PHP composer weet ik het niet.

• Python -> poetry.lock / pip-tools
• Node -> package-lock.json / pnpm-lock.yaml
• PHP -> composer.lock

Al die systemen hebben gewoon harde lock opties hoor. Alles is compleet deterministisch te maken

Wisselende versies op dev/prod welke toevallig in jouw distro release cycle zitten en/of momentaan van installatie beschikbaar was, lijkt mij zeer onwenselijk.

Is het ook. Maar daar hebben we reproducible builds en artefact deployments voor. De taal is echt totaal irrelevant in deze. Je pipelines en processen is waar het valt of staat.

Ik ben zelf tegenwoordig meer in de embedded ontwikkeling hoek actief.

Ah kijk. Daar komt de app uit de mouw. Je kunt niet het embedded wereldje op backend development projecteren. Dat zijn echt twee andere werelden waar andere processen gelden. In embedded wil je minimale dependencies, zoveel mogelijk statisch linken en ook zoveel mogelijk in eigen beheer, want het moet LANG mee. Controle en voorspelbaarheid zijn daarin key.

Bij backend development zit je op een andere as. Daar wil je je ecosysteem leveragen en gebruiken. Dus juist tool managed dependencies die je absoluut niet zelf wil beheren. Snelle development cycles en verantwoordelijkheden elders kunnen beleggen als het nodig is. Snelheid, schaalbaarheid en maintainablity. Dat doe je juist niet door je dependencies binnen te trekken als source.

Het voordeel is wel: de source code staat in je eigen tree, dus je kan alles aanpassen naar wens.

Het nadeel lijkt mij ook evident: je hebt ineens geen dependency meer, maar een nieuwe stuk legacy onderhoud. Als je eenmaal begint aan het binnentrekken en eenzijdig aanpassen van code, dan zit je dus met je hele project weer vast op een stuk extra code wat je moet gaan onderhouden en zodra je ook maar 1 regel aanpast ben je de sjaak, want je zult geheid bij de volgende update een change krijgen die je er niet meer fatsoenlijk in gefietst gaat krijgen. Je cost trade-off is echt gigantisch en dan ook echt compleet de verkeerde kant op. Je bent ineens maintainer van een stuk code die niet van jou is, omdat het een lib is, vaak veel te groot en generiek voor jouw toepassing, en je bent nog steeds afhankelijk van die derde partij voor security updates.

Dit leek op het model zoals Google dat had met Android voor updates, we weten allemaal hoe tragisch dat was. Google update -> fabrikant update -> carrier update -> een jaar verder voordat er mogelijk iets te updaten viel voor de klant.

Echter wanneer je een library moet updaten (bvb een vulnerability die je zelf niet kan fixen), dan heb je kans op 1) Bugs kunnen opnieuw ontstaan, 2) Bugs kunnen subtiel anders gefixt zijn, 3) Er tal van andere breaking changes zijn.

Again. Life cycle management en automatisering. Tests goed schrijven, Pipelines goed maken, Dependabot er op gooien en gewon gas geven. Dit is echt alleen een probleem als je je spul niet op orde hebt hoor.

is er geen automatisch package beheer.

Dit is een governance probleem.

Hieruit voortvloeiend krijg je helaas ook de 'not invented here' vibe.

Ja maar het alternatief is “we bouwen alles zelf” en dat is echt wel een anti-pattern waar je juist tegen de dingen aan gaat lopen die je wil voorkomen: Meer bugs, Minder security updates en significant hogere kosten.

Met zo'n mindset zie ik elke extra dependency dan ook als een lange termijn gevaar, en dus ook andere talen, frameworks, enz.

Maar alles wat je in "die mindset" wegzet zijn anti-patterns. Dus ik geloof niet dat iemand dat zal aanraden. De dingen die je hier als risico ziet voor de lange termijn zijn dan vaak zaken die al wel oplosbaar zijn in een vorm. DevOps is denk ik wel de oplossing voor de issues die je hier benoemd.

Als incrementele versies betrouwbaar moeten blijven, is het uit den boze om blind packages te upgraden.

Nee, Maar niemand beweert ook dat je dat blind moet doen. Sterker nog, ik weet 100% zeker dat niemand aan zal raden dat je dat ooit doet.

Ja begrijpelijk hoor. Vanuit enterprise zie ik ook meer standaardisatie op 1 taal + tooling rondom een select aantal van die andere talen zoals Python en Go voor het scriptwerk.

in het geval van tweakers zit er ook al weer 25 jaar aan development achter dus kan me ook nog wel wat legacy en dergelijke voorstellen. Je noemde de data complexiteit al. Als je dan wat kleiner bent en idd niet 80 teams en 500 devs hebt, dan wil je er idd zo weinig mogelijk zien.

Hoewel ik jouw lijstje nog behoorlijk vind hoor.