Dopo oltre 15 anni passati a sviluppare applicazioni web in PHP, lavorando su gestionali, piattaforme web e sistemi in produzione, ho deciso di affrontare una nuova sfida tecnica:
imparare Go, Docker e Kubernetes.
Non perché “vada di moda”.
E nemmeno perché penso che le tecnologie che utilizzo oggi non siano più valide.
La ragione è molto più semplice: credo che un buon sviluppatore non debba mai smettere di evolversi.
Perché Go?
Negli ultimi anni ho iniziato a osservare sempre più progetti backend e infrastrutture costruite in Go.
La cosa che mi ha colpito subito è stata la filosofia del linguaggio:
- semplicità
- performance
- leggibilità
- concorrenza nativa
Dopo tanti anni passati su stack web tradizionali, lavorare con un linguaggio pensato per servizi moderni, API e sistemi distribuiti è stato estremamente stimolante.
Go ti obbliga a ragionare in modo diverso.
E questa, secondo me, è una delle parti più interessanti dell’apprendimento.
Una gestione della concorrenza completamente diversa
Uno degli aspetti che più mi ha colpito di Go è il modo in cui gestisce la concorrenza.
Dopo anni passati su stack web tradizionali, trovarsi davanti a concetti come:
- goroutine
- channels
- select
- context management
cambia completamente il modo di progettare alcune tipologie di applicazioni.
La possibilità di eseguire task concorrenti in maniera semplice e leggibile rende Go particolarmente interessante per:
- microservizi
- API ad alte prestazioni
- tool CLI
- servizi distribuiti
Un altro aspetto che sto apprezzando molto è la standard library: essenziale ma estremamente potente.
La sensazione è che Go cerchi continuamente di eliminare complessità inutili, favorendo codice chiaro e mantenibile.
Docker: il momento in cui tutto cambia
Per anni ho lavorato con ambienti locali, server Linux, staging e deploy manuali.
Poi arriva Docker e cambia completamente il modo in cui guardi un’applicazione.
Non stai più pensando solo al codice.
Stai pensando all’intero ambiente:
- servizi
- dipendenze
- container
- portabilità
La possibilità di avere ambienti coerenti tra sviluppo e produzione è qualcosa che cambia radicalmente il workflow.
E onestamente?
Dopo aver iniziato a usarlo, capisci subito perché sia diventato uno standard.
Containerizzare un’applicazione cambia il modo di pensarla
La parte interessante di Docker non è solo creare container.
È capire come cambia l’approccio allo sviluppo.
Negli ultimi mesi ho iniziato a lavorare con:
- Dockerfile multi-stage
- docker-compose
- network tra container
- persistenza dei volumi
- containerizzazione di database e servizi backend
e questo mi ha fatto capire quanto sia importante progettare applicazioni realmente isolate e portabili.
Uno degli aspetti più utili è la possibilità di replicare ambienti completi in pochi secondi:
- backend
- database
- reverse proxy
- servizi secondari
riducendo drasticamente i classici problemi di configurazione tra sviluppo, staging e produzione.
Docker non è semplicemente uno strumento DevOps.
È un modo diverso di pensare il ciclo di vita del software.
Kubernetes: complesso, ma affascinante
Kubernetes è probabilmente una delle tecnologie più complesse che abbia iniziato ad affrontare negli ultimi anni.
Ed è anche quella che mi ha fatto capire quanto il mondo dello sviluppo moderno si stia spostando verso:
- scalabilità
- automazione
- orchestrazione
- resilienza
All’inizio sembra enorme.
Pods, deployments, services, ingress, cluster… tutto appare dispersivo.
Poi però inizi a vedere il disegno complessivo.
E capisci che Kubernetes non è “solo DevOps”: è un nuovo modo di pensare il software in produzione.
La parte più difficile? Tornare principiante
Dopo tanti anni di esperienza, la sfida più grande non è imparare la sintassi.
È accettare di tornare in una fase in cui:
- non sai tutto
- devi sbagliare
- devi sperimentare
- devi ricominciare a fare domande
Ma è anche la parte più sana di questo lavoro.
Perché ti ricorda che la tecnologia evolve continuamente… e che smettere di imparare è il modo più veloce per restare indietro.
Cosa sto cercando davvero di costruire
Non sto cercando di “cambiare stack” dall’oggi al domani.
Sto cercando di ampliare il mio modo di progettare software.
Capire:
- come funzionano le architetture moderne
- come vengono distribuiti i servizi
- come scalano le applicazioni
- come dialogano sviluppo e infrastruttura
E soprattutto, voglio continuare a essere uno sviluppatore capace di adattarsi.
Perché condivido questo percorso
Per due motivi.
Il primo: perché penso sia importante mostrare anche il processo di apprendimento, non solo il risultato finale.
Il secondo: perché mi piacerebbe confrontarmi con altri sviluppatori che stanno affrontando percorsi simili.
Consigli, esperienze e punti di vista diversi sono spesso il modo migliore per crescere davvero.
Conclusione
Dopo tanti anni nel web development, uscire dalla propria comfort zone non è semplice.
Ma probabilmente è una delle cose migliori che uno sviluppatore possa fare.
E onestamente?
Sono contento di aver iniziato questo percorso.