Shift Down: l’evoluzione dello Shift Left che sfrutta le piattaforme

L’utilizzo del modello a V ha i suoi vantaggi. È un approccio altamente disciplinato, poiché una fase inizia quando la precedente è terminata. È anche facile da usare e da capire. Tuttavia, la somiglianza con il modello Waterfall fa emergere anche alcune limitazioni associate a questo modello:

• Per i progetti più grandi, le fasi strutturate e interconnesse del modello a V potrebbero diventare gravose da gestire per i team di collaudo, con conseguenti problemi di coordinamento e maggiore complessità.
• Il coinvolgimento del cliente è in genere più concentrato verso le fasi successive del processo di sviluppo del modello a V, con conseguente riduzione delle opportunità di feedback precoci e potenziale disallineamento con le aspettative del cliente.
• Il modello non supporta intrinsecamente i cambiamenti rapidi o lo sviluppo iterativo.

Con le applicazioni moderne che diventano sempre più complesse, c’è bisogno di tipi più avanzati di approcci di test shift left, come i test incrementali e i test model-based.

L’utilizzo di test incrementali è un processo di sviluppo del software che promuove test precoci e frequenti di singoli componenti o unità durante lo sviluppo. Questo approccio funziona meglio con i sistemi complessi e aiuta a mitigare il rischio che i problemi si trasformino in problemi più complessi durante le fasi successive.

I test model-based aiutano a verificare i requisiti, l’architettura e i modelli di progettazione eseguibili, e sono in grado di ridurre del 45-65% gli errori introdotti in queste prime fasi. L’approccio basato sui modelli è il metodo più recente nel campo dei test shift left e il suo principale vantaggio è che funziona nelle prime fasi del ciclo di sviluppo del progetto.

Che cos’è lo shift right?

Il concetto di “shift right” introduce un cambiamento dinamico nel modo in cui si affrontano i test e la QA del software. A differenza dei metodi tradizionali come lo shift left, che si concentrano esclusivamente sui test di pre-produzione, lo “shift right” sostiene l’estensione della fase di test all’ambiente di produzione live. Questo approccio acquisisce l’esperienza reale dell’utente conducendo valutazioni rigorose in condizioni reali.

Lo shift right consiste nell’eseguire il deploy dell’applicazione nel mondo reale e nell’osservare come essa risponde agli utenti, ai dati e all’ambiente. Sottoponendo l’applicazione a carichi di utenti autentici e a scenari di utilizzo reali, shift right permette di ottenere preziose informazioni sul comportamento dell’applicazione, sulla sua reattività e sulla sua capacità di rispondere alle richieste degli utenti.

Ecco alcuni dei vantaggi principali dell’eseguire test secondo l’approccio shift right:

• Determinare il carico di lavoro effettivo del traffico dei clienti e garantire che il software sia in grado di gestire le richieste e i requisiti precisi degli utenti in un ambiente di produzione reale.
• Identificare le preferenze degli utenti attraverso A/B testing o Blue-Green deployment.
• Individuare e risolvere potenziali problemi nell’ambiente di produzione prima che si aggravino e abbiano un impatto su una base di utenti più ampia.

Bilanciare shift left e shift right: Un approccio olistico alla sicurezza delle applicazioni

Sebbene sia stato utile nel corso degli anni, concentrarsi esclusivamente sullo shift left può presentare alcuni inconvenienti, in quanto non è in grado di coprire tutte le complessità degli scenari del mondo reale e degli ambienti di produzione. Questa mancanza può mettere alla prova il team di sviluppo e distogliere la sua attenzione da compiti essenziali per risolvere questi problemi nelle fasi successive.

In questa sezione vedremo i potenziali problemi di sicurezza che possono derivare da una eccessiva attenzione alle pratiche shift left. Mostreremo anche l’importanza dei test shift right abbinati ai test shift left per ridurre al minimo i rischi e garantire una solida sicurezza delle applicazioni.

Problemi di sicurezza dovuti alla forte concentrazione sullo shift left
I test di sicurezza eseguiti nello shift left non forniscono l’intero contesto di sicurezza dell’infrastruttura, ma piuttosto un piccolo pezzo del puzzle per approfondire la sicurezza delle applicazioni moderne.

Lo shift left funziona molto bene per i test di sviluppo. Tuttavia, perde efficacia piuttosto rapidamente quando viene applicato ad applicazioni e tecnologie già in uso all’interno di un ambiente, per cui l’approccio di test shift right sarà sempre importante. Un altro esempio dell’inefficienza dei test shift left è il caso delle API. L’approccio shift left potrebbe richiedere una valutazione approfondita delle potenziali vulnerabilità dei meccanismi di autenticazione e autorizzazione delle API, che rendono le API vulnerabili ad accessi non autorizzati, violazioni dei dati e attacchi pericolosi.

Una strategia di test operativo completa che includa le giuste pratiche di shift right è fondamentale per mitigare questi rischi per la sicurezza. L’esclusiva dipendenza dai soli test di shift left fa perdere alcune vulnerabilità di sicurezza che diventano evidenti solo nell’uso reale; shift right, invece, estende il test all’ambiente di produzione.

In sostanza, i test shift left uniscono sviluppo e test, includendo i test di sviluppo nel ciclo di sviluppo del software. D’altro canto, il test shift-right comprende i test operativi. I team di sicurezza possono stabilire un solido framework di sicurezza combinando questi approcci di test.

L’applicazione di Shift Left e Shift Right nell’architettura a microservizi

La modularità e l’interoperabilità dei microservizi consentono il rilascio frequente di applicazioni grandi e complesse. Questo complica l’esecuzione di test nell’ambito shift left per molte ragioni:

• I microservizi spesso comunicano tramite API, rendendo le loro interazioni intricate. I test dello shift left potrebbero faticare a simulare accuratamente la natura dinamica e interconnessa di questi servizi.
• Isolare i singoli microservizi per i test può essere impegnativo. Le pratiche di shift left potrebbero dover affrontare efficacemente i problemi che sorgono quando più servizi interagiscono, causando problemi non rilevati nel sistema complessivo.
• Un’architettura a microservizi può coinvolgere molti servizi, rendendo i test completi molto impegnativi dal punto di vista di utilizzo delle risorse.
• Lo shift a sinistra potrebbe non notare le vulnerabilità di sicurezza specifiche dei microservizi, come la convalida inadeguata dei dati tra i servizi, i problemi di propagazione dei token o i controlli di accesso illeciti.

L’importanza di incorporare i test di shift right per garantire un monitoraggio e un feedback completi
Nei microservizi, gli approcci di test shift right e shift left sono strumenti fondamentali per un monitoraggio e un feedback completi. Shift right ci permette di valutare l’intero ecosistema di diversi microservizi in condizioni reali, fornendo preziose indicazioni su come questi servizi interagiscono tra loro, scalano e rispondono ai carichi di traffico degli utenti.

L’approccio shift right consente un miglioramento continuo attraverso cicli di feedback iterativi. Questo approccio ripetitivo permette di migliorare l’esperienza del cliente con l’applicazione in base al feedback degli utenti e ai modelli di utilizzo dei dati reali.

Che cos’è lo shift down?

L’approccio “shift down” sfrutta le piattaforme esistenti e consente alle figure meno esperte dal punto di vista tecnico di risolvere un maggior numero di problemi nelle prime fasi del processo. Con l’approccio shift down, si riduce il carico cognitivo di chi sviluppa software sfruttando appieno la tecnologia disponibile e spostando più carichi di lavoro sulle piattaforme che già utilizzano.

L’approccio “shift down” nello sviluppo mira a migliorare l’efficienza e a ridurre i costi, liberando le figure più senior per concentrarsi su compiti più complessi e innovativi. Si possono osservare diversi esempi di approcci shift down in vari scenari, tra cui:

• Le figure più junior sono in grado di risolvere i problemi senza dover ricorrere a persone più esperte.
• Gli strumenti e la documentazione self-service consentono agli utenti di risolvere i loro problemi senza contattare l’assistenza.

Vantaggi della compressione dello stack tecnologico e della riduzione del carico cognitivo degli sviluppatori
La compressione dello stack tecnologico implica la scelta e l’utilizzo strategico di un insieme ridotto di tecnologie, framework e strumenti per lo sviluppo. Questo approccio mira a ridurre la complessità della gestione di molteplici dipendenze e interazioni, semplificando così lo sviluppo per i team di sviluppo. I vantaggi di questo approccio comprendono:

• Ridurre il numero di tecnologie e framework da conoscere per poter lavorare al progetto.
• Consentire di acquisire rapidamente familiarità con un insieme ridotto di tecnologie e strumenti per iniziare a lavorare sul progetto.
• Ridurre il carico cognitivo in modo che i team di sviluppo abbiano tempo e risorse sufficienti per lavorare su nuovi progetti e raggiungere gli obiettivi aziendali, invece di lottare per comprendere nuovi strumenti complessi.

Eseguire lo shift down nel ciclo di rilascio del software

L’approccio “shift down”, che sfrutta le piattaforme sottostanti, contribuisce a promuovere una collaborazione più fluida, una risoluzione più rapida dei problemi e una maggiore efficienza nel rilascio del software.

Il Platform Engineering è una disciplina che condivide l’obiettivo di migliorare l’efficienza nella distribuzione del software. Il Platform Engineering è la progettazione e la costruzione di toolchain e flussi di lavoro che consentono funzionalità self-service e migliorano la Developer Experience. Oltre a consentire funzionalità self-service, vi sono altri vantaggi nell’adottare il Platform Engineering:

• Il Platform Engineering aiuta a migliorare l’efficienza e ad accelerare lo sviluppo e la distribuzione del software, automatizzando le attività e fornendo strumenti e processi standardizzati, chiamati anche Golden Path.
• I processi standardizzati garantiscono l’uniformità tra le varie fasi, riducendo così gli errori e migliorando la qualità del prodotto.
• Il Platform Engineering può portare a una riduzione dei costi e a un uso più efficiente delle risorse.

Per implementare efficacemente il Platform Engineering, è necessario uno sforzo interfunzionale che richiede collaborazione e comunicazione tra i diversi team. Questa collaborazione assicura che tutti comprendano e lavorino per raggiungere obiettivi condivisi. La comunicazione colma i divari tra i team e incoraggia il feedback costante, le intuizioni condivise e le best practice, favorendo il miglioramento continuo, l’apprendimento e la risoluzione dei problemi.

Sfide e strategie di mitigazione per eseguire lo shift down

In questo articolo abbiamo analizzato in dettaglio i motivi per cui lo shift down è la mossa giusta per molte organizzazioni, in quanto aumenta la produttività delle figure meno esperte e sgrava quelle più esperte da molte attività ripetitive e non strettamente legate all’obiettivo finale del progetto. Tuttavia, questo passaggio può essere impegnativo per molti motivi.

In primo luogo, lo shifting down richiede un cambiamento culturale significativo, in quanto i team devono essere disposti a rinunciare a un po’ di controllo in più e a lavorare in modo collaborativo. In secondo luogo, è necessario un investimento significativo in strumenti, infrastrutture e formazione per i membri meno esperti del team.

Per affrontare le sfide dello shift down alla piattaforma, le organizzazioni possono adottare una serie di strategie pratiche. Tra queste troviamo:

• Iniziare con un progetto e un team di piccole dimensioni, quindi ampliare gradualmente l’approccio. Eseguire lo shift down in una volta sola è infatti estenuante.
• Investire in strumenti e infrastrutture adeguati che possano supportare l’approccio “shift down”. L’automazione e gli strumenti self-service di facile utilizzo sono la chiave per consentire ai team di sviluppo di adattarsi e prosperare nel Platform Engineering.
• Costruire un team di Platform Engineering che abbia una profonda conoscenza della piattaforma e che la tratti come un vero e proprio prodotto.

I benefici dello shift down verso una piattaforma sono molteplici:

• Migliore efficienza nel processo di sviluppo del software: Il passaggio alla piattaforma aiuta a liberare risorse e ingegneri esperti per concentrarsi su attività più complesse e a snellire i processi di sviluppo, test e operazioni. Inoltre, porta a una risoluzione più rapida dei problemi e a un time to market più veloce.
• Maggiore agilità: Il passaggio alla piattaforma rende più semplice l’implementazione e il debug di nuovi componenti e funzionalità, migliorando così la qualità complessiva del codice.
• Riduzione dei costi: Lo shift down può ridurre i costi grazie alla centralizzazione dell’infrastruttura e delle risorse, con conseguente riduzione dei costi IT e un uso più efficiente delle risorse.

Conclusione

Eseguire lo shift down alla piattaforma offre un approccio trasformativo che ottimizza l’utilizzo delle risorse per accelerare e migliorare il processo di sviluppo del software delle organizzazioni. Le organizzazioni hanno tradizionalmente impiegato la nota strategia shift left nello sviluppo del software, ma i suoi limiti hanno stimolato l’approccio shift down.

Nel mondo del Platform Engineering, le organizzazioni possono sfruttare le piattaforme e gli strumenti esistenti per progettare, costruire e distribuire solide toolchain che offrono processi standardizzati, automazione e implementazioni semplificate per superare le complessità tecniche. L’adozione della filosofia “shift down”, insieme alla Platform Engineering, g arantisce non solo un utilizzo efficiente delle risorse e delle competenze, ma anche un ecosistema in cui fioriscono l’apprendimento continuo, la collaborazione e l’innovazione.

Affidarsi a un platform builder come Mia-Platform consente alle organizzazioni di integrare facilmente il Platform Engineering nei cicli di sviluppo e rilascio del software. Le aziende potranno così evolvere in Platform Company: scarica il white paper gratuito per scoprire tutti i vantaggi di questo paradigma.

Questo articolo è stato scritto da Michel Murabito, Developer Advocate di Mia‑Platform.