In questa seconda parte dedicata alle architetture event-driven, parliamo degli eventi: cosa sono e, soprattutto, cosa non sono?

Durante le mie prime due settimane in Cloud Enablers, ho iniziato a dare un’occhiata ai Dev Containers, tra le tante cose…

Premessa Questo articolo è stato scritto a quattro mani da Serena Sensini e Michael Di Prisco, entrambi genitori, con lo scopo di condividere con altre persone che fanno questo mestiere le frustrazioni, le sfide e le gioie quotidiane nell’essere genitori e dev.

Nel 2009 Netflix ha dovuto affrontare diverse difficoltà, tra cui quella per cui la sua infrastruttura non riusciva a tenere il passo con la domanda dei servizi di streaming video in rapida crescita.

Una delle ultime novità in casa Docker è Docker Scout: un tool per analizzare e gestire le vulnerabilità presenti nelle immagini prodotte disponibile a partire dalla versione 4.

Nel campo delle architetture software, quella event-driven è tra le più note, per i suoi diversi vantaggi e per essere un’architettura stateless.

Kubernetes fornisce una piattaforma per automatizzare il rilascio e le operazioni legate al ciclo di vita dei container definendo le risorse come oggetti “gestiti”, o managed.

Introduzione La programmazione asincrona è un concetto fondamentale nello sviluppo web moderno e una tecnica potente nel nostro arsenale è il batching asincrono, o asynchronous batching.

Quando un container fallisce e un Pod muore, possono esserci diverse ragioni, e queste sono sempre descritte all’interno dei termination messages.

Ti sarà capitato in passato di avere a che fare con i contesti in Kubernetes: questi semplificano notevolmente la vita di chi ha bisogno di interfacciarsi con cluster e namespace diversi e vuole risparmiare qualche comando per passare dall’uno all’altro, invece di eseguire ogni volta comandi come il seguente.