Negli ultimi anni, il mondo dello sviluppo software ha vissuto una trasformazione radicale, passando dall’esecuzione tradizionale delle applicazioni su server fisici a soluzioni più flessibili e scalabili. Un esempio chiaro di questa evoluzione è il percorso che un’applicazione compie dalla fase di sviluppo fino alla gestione automatizzata con Kubernetes.

Ma prima di andare avanti è meglio dare almeno le definizioni di container e orchestrator, concetti che troveremo più avanti:

• Cos’è un container? Un container è un ambiente isolato che contiene tutto il necessario per eseguire un’applicazione: codice, librerie e dipendenze. Grazie ai container, le applicazioni possono funzionare in qualsiasi sistema senza problemi di compatibilità.
• Cos’è un orchestrator? Un orchestrator, come Kubernetes, è uno strumento che gestisce automaticamente il deployment, il bilanciamento del carico, la scalabilità e il ripristino dei container, garantendo che l’applicazione sia sempre disponibile e performante.

Un po’ di storia: dalle origini dei container a Kubernetes

L’idea di eseguire applicazioni in ambienti isolati risale agli anni ’60 con il concetto di virtualizzazione, ma è negli anni 2000 che i container iniziano a prendere forma. Nel 2000, FreeBSD introduce i “Jails“, un primo tentativo di creare ambienti isolati all’interno di un sistema operativo. Nel 2007, Google sviluppa e introduce il concetto di Process Container, poi cgroups (Control Groups), una tecnologia che permette di limitare e isolare l’uso delle risorse da parte dei processi, e lo integra in Linux.

Nel 2013, Docker Inc. (all’epoca dotCloud) rivoluziona il settore introducendo Docker, una piattaforma open-source che semplifica la creazione, distribuzione ed esecuzione dei container. Grazie alla sua facilità d’uso, Docker diventa rapidamente lo standard de facto per il deployment delle applicazioni. La nascita di Docker ha rivoluzionato non solo la portabilità dei container, ma anche la standardizzazione di questi facendo passi da gigante nell’automatizzare e semplificare il processo di creazione e distribuzione dei container.

Con la crescente diffusione dei container, emerge la necessità di un sistema per gestirli su larga scala. Nel 2014, Google rilascia Kubernetes, un progetto open-source basato su Borg, un orchestratore interno utilizzato per anni nei data center di Google. Kubernetes diventa rapidamente il leader indiscusso nell’orchestrazione dei container, grazie al supporto della Cloud Native Computing Foundation (CNCF).

Il punto di partenza – sviluppo locale

Per cercare di capire cosa sia Kubernetes e qual’è la sua utilità è utile provare a ripercorrere lo sviluppo di una applicazione nel tempo.

Immaginiamo di dover sviluppare una piccola applicazione web, magari con Python e Flask. Il primo passo naturale è scrivere il codice e testarlo sulla propria macchina, installando le librerie necessarie e configurando l’ambiente per farlo funzionare. Finché l’applicazione è utilizzata solo dallo sviluppatore, questo approccio può andare bene.

Tuttavia, emergono rapidamente i primi problemi: cosa succede se dobbiamo eseguire la stessa applicazione su un altro computer? O se dobbiamo distribuirla a più sviluppatori senza conflitti tra librerie diverse? Qui entra in gioco la necessità di un sistema più standardizzato, che permetta anche di automatizzare alcune operazioni.

L’isolamento con Docker

Docker risolve questi problemi fornendo un ambiente isolato in cui l’applicazione può essere eseguita senza dipendere dalla configurazione del sistema operativo sottostante. Creando un’immagine Docker, è possibile impacchettare tutto il necessario (codice, dipendenze, configurazioni) in un unico file eseguibile, che può essere eseguito su diverse macchine. In questo modo, l’applicazione diventa più portatile: può essere avviata con un semplice comando e funzionerà in modo consistente su macchine con configurazioni simili, sia in locale che su server remoti.

Coordinare più servizi con Docker Compose

Molte applicazioni non sono autonome e richiedono l’interazione con altri servizi per funzionare correttamente. Ad esempio, un’applicazione web potrebbe dipendere da un database come PostgreSQL. In questi casi, gestire i singoli container separatamente può diventare complicato. Docker Compose semplifica questo processo, permettendo di definire e avviare più container contemporaneamente con un solo comando, gestendo facilmente le dipendenze tra i vari servizi.

Questo approccio semplifica la gestione di applicazioni composte da più servizi, rendendo lo sviluppo più fluido.

Ma cosa succede quando vogliamo eseguire la nostra applicazione non su un solo server, ma su più macchine, magari per gestire un traffico maggiore?

La scalabilità con Kubernetes

Dopo aver gestito l’ambiente di sviluppo e aver creato il container con Docker, il passo successivo è affrontare la gestione su larga scala, ed è qui che Kubernetes entra in gioco.

Se l’applicazione deve gestire un numero crescente di utenti, un singolo server non basta più , occorre passare a Kubernetes, un sistema di orchestrazione che automatizza la gestione dei container su più macchine.

Con Kubernetes, possiamo:

• Distribuire l’app su più server per garantire disponibilità continua.
• Scalare automaticamente il numero di container in base al carico di lavoro.
• Riavviare automaticamente i container che si bloccano o falliscono.
• Bilanciare il traffico tra le varie istanze dell’applicazione.

Questa flessibilità permette di affrontare qualsiasi esigenza di crescita, senza dover gestire manualmente ogni singolo container.

L’altra faccia della medaglia

Se da un lato Docker e Kubernetes hanno portato grandi vantaggi in termini di flessibilità, scalabilità e gestione delle applicazioni, dall’altro hanno anche ampliato la superficie di attacco e le potenzialità di vulnerabilità. Con l’introduzione di container, orchestratori e infrastrutture distribuite, si sono creati nuovi punti di accesso per attacchi informatici.

Ogni componente aggiunto all’infrastruttura (dal container stesso, ai vari microservizi, fino ai nodi gestiti da Kubernetes) introduce nuove potenziali vulnerabilità. Inoltre, la gestione di più container e il coordinamento tra di essi richiedono la gestione di credenziali, configurazioni di rete e comunicazioni che, se non protette adeguatamente, possono diventare veicoli per attacchi.

Il rischio aumenta ulteriormente con l’adozione di configurazioni errate, la gestione di dati sensibili non adeguatamente criptati e la possibilità di errori di programmazione nei microservizi che, se sfruttati, possono compromettere l’intero sistema. In un ambiente distribuito, un attacco a uno dei singoli componenti può avere ripercussioni su tutta l’infrastruttura, con effetti devastanti.

Conclusione: innovazione e sicurezza vanno di pari passo

L’evoluzione tecnologica portata da Docker, Kubernetes e le architetture distribuite, ha trasformato radicalmente il modo in cui sviluppiamo, distribuiamo e gestiamo le applicazioni. Grazie a queste tecnologie, le organizzazioni possono rispondere in modo più agile alle esigenze di mercato, ottimizzare le risorse e garantire scalabilità continua. Tuttavia, come con ogni innovazione, l’introduzione di queste soluzioni ha anche ampliato la superficie di attacco, portando con sé nuove sfide in termini di sicurezza.

Per sfruttare appieno i vantaggi di queste tecnologie senza incorrere nei rischi associati, è fondamentale che le aziende adottino un approccio di sviluppo sicuro sin dalle prime fasi del ciclo di vita del software. Ciò significa integrare pratiche di sicurezza in ogni fase del processo di sviluppo, dalla scrittura del codice alla gestione dei container e delle configurazioni, passando per la protezione dei dati e delle comunicazioni. La sicurezza non deve più essere vista come un elemento separato, ma come una componente fondamentale e proattiva da incorporare fin dall’inizio nei processi di produzione.

In definitiva, l’automazione e la scalabilità rappresentano il futuro della gestione applicativa, ma solo con una solida base di sviluppo sicuro e una gestione olistica della sicurezza queste innovazioni potranno essere pienamente sfruttate, assicurando al contempo che i benefici della trasformazione digitale non si traducano in vulnerabilità sistemiche.

L'articolo Dal codice alla scalabilità: il viaggio di un’applicazione con Docker e Kubernetes proviene da il blog della sicurezza informatica.

If you flew or drove anything remote controlled until the last few years, chances are very good that you’d be using some faceless corporation’s equipment and radio protocols. But recently, open-source options have taken over the market, at least among the enthusiast core who are into squeezing every last bit of performance out of their gear. So why not take it one step further and roll your own complete system?

Apparently, that’s what [Malcolm Messiter] was thinking when, during the COVID lockdowns, he started his own RC project that he’s calling LockDownRadioControl. The result covers the entire stack, from the protocol to the transmitter and receiver hardware, even to the software that runs it all. The 3D-printed remote sports a Teensy 4.1 and off-the-shelf radio modules on the inside, and premium FrSky hardware on the outside. He’s even got an extensive folder of sound effects that the controller can play to alert you. It’s very complete. Heck, the transmitter even has a game of Pong implemented so that you can keep yourself amused when it’s too rainy to go flying.

Of course, as we alluded to in the beginning, there is a healthy commercial infrastructure and community around other open-source RC projects, namely ExpressLRS and OpenTX, and you can buy gear that runs those software straight out of the box, but it never hurts to have alternatives. And nothing is easier to customize and start hacking on than something you built yourself, so maybe [Malcolm]’s full-stack RC solution is right for you? Either way, it’s certainly impressive for a lockdown project, and evidence of time well spent.

Thanks [Malcolm] for sending that one in!

hackaday.com/2025/04/04/lockdo…

We remember when the transputer first appeared. Everyone “knew” that it was going to take over everything. Of course, it didn’t. But [Oscar Toledo G.] gives us a taste of what life could have been like with a JavaScript emulator for the transputer, you can try in your browser.

If you don’t recall, the transputer was a groundbreaking CPU architecture made for parallel processing. Instead of giant, powerful CPUs, the transputer had many simple CPUs and a way to chain them all together. Sounds great, but didn’t quite make it. However, you can see the transputer’s influence on CPUs even today.

Made to work with occam, the transputer was built from the ground up for concurrent programming. Context switching was cheap, along with simple message passing and hardware scheduling.

The ersatz computer has a lot of messages in Spanish, but you can probably muddle through if you don’t hablar español. We did get the ray tracing example to work, but it was fairly slow.

Want to know more about the CPU? We got you. Of course, these days, you can emulate a transputer with nearly anything and probably outperform the original. What we really want to see is a GPU emulation.

hackaday.com/2025/04/04/the-tr…

[Morten] works very fast. He has already designed, fabbed, populated, and tested a breakout board for the new tiniest microcontroller on the market, and he’s even made a video about it, embedded below.

You might have heard about this new TI ARM Cortex MO micro on these very pages, where we asked you what you’d do with this grain-of-rice-sized chunk of thinking sand. (The number one answer was “sneeze and lose it in the carpet”.)

From the video, it looks like [Morten] would design a breakout board using Kicad 8, populate it, get it blinking, and then use its I2C lines to make a simple digital thermometer demo. In the video, he shows how he worked with the part, from making a custom footprint to spending quite a while nudging it into place before soldering it carefully down.

But he nailed it on the first try, and honestly it doesn’t look nearly as intimidating as we’d feared, mostly because of the two-row layout of the balls. It actually looks easy enough to fan out. Because you can’t inspect the soldering work underneath the chip, he broke out all of the lines to a header to make it quick to check for shorts between those tiny little balls. Smart.

We love to see people trying out the newest hotness. Let us know down in the comments what new parts you’re trying out.

Thanks [Clint] for the tip!

youtube.com/embed/XSAPGh9um_k?…

hackaday.com/2025/04/04/first-…

If you’re on the US East Coast, you should head on over to Wall, NJ and check out the Vintage Computer Festival East. After all, [Brian Kernighan] is going to be there. Yes, that [Brian Kernighan].

Events are actually well underway, and you’ve already missed the first few TRS-80 Color Computer programming workshops, but rest assured that they’re going on all weekend. If you’re from the other side of the retrocomputing fence, namely the C64 side, you’ve also got a lot to look forward to, because the theme this year is “The Sounds of Retro” which means that your favorite chiptune chips will be getting a workout.

[Tom Nardi] went to VCF East last year, so if you’re on the fence, just have a look at his writeup and you’ll probably hop in your car, or like us, wish you could. If when you do end up going, let us know how it was in the comments!

hackaday.com/2025/04/04/vintag…

"Zero Day", su Netflix, interpretato e prodotto da Robert De Niro.

Sei episodi.

Ve lo consiglio.

Eh sì amici miei, non lo sapevate, ma siamo i peggiori.

Siamo delle bruttissime persone. Orribili. Così raccapriccianti e temibili da farci definire "i peggiori" da parte di Trump.

Peggiori perché?

Perché abbiamo osato dire che, se ci avesse imposto dei dazi, li avremmo messi a nostra volta. E così, come se niente fosse, Trump ci ha messi tra i peggiori, affibbiandoci dazi del 20%, e ci è andata pure bene rispetto alla Cina che ne subirà il 30%.

Quindi, ricapitoliamo: è come se io dicessi a qualcuno che sto per dargli un pugno. Questo mi risponde che se glielo do me ne darà uno anche lui, e decido che l'altro è violento. E così, per difendermi, gli do un pugno per primo.
Non fa una grinza, che ne dite?

Il problema è che in questa sagra delle post-verità che è diventato il mondo, si rischia che chi vedrà la cosa a posteriori pensi davvero che il violento non sarei io, ma l'altro.

Comunque io, se fossi in voi, mi vergognerei un po'. Prendercela così tanto con un pover'uomo anziano (Trump) che, evidentemente, ha ormai varie rotelle fuori posto.

Cioè, non vi fate un po' schifo da soli, quando vi guardate allo specchio? Da oggi, io sì, perché sono tra i peggiori. Mica i terroristi, o chi invade un Paese straniero.

Noi, i peggiori.

#trump #dazi #tariffs #boycottusa #USA #tariffswar #guerradeidazi #Politica

La biografia definitiva di Robert Johnson. La mia recensione su Free Zone Magazine.
#libri #biografie #blues #RobertJohnson

Bruce Conforth, Gayle Dean Wardlow - Il diavolo, probabilmente. Vita di Robert Johnson | FREE ZONE MAGAZINE freezonemagazine.com/articoli/…

Bruce Conforth, Gayle Dean Wardlow - Il diavolo, probabilmente. Vita di Robert Johnson | FREE ZONE MAGAZINE

Robert Johnson è un bluesman fondamentale, e questo libro fa pulizia degli aspetti mitologici per approfondire il musicista.

^{FREE ZONE MAGAZINE}