Basterebbe l’incipit di questo articolo di The New Stack che racconta dell’intervento di Tim Hockin alla Kubecon che si è svolta la scorsa settimana a Chicago:

Top Kubernetes engineers are agreeing: K8s is getting too complex, for end-users and maybe even for the core maintainers themselves. Time to put complexity on a budget.

I più importanti ingegneri Kubernetes concordano: K8s [Kubernetes] sta diventando troppo complesso, per gli utenti finali e forse anche per i maintainer stessi. È ora di regolare questa complessità.

Hockin è tra i fondatori di Kubernetes e le sue affermazioni permettono di formulare una serie di pensieri in merito alla direzione che sta prendendo la tecnologia che non sono per nulla banali, e perfettamente in linea con quanto da tempo insistiamo nel proporre: la complessità ci seppellirà.

Ecco alcune delle sue frasi:

There’s a finite amount of complexity that we can absorb into the project over a certain amount of time

C’è una quantità ben definita di complessità che un progetto in un certo lasso di tempo può assorbire

Maggiore è la complessità e minore sarà la capacità di inserire modifiche o cambiamenti nel futuro. Uno dei fattori che hanno incrementato questo rischio è l’incremento di contributori dovuto alla sempre più crescente popolarità della piattaforma.

Ad oggi si contano più di settantaquattromila contributori nel progetto e più questi aumenteranno e più bisognerà far fronte a un minor interesse verso la piattaforma come un unicum ed un maggior interesse “personale”, infatti in molti casi questi contributori sono dipendenti di aziende che hanno la necessità di inserire funzionalità in Kubernetes, piuttosto che volontari a cui interessa il progetto in sé.

Del tutto normale, per carità, è così che va il mondo. Il problema però e reale e si riflette sulla qualità del software:

The more complex something we add is, the more of our budget that we eat up. And when the budget runs out, bad things happen.

Più è complessa una aggiunta che viene fatta, più consumiamo quello che è il nostro budget. E quando il budget finisce, accadono cose brutte.

Da qui l’idea di creare quello che viene definito come un complexity budget, il quale una volta consumato dovrebbe portare ad un alleggerimento delle nuove funzionalità in favore della semplicità generale del progetto.

Imparare a dire no, in poche parole, laddove per quanto ghiotta la funzionalità rappresenterebbe comunque l’aggiunta di ulteriore complessità.

Perché se c’è una cosa che è vera e riconosciuta da tutti, oggi più che mai, è come Kubernetes sia una tecnologia complessa. Usata ovunque, ma complessa. Tanto da richiedere strati intermedi, software che ne alleggeriscono il peso gestionale, forniti da terzi. Le stesse aziende che, facendo business, necessitano che Kubernetes rimanga complesso, minando così gli stessi clienti i quali, in un circolo vizioso, rimangono dentro a una centrifuga di tecnologie che anziché dominare, li sottomette.

Certamente non un problema banale.

Raoul Scarazzini

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.