Sviluppo remoto su AWS: da Cloud9 a VS Code
20 Novembre 2024 - 2 min. read
Alessio Gandini
Cloud-native Development Line Manager
Benvenuti nella nostra serie di 3 articoli dedicata al principio della Landing Zone su AWS. Nei prossimi articoli capiremo perché sia un concetto imprescindibile per qualsiasi azienda intraprenda un percorso di Cloud adoption e perché dovremmo considerarlo prima di ogni cosa quando progettiamo un ambiente Cloud.
Oggi cominciamo descrivendone i concetti base, le linee guida e le best practice per una corretta implementazione. Iniziamo!
L’interesse nei confronti del Cloud sta crescendo esponenzialmente. Da un lato, la stragrande maggioranza delle startup decide di basare l’infrastruttura sui servizi Cloud fin da subito. Dall’altro, sono sempre di più anche le aziende di stampo più tradizionale che si avvicinano a questa tecnologia in ottica di modernizzazione. Qualunque sia il grado di adozione del Cloud, la dimensione aziendale o il settore di appartenenza, è fondamentale comprendere appieno come muoversi in un mondo che mette in revisione le pratiche tipiche delle infrastrutture on-premise.
Dall'azienda che vuole partire da zero in ambiente Cloud, passando per chi vuole migrare i propri carichi di lavoro, fino a chi vuole estendere il proprio datacenter basandosi su una soluzione ibrida, il Cloud è uno strumento molto potente per soddisfare l’esigenza di maggior produttività, agilità e resilienza.
Spesso per questioni legate al time-to-market, per necessità di poter creare workload nuovi più velocemente, oppure per via dell’esaurimento imminente delle risorse on-premise, si tende a buttarsi in Cloud in maniera un po’ scomposta e a rimandare la definizione di aspetti strutturali di controllo sui propri ambienti AWS.
Ma non c’è nulla di più definitivo di ciò che è temporaneo: per questo è buona pratica adottare un approccio consistente prima di iniziare qualsiasi progetto sul Cloud evitando di dover correre ai ripari nel momento meno opportuno.
La natura on-demand e agile del Cloud ci permette di sperimentare con velocità, di fallire a basso costo e di poter creare ambienti di Disaster Recovery in maniera estremamente competitiva. Per farlo in sicurezza, però, è necessario garantire il corretto bilanciamento tra controllo e flessibilità, permettendo agli sviluppatori di sperimentare liberamente e in tutta sicurezza secondo il principio Fail-Fast.
Prima di mettere in opera un server o delle API pubbliche sul Cloud, bisogna tenere in considerazione una serie di tematiche che comprendono governance, compliance, ripartizione dei costi, gestione degli accessi, configurazioni di networking, disaster Recovery. Fondamentalmente, questa è l’idea che sta dietro al concetto di Landing Zone.
La Landing Zone è un set comune di regole, best practices, configurazioni, oggetti e appliance che definiscono la configurazione dell’ambiente AWS dentro al quale verranno eseguiti i workload aziendali in maniera consistente e governata.
I canoni su cui deve essere costruita la Landing Zone sono:
La Landing Zone è il requisito principale su cui si basa l’AWS Well-Architected Framework ed essa stessa non si deve esimere dal rispettarlo.
Per implementare una Landing zone, si possono adottare due approcci differenti.
Il primo si basa sull’utilizzo di AWS Control Tower, il servizio gestito di AWS che offre un modello general purpose e automatizzato di implementazione della Landing Zone. AWS Control Tower permette di automatizzare la configurazione degli account e la creazione di policy di sicurezza e di regole di accesso basate su blueprint e best practice pronti all’uso.
Se pur interessante e utile nel caso in cui ci si affacci al Cloud sperimentando un ambiente nuovo, si tratta comunque di un approccio di tipo one-size-fits-all, quindi con dei limiti e potrebbe non essere il più adatto al proprio contesto aziendale.
Il secondo approccio si basa invece su una progettazione 100% custom, affiancati da un partner esperto, che presuppone profonda conoscenza del contesto in cui la Landing zone sarà calata, risultando aderente alla struttura e all’organizzazione aziendale.
Come recita la Legge di Conway (Melvin Conway):
“le organizzazioni che progettano sistemi ... sono indotte a generare design che sono copie dei legami nelle organizzazioni stesse.”
Questo principio ci insegna a progettare rispettando lo scheletro dell’azienda. È necessario comprendere quanti e quali team IT sono presenti, quali workload e la loro complessità, le prospettive e le procedure aziendali. Solo declinando queste variabili è possibile progettare le fondamenta su cui costruire una pratica Cloud corretta.
Aziende Enterprise che hanno un piccolo team IT hanno bisogno di una Landing Zone che non aggiunga overhead ai task quotidiani, pur mantenendo un controllo semplificato e centralizzato. Startup tecnologiche orientate al prodotto, con workload moderni e complessi, necessitano di un controllo più strutturato degli accessi, ma allo stesso tempo non devono limitare l’agilità dei propri sviluppatori. Aziende stratificate da tanti nuclei che hanno bisogno di consolidare e modernizzarsi hanno bisogno di uno scheletro di partenza solido e modulare. Insomma, si può partire da un modello di base, ma ogni scenario ha bisogno di tradurre le sue peculiarità.
In altre parole, partire da un modello basilare può essere utile per iniziare, ma occorre tenere a mente che ogni scenario aziendale dovrà essere tradotto in tutte le sue peculiarità e dovrà trovare un terrreno il più possibile adatto a seguire l'andamento della sua evoluzione.
In questo articolo, il primo di una serie di tre, abbiamo introdotto il concetto di Landing Zone dandone una definizione, descrivendo i principi fondamentali su cui essa si basa e presentando i due metodi attraverso cui è possibile implementarla nella propria strategia di adozione del Cloud.
Nei prossimi due articoli, entreremo nel dettaglio di ciascun principio e concluderemo descrivendo due casi di implementazione della Landing Zone, uno in ambiente enterprise, l’altro in ambiente startup.
Avete già implementato la Landing Zone? In che modo mantenete il controllo in caso di ambienti Cloud multi-account? Dateci il vostro punto di vista!
Leggi la seconda parte
Resources: