Benvenuti nella nostra serie di 3 articoli dedicata al principio della Landing Zone su AWS. Nei prossimi articoli capiremo perch\u00e9 sia un concetto imprescindibile per qualsiasi azienda intraprenda un percorso di Cloud adoption e perch\u00e9 dovremmo considerarlo prima di ogni cosa quando progettiamo un ambiente Cloud.<\/p>\n\n\n\n
Oggi cominciamo descrivendone i concetti base, le linee guida e le best practice per una corretta implementazione. Iniziamo!<\/p>\n\n\n\n
L\u2019interesse nei confronti del Cloud sta crescendo esponenzialmente. Da un lato, la stragrande maggioranza delle startup decide di basare l\u2019infrastruttura sui servizi Cloud fin da subito. Dall\u2019altro, sono sempre di pi\u00f9 anche le aziende di stampo pi\u00f9 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, \u00e8 fondamentale comprendere appieno come muoversi in un mondo che mette in revisione le pratiche tipiche delle infrastrutture on-premise.<\/p>\n\n\n\n
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 \u00e8 uno strumento molto potente per soddisfare l\u2019esigenza di maggior produttivit\u00e0<\/strong>, agilit\u00e0<\/strong> e resilienza<\/strong>.<\/p>\n\n\n\n Spesso per questioni legate al time-to-market, per necessit\u00e0 di poter creare workload nuovi pi\u00f9 velocemente, oppure per via dell\u2019esaurimento imminente delle risorse on-premise, si tende a buttarsi in Cloud in maniera un po\u2019 scomposta e a rimandare la definizione di aspetti strutturali di controllo sui propri ambienti AWS.<\/p>\n\n\n\n Ma non c\u2019\u00e8 nulla di pi\u00f9 definitivo di ci\u00f2 che \u00e8 temporaneo: per questo \u00e8 buona pratica adottare un approccio consistente<\/strong> prima di iniziare qualsiasi progetto sul Cloud evitando di dover correre ai ripari nel momento meno opportuno.<\/p>\n\n\n\n La natura on-demand e agile del Cloud ci permette di sperimentare con velocit\u00e0, di fallire a basso costo e di poter creare ambienti di Disaster Recovery in maniera estremamente competitiva. Per farlo in sicurezza, per\u00f2, \u00e8 necessario garantire il corretto bilanciamento tra controllo e flessibilit\u00e0<\/strong>, permettendo agli sviluppatori di sperimentare liberamente e in tutta sicurezza secondo il principio Fail-Fast.<\/p>\n\n\n\n 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<\/strong>, disaster Recovery<\/strong>. Fondamentalmente, questa \u00e8 l\u2019idea che sta dietro al concetto di Landing Zone.<\/strong><\/p>\n\n\n\n La Landing Zone \u00e8 un set comune di regole, best practices, configurazioni, oggetti e appliance che definiscono la configurazione dell\u2019ambiente AWS<\/strong> dentro al quale verranno eseguiti i workload aziendali in maniera consistente e governata. <\/p>\n\n\n\n I canoni<\/strong> su cui deve essere costruita la Landing Zone<\/strong> sono:<\/p>\n\n\n\n La Landing Zone \u00e8 il requisito principale su cui si basa l\u2019AWS Well-Architected Framework<\/strong> ed essa stessa non si deve esimere dal rispettarlo.<\/p>\n\n\n\n Per implementare una Landing zone, si possono adottare due approcci differenti<\/strong>.<\/p>\n\n\n\n Il primo si basa sull\u2019utilizzo di AWS Control Tower<\/strong>, 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\u2019uso. <\/p>\n\n\n\n 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<\/strong><\/em>, quindi con dei limiti e potrebbe non essere il pi\u00f9 adatto al proprio contesto aziendale. <\/p>\n\n\n\n Il secondo approccio si basa invece su una progettazione 100% custom<\/strong>, affiancati da un partner esperto, che presuppone profonda conoscenza del contesto in cui la Landing zone sar\u00e0 calata, risultando aderente alla struttura e all\u2019organizzazione aziendale. <\/p>\n\n\n\n Come recita la Legge di Conway<\/strong> (Melvin Conway):<\/p>\n\n\n\n \u201cle organizzazioni che progettano sistemi … sono indotte a generare design che sono copie dei legami nelle organizzazioni stesse.<\/em>\u201d<\/p>\n<\/blockquote>\n\n\n\n Questo principio ci insegna a progettare rispettando lo scheletro dell\u2019azienda. \u00c8 necessario comprendere quanti e quali team IT sono presenti, quali workload e la loro complessit\u00e0, le prospettive e le procedure aziendali. Solo declinando queste variabili \u00e8 possibile progettare le fondamenta su cui costruire una pratica Cloud corretta.<\/p>\n\n\n\n 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\u00f9 strutturato degli accessi, ma allo stesso tempo non devono limitare l\u2019agilit\u00e0 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\u00f2 partire da un modello di base, ma ogni scenario ha bisogno di tradurre le sue peculiarit\u00e0.<\/p>\n\n\n\n In altre parole, partire da un modello basilare pu\u00f2 essere utile per iniziare, ma occorre tenere a mente che ogni scenario aziendale dovr\u00e0 essere tradotto in tutte le sue peculiarit\u00e0<\/strong> e dovr\u00e0 trovare un terrreno il pi\u00f9 possibile adatto a seguire l’andamento della sua evoluzione.<\/p>\n\n\n\n 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 \u00e8 possibile implementarla nella propria strategia di adozione del Cloud.<\/p>\n\n\n\n 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\u2019altro in ambiente startup.<\/p>\n\n\n\n Avete gi\u00e0 implementato la Landing Zone? In che modo mantenete il controllo in caso di ambienti Cloud multi-account? Dateci il vostro punto di vista!<\/p>\n\n\n\n Leggi la seconda parte<\/a><\/p>\n\n\n\n Resources:<\/p>\n\n\n\nCos\u2019\u00e8 una Landing Zone<\/h2>\n\n\n\n
\n
Come implementarla nel modo corretto <\/h2>\n\n\n\n
\n
Per concludere<\/h2>\n\n\n\n
\n\n\n\n