{"id":8127,"date":"2025-10-29T10:04:14","date_gmt":"2025-10-29T09:04:14","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=8127"},"modified":"2025-10-29T11:44:40","modified_gmt":"2025-10-29T10:44:40","slug":"nightmare-infrastructure-episode-4-nessun-limite-al-peggio","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/","title":{"rendered":"Nightmare infrastructure – episodio 4: nessun limite al peggio."},"content":{"rendered":"\n
\n
\n

“Sai, penso che questa cosa del Natale non sia cos\u00ec complicata come sembra! Ma perch\u00e9 dovrebbero divertirsi solo loro? Dovrebbe essere di tutti! Anzi, non di tutti, ma mio! Perch\u00e9, potrei fare un albero di Natale! E non c’\u00e8 una ragione valida, non potrei avere un periodo natalizio! Scommetto che potrei anche migliorarlo! Ed \u00e8 esattamente quello che far\u00f2!”<\/p>\n\n\n\n

Jack Skellington<\/p>\n<\/blockquote>\n<\/blockquote>\n\n\n\n

<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

<\/p>\n\n\n\n

La dichiarazione di Jack Skellington esprime alla perfezione l’overconfidence di un ingegnere, la sua curiosit\u00e0 e la voglia di migliorare o reinventare un sistema, che porta spesso con risultati caotici o disastrosi. <\/p>\n\n\n\n

Cattura lo spirito che fa prendere un processo semplice per provare a migliorarlo, per scoprire troppo tardi che la complessit\u00e0 originale era nascosta, appena fuori dalla nostra vista. <\/p>\n\n\n\n

Molte tradizioni nascono senza intenzioni serie, senza pianificazione, quasi per esperimento. Questa serie di articoli \u00e8 diventata una tradizione, che ci fa preparare in anticipo e prendere l’anno, pensando a quando arriver\u00e0 di nuovo Halloween per farvi venire i brividi. <\/p>\n\n\n\n

Quindi, bando alle ciance, iniziamo il nostro viaggio negli orrori di quest’anno!<\/p>\n\n\n\n

Il container di Schr\u00f6dinger<\/h2>\n\n\n\n
\n
\n

“Quindi siamo noi nella scatola. Noi siamo il gatto. Siamo sia vivi che morti. Quindi ci sono due realt\u00e0 separate, presumibilmente finch\u00e9 la cometa non passa.” <\/p>\n\n\n\n

Coherence, 2013<\/p>\n<\/blockquote>\n<\/blockquote>\n\n\n\n

<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

<\/p>\n\n\n\n

Il gatto di Schr\u00f6dinger \u00e8 un paradosso per spiegare il principio di indeterminazione della meccanica quantistica: osservando un sistema, lo si altera, rendendo impossibile determinare il suo stato iniziale. <\/p>\n\n\n\n

Per rendere il concetto, basta immaginare che un gatto e una fiala di veleno siano messi in una scatola chiusa, isolata dall’ambiente esterno. Se si apre la scatola, si rompe la fiala, avvelenando il gatto. Allo stesso tempo, il gatto non ha cibo n\u00e9 acqua, quindi prima o poi sar\u00e0 sicuramente morto. Il paradosso \u00e8 nel fatto che, aprendo la scatola, ucciderai di sicuro il gatto, ma senza aprirla non \u00e8 possibile sapere se il gatto sia vivo o morto. <\/p>\n\n\n\n

Questo pu\u00f2 succedere anche a un container<\/em>.<\/strong><\/p>\n\n\n\n

Siamo stati ingaggiati per affrontare un progetto di refactoring di un’applicazione web (il classico “breaking down the monolith”) da un’istanza EC2<\/em> a container.<\/p>\n\n\n\n

Abbiamo iniziato analizzando l’applicazione facendo deploy di un ambiente di sviluppo in un account AWS Account dedicato e procedendo con una prima containerizzazione<\/em> dell’intera applicazione per vedere come interagiva con gli altri servizi esistenti. Dopodich\u00e9 ci siamo dedicati alle pipeline<\/em> di CI\/CD<\/em> e abbiamo impostato un approccio cloud-native. <\/p>\n\n\n\n

Di seguito il diagramma “noioso” dell’infrastruttura. Visto che l’applicazione era relativamente semplice, abbiamo optato per l\u2019utilizzo di  ECS Fargate per il workload.<\/p>\n\n\n\n

<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

<\/p>\n\n\n\n

L’applicazione sembrava a posto, ma, dopo alcuni test iniziali, la mattina dopo il primo deployment, abbiamo visto un errore 502. Abbiamo pensato ad un problema temporaneo, visto che l’applicazione \u00e8 tornata a funzionare dopo qualche minuto.<\/p>\n\n\n\n

 Nel pomeriggio, abbiamo notato la stessa cosa e abbiamo quindi iniziato a investigare. Abbiamo notato che il task ECS era stato riavviato diverse volte la notte prima, anche senza traffico. Il grafico della memoria indicava chiaramente un memory l<\/em>eak. La cosa strana era che nessun utente stava facendo traffico, trattandosi di un ambiente di sviluppo. L’health check dell’Application Load Balancer era sufficiente a scatenare il memory leak. Quindi, il solo fatto di osservare il sistema lo faceva “morire”, proprio come nel paradosso di Schr\u00f6dinger. Il container era contemporaneamente running e morto: il vecchio memory leak dell’applicazione aveva trovato nuova vita nel cloud. <\/p>\n\n\n\n

La vera tragedia non era il bug in s\u00e9, ma il fatto che la nostra architettura era diventata un sistema di delivery per memory leak. Mettere in un container un’applicazione fallata non \u00e8 modernizzazione; \u00e8 solo un modo per accelerarne il malfunzionamento.<\/p>\n\n\n\n

Grazie, Mehmed<\/a>, per l’idea e per il titolo!<\/p>\n\n\n\n

Il filo di Arianna<\/h2>\n\n\n\n
\n

“Arianna sussurra: \u201cLa tana del Minotauro \u00e8 nel cuore stesso del labirinto. Il suono del suo respiro ti mostrer\u00e0 in che direzione andare. Ecco una spada, e qui c’\u00e8 un gomitolo di filo, col quale, dopo aver ucciso il mostro, potrai ritrovare la via del ritorno.\u201d <\/p>\n\n\n\n

Il Mito di Teseo e il Minotauro<\/p>\n<\/blockquote>\n\n\n\n

<\/p>\n\n\n\n

\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n<\/figure>\n\n\n\n

<\/p>\n\n\n\n

Quando Teseo si trova nel labirinto del Minotauro, Arianna gli porge un filo per guidarlo e aiutarlo a ritrovare la via d’uscita.<\/p>\n\n\n\n

Peccato che in questa storia noi non avessimo nessuno a darci una guida. <\/p>\n\n\n\n

Questa storia inizia con un esperimento, diventato poi una grossa applicazione usata da molti grossi clienti. L’azienda \u00e8 partita utilizzando un singolo account AWS per tutti gli ambienti, giusto per sperimentare. All’improvviso, l\u2019applicazione \u00e8 diventata “una cosa seria” e non c\u2019\u00e8 stato tempo per organizzarne la governance. A un certo punto, una Landing Zone \u00e8 diventata necessaria in modo urgente per governare meglio le risorse AWS, isolare risorse e accessi, e rispondere alle richieste dei clienti. <\/p>\n\n\n\n

Dopo aver definito la soluzione migliore per il caso d’uso, aver creato gli account AWS, aver integrato l’IdP ed aver implementato il networking centralizzato, era ora di spostare i workload dal singolo account AWS a quelli dedicati. <\/p>\n\n\n\n

Non abbiamo indagato molto a fondo nell’applicazione, ma si trattava di un’applicazione distribuita in container e che seguiva un approccio a microservizi, quindi abbiamo iniziato le interviste per definire meglio le dipendenze. Visto che il tempo di esecuzione era fondamentale, abbiamo iniziato a fare deploy nel nuovo account. <\/p>\n\n\n\n

Il problema \u00e8 arrivato dopo il deploy dei primi database e la migrazione dei dati: ogni servizio sembrava far riferimento a qualcos’altro: un autoscaling group EC2 per ottenere i parametri di configurazione, un altro microservizio per far partire il frontend, e un batch job che interrogava il servizio preso in esame per popolare una tabella necessaria al primo servizio. <\/p>\n\n\n\n

Provare a tracciare un diagramma delle dipendenze \u00e8 finito per generare qualcosa che ricorda un disegno di Picasso. <\/p>\n\n\n\n

L’esperimento \u00e8 diventato un’applicazione, e l’applicazione \u00e8 diventata una maledizione<\/strong>. Ci siamo resi conto in fretta che il vero labirinto non era la migrazione: era il risultato di dipendenze storiche, mancanza di documentazione e di decisioni prese “ieri”. Abbiamo gi\u00e0 visto la differenza tra container e microservice qui<\/a>.<\/p>\n\n\n\n

Troppo monitoring<\/h2>\n\n\n\n
\n

\u201cDov’\u00e8 la conoscenza che abbiamo perso nell’informazione?\u201d <\/p>\n\n\n\n

 T.S. Eliot – Cori da “La Rocca”<\/p>\n\n\n\n

<\/p>\n<\/blockquote>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

<\/p>\n\n\n\n

Sapere come i clienti stiano fruendo un servizio e se la loro esperienza \u00e8 buona \u00e8 sempre una sfida; se hai un e-commerce, il pi\u00f9 piccolo dettaglio pu\u00f2 avere un impatto sull\u2019esperienza utente, alterando le vendite in modo positivo o negativo.<\/p>\n\n\n\n

 Anche un piccolo delay durante la visita di un sito pu\u00f2 tradursi in una perdita di soldi, quindi \u00e8 cruciale trovare un modo per monitorare l\u2019esperienza utente.<\/p>\n\n\n\n

Vi presentiamo MegaCorp, che ha sviluppato un e-commerce utilizzando ogni piattaforma no-code e servizio immaginabile. Quando qualcosa andava storto, fare troubleshooting era praticamente impossibile, e capire quale componente peggiorasse le performance era un’impresa colossale. <\/p>\n\n\n\n

A peggiorare le cose, i deployment erano programmati ogni 15 giorni per gli ambienti di dev e test, ed ogni mese per l’ambiente di produzione. <\/p>\n\n\n\n

Per nostra fortuna, Amazon RUM semplifica l\u2019attivit\u00e0, fornendo insight su ogni piccolo evento che si verifica nel browser, permettendo di monitorare i dati di performance percepiti dagli utenti, come, ad esempio, i tempi di download delle risorse e di render della pagina, e perfino monitorare le eccezioni JavaScript nella console. <\/p>\n\n\n\n

Amazon RUM inserisce un piccolo JavaScript che riporta gli eventi utente a un endpoint. \u00c8 buona norma testare potenziali interazioni indesiderate con gli script JavaScript esistenti in un ambiente di test. Inoltre, visto che il billing usa un modello pay-as-you-go basato sugli eventi generati, occorre trovare il giusto equilibrio tra monitorare ogni singolo utente e abilitare il sampling, selezionando il tipo di eventi da registrare. <\/p>\n\n\n\n

Abbiamo iniziato quindi con un semplice ambiente di test per trovare il punto giusto e tenere tutto sotto controllo. <\/p>\n\n\n\n

I nostri test non hanno riportato problemi con l’integrazione. Tuttavia, abbiamo dovuto escludere gli eventi per il caricamento delle immagini, visto che era in uso una CDN veloce e il numero di eventi sarebbe stato troppo grande.<\/p>\n\n\n\n

Abbiamo notato alcuni errori JavaScript in console, ma ci hanno detto che erano dovuti al fatto che gli sviluppatori erano in procinto di rilasciare una nuova feature. <\/p>\n\n\n\n

E allora, produzione sia! Dopo aver atteso 20 giorni per il deployment, RUM \u00e8 andato live. E funzionava come previsto, ma… <\/p>\n\n\n\n

Dopo mezza giornata di raccolta dati, abbiamo ricevuto un budget alert: la nostra soglia dell’80% del budget mensile (6000 $) era gi\u00e0 stata raggiunta. <\/p>\n\n\n\n

Abbiamo controllato i numeri: visitatori e page view erano allineati con le nostre previsioni, ma i conti non tornavano per quanto riguardava il numero di eventi. Abbiamo scoperto che ogni visita generava almeno 5 o 6 eccezioni JavaScript nella console del browser, che RUM ovviamente registrava. Gli errori erano dovuti a un bug che era stato s\u00ec sistemato, ma era stato rilasciato in produzione per colpa del ciclo di release. Non potevamo disattivare RUM perch\u00e9 la finestra di deploy era passata. <\/p>\n\n\n\n

Per fortuna, RUM usa un Cognito Identity Pool per creare credenziali temporanee per inviare i dati all\u2019endpoint. Disattivare Cognito ha fermato il billing. <\/p>\n\n\n\n

Alla fine, un bug perfettamente monitorato \u00e8 solo un bug ancora pi\u00f9 costoso, e l’unica cosa pi\u00f9 importante dell\u2019avere una soluzione di monitoring \u00e8 avere un processo per controllare i bug e i deployment in produzione! Quando il ciclo di deployment non riesce a stare dietro al debito tecnico, gli strumenti nati per fornire chiarezza possono trasformarsi molto velocemente in una spesa enorme senza aggiungere valore.<\/p>\n\n\n\n

I soliti sospetti<\/h2>\n\n\n\n
\n

\u201cIn un mondo dove niente \u00e8 ci\u00f2 che sembra devi guardare oltre…\u201d <\/p>\n\n\n\n

Roger Kint (Kevin Spacey) – I Soliti Sospetti<\/p>\n<\/blockquote>\n\n\n\n

<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

<\/p>\n\n\n\n

“La nostra infrastruttura \u00e8 cloud-native”.<\/em> <\/p>\n\n\n\n

Quando abbiamo sentito questa frase, eravamo felici ma anche un po’ sospettosi. <\/p>\n\n\n\n

Dopo una scissione tra aziende, siamo stati incaricati di occuparci della separazione di un account AWS dall\u2019organization originale e dell\u2019implementazione di una Landing Zone nuova fiammante. Questo significava un nuovo set di account, la creazione di un network centralizzato, deleghe dei servizi e una nuova federazione IAM Identity Center. <\/p>\n\n\n\n

Dopo l’assessment iniziale e le interviste, ci \u00e8 stato chiesto di fare troubleshooting su alcuni problemi di latenza e irraggiungibilit\u00e0 sull’applicazione web utilizzata dagli utenti esterni ed in esecuzione in un cluster Amazon EKS. <\/p>\n\n\n\n

Durante le ore di picco, la latenza sembrava aumentare fino a che l’applicazione diventava irraggiungibile per diversi minuti. Poi, senza nessun intervento, il problema sembrava risolversi da solo. <\/p>\n\n\n\n

Anche se era un’applicazione con architettura a microservizi, non era stato implementato nessun meccanismo di tracing. Dopo aver implementato una soluzione di tracing, il quadro \u00e8 diventato chiaro: l\u2019applicazione, in fin dei conti, non era poi cos\u00ec cloud-native: solo la parte a cui accedevano gli utenti girava nativamente su Kubernetes. Tutti gli altri componenti erano ospitati in un datacenter on-premise, con una connessione VPN configurata con un singolo tunnel attivo e senza BGP. Durante le ore di picco, il traffico superava la quota massima di 1,25 Gbit del tunnel, aggiungendo latenza, ritardi e perdita di pacchetti con un effetto valanga. <\/p>\n\n\n\n

L’applicazione girava pure su EKS, ma il suo spirito guida era in realt\u00e0 una connessione dial-up a 56k.<\/p>\n\n\n\n

La luce in fondo al tunnel<\/h2>\n\n\n\n

E cos\u00ec, \u00e8 giunta l\u2019ora di richiudere il coperchio della bara su un’altra collezione di incubi infrastrutturali, con un ultimo promemoria: adottare semplicemente l’ultima tecnologia non rende immuni dai peccati del passato. <\/p>\n\n\n\n

Ma non temete! Gli orrori torneranno la prossima stagione di Halloween. Fino ad allora, che le vostre pipeline siano verdi e i vostri grafici della memoria piatti.<\/p>\n\n\n\n

Abbiamo raccontato le nostre storie, ora vogliamo sentire le vostre! Quali orrori indicibili si nascondono nei vostri ambienti di produzione?<\/p>\n\n\n\n

Lasciateci un commento qui sotto, scambiamoci racconti del terrore prima che le luci si spengano per sempre. <\/p>\n\n\n\n

Buon Halloween, e che la vostra infrastruttura possa riposare in pace… per ora.<\/p>\n\n\n\n

\n\n\n\n

About Proud2beCloud<\/h4>\n\n\n\n

Proud2beCloud \u00e8 il blog di beSharp<\/a>, APN Premier Consulting Partner italiano esperto nella progettazione, implementazione e gestione di infrastrutture Cloud complesse e servizi AWS avanzati. Prima di essere scrittori, siamo Solutions Architect che, dal 2007, lavorano quotidianamente con i servizi AWS. Siamo innovatori alla costante ricerca della soluzione pi\u00f9 all’avanguardia per noi e per i nostri clienti. Su Proud2beCloud condividiamo regolarmente i nostri migliori spunti con chi come noi, per lavoro o per passione, lavora con il Cloud di AWS. Partecipa alla discussione!<\/p>\n","protected":false},"excerpt":{"rendered":"

La dichiarazione di Jack Skellington esprime alla perfezione l’overconfidence di un ingegnere, la sua curiosit\u00e0 e la voglia di migliorare […]<\/p>\n","protected":false},"author":13,"featured_media":8134,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[481],"tags":[],"class_list":["post-8127","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-architecting"],"yoast_head":"\nNightmare infrastructure - episodio 4: nessun limite al peggio. - Proud2beCloud Blog<\/title>\n<meta name=\"description\" content=\"Migrare in cloud non significa che i demoni della vecchia infrastruttura non ti seguiranno; volte diamo loro solo una connessione pi\u00f9 veloce!\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/\" \/>\n<meta property=\"og:locale\" content=\"it_IT\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Halloween Special: Nightmare infrastructure - episodio 4\" \/>\n<meta property=\"og:description\" content=\"Migrare in cloud non significa che i demoni della vecchia infrastruttura non ti seguiranno; volte diamo loro solo una connessione pi\u00f9 veloce!\" \/>\n<meta property=\"og:url\" content=\"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/\" \/>\n<meta property=\"og:site_name\" content=\"Proud2beCloud Blog\" \/>\n<meta property=\"article:published_time\" content=\"2025-10-29T09:04:14+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2025-10-29T10:44:40+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2025\/10\/Copertina-per-Blog-49.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1600\" \/>\n\t<meta property=\"og:image:height\" content=\"900\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Damiano Giorgi\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:title\" content=\"Halloween Special: Nightmare infrastructure - episodio 4\" \/>\n<meta name=\"twitter:description\" content=\"Migrare in cloud non significa che i demoni della vecchia infrastruttura non ti seguiranno; volte diamo loro solo una connessione pi\u00f9 veloce!\" \/>\n<meta name=\"twitter:label1\" content=\"Scritto da\" \/>\n\t<meta name=\"twitter:data1\" content=\"Damiano Giorgi\" \/>\n\t<meta name=\"twitter:label2\" content=\"Tempo di lettura stimato\" \/>\n\t<meta name=\"twitter:data2\" content=\"10 minuti\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/\",\"url\":\"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/\",\"name\":\"Nightmare infrastructure - episodio 4: nessun limite al peggio. - Proud2beCloud Blog\",\"isPartOf\":{\"@id\":\"https:\/\/blog.besharp.it\/it\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2025\/10\/Copertina-per-Blog-49.jpg\",\"datePublished\":\"2025-10-29T09:04:14+00:00\",\"dateModified\":\"2025-10-29T10:44:40+00:00\",\"author\":{\"@id\":\"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/a9195473e4a658b45cb12d3df3fdf293\"},\"description\":\"Migrare in cloud non significa che i demoni della vecchia infrastruttura non ti seguiranno; volte diamo loro solo una connessione pi\u00f9 veloce!\",\"breadcrumb\":{\"@id\":\"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/#breadcrumb\"},\"inLanguage\":\"it-IT\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"it-IT\",\"@id\":\"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/#primaryimage\",\"url\":\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2025\/10\/Copertina-per-Blog-49.jpg\",\"contentUrl\":\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2025\/10\/Copertina-per-Blog-49.jpg\",\"width\":1600,\"height\":900,\"caption\":\"Nightmare infrastructure - episode 4. Just when you thought it couldn't get any worse... SOCIAL ITA\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/blog.besharp.it\/it\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Nightmare infrastructure – episodio 4: nessun limite al peggio.\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/blog.besharp.it\/it\/#website\",\"url\":\"https:\/\/blog.besharp.it\/it\/\",\"name\":\"Proud2beCloud Blog\",\"description\":\"il blog di beSharp\",\"alternateName\":\"Proud2beCloud Blog\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/blog.besharp.it\/it\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"it-IT\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/a9195473e4a658b45cb12d3df3fdf293\",\"name\":\"Damiano Giorgi\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"it-IT\",\"@id\":\"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/302fe7b73fb8aab3dda1174b5fc62e3b5cb8ae007de5c2dee327a1bfda97f1d1?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/302fe7b73fb8aab3dda1174b5fc62e3b5cb8ae007de5c2dee327a1bfda97f1d1?s=96&d=mm&r=g\",\"caption\":\"Damiano Giorgi\"},\"description\":\"Ex sistemista on-prem, pigro e incline all'automazione di task noiosi. Alla ricerca costante di novit\u00e0 tecnologiche e quindi passato al cloud per trovare nuovi stimoli. L'unico hardware a cui mi dedico ora \u00e8 quello del mio basso; se non mi trovate in ufficio o in sala prove provate al pub o in qualche aeroporto!\",\"url\":\"https:\/\/blog.besharp.it\/it\/author\/damiano-giorgi\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Nightmare infrastructure - episodio 4: nessun limite al peggio. - Proud2beCloud Blog","description":"Migrare in cloud non significa che i demoni della vecchia infrastruttura non ti seguiranno; volte diamo loro solo una connessione pi\u00f9 veloce!","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/","og_locale":"it_IT","og_type":"article","og_title":"Halloween Special: Nightmare infrastructure - episodio 4","og_description":"Migrare in cloud non significa che i demoni della vecchia infrastruttura non ti seguiranno; volte diamo loro solo una connessione pi\u00f9 veloce!","og_url":"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/","og_site_name":"Proud2beCloud Blog","article_published_time":"2025-10-29T09:04:14+00:00","article_modified_time":"2025-10-29T10:44:40+00:00","og_image":[{"width":1600,"height":900,"url":"https:\/\/blog.besharp.it\/wp-content\/uploads\/2025\/10\/Copertina-per-Blog-49.jpg","type":"image\/jpeg"}],"author":"Damiano Giorgi","twitter_card":"summary_large_image","twitter_title":"Halloween Special: Nightmare infrastructure - episodio 4","twitter_description":"Migrare in cloud non significa che i demoni della vecchia infrastruttura non ti seguiranno; volte diamo loro solo una connessione pi\u00f9 veloce!","twitter_misc":{"Scritto da":"Damiano Giorgi","Tempo di lettura stimato":"10 minuti"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/","url":"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/","name":"Nightmare infrastructure - episodio 4: nessun limite al peggio. - Proud2beCloud Blog","isPartOf":{"@id":"https:\/\/blog.besharp.it\/it\/#website"},"primaryImageOfPage":{"@id":"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/#primaryimage"},"image":{"@id":"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/#primaryimage"},"thumbnailUrl":"https:\/\/blog.besharp.it\/wp-content\/uploads\/2025\/10\/Copertina-per-Blog-49.jpg","datePublished":"2025-10-29T09:04:14+00:00","dateModified":"2025-10-29T10:44:40+00:00","author":{"@id":"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/a9195473e4a658b45cb12d3df3fdf293"},"description":"Migrare in cloud non significa che i demoni della vecchia infrastruttura non ti seguiranno; volte diamo loro solo una connessione pi\u00f9 veloce!","breadcrumb":{"@id":"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/#breadcrumb"},"inLanguage":"it-IT","potentialAction":[{"@type":"ReadAction","target":["https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/"]}]},{"@type":"ImageObject","inLanguage":"it-IT","@id":"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/#primaryimage","url":"https:\/\/blog.besharp.it\/wp-content\/uploads\/2025\/10\/Copertina-per-Blog-49.jpg","contentUrl":"https:\/\/blog.besharp.it\/wp-content\/uploads\/2025\/10\/Copertina-per-Blog-49.jpg","width":1600,"height":900,"caption":"Nightmare infrastructure - episode 4. Just when you thought it couldn't get any worse... SOCIAL ITA"},{"@type":"BreadcrumbList","@id":"https:\/\/blog.besharp.it\/it\/nightmare-infrastructure-episode-4-nessun-limite-al-peggio\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/blog.besharp.it\/it\/"},{"@type":"ListItem","position":2,"name":"Nightmare infrastructure – episodio 4: nessun limite al peggio."}]},{"@type":"WebSite","@id":"https:\/\/blog.besharp.it\/it\/#website","url":"https:\/\/blog.besharp.it\/it\/","name":"Proud2beCloud Blog","description":"il blog di beSharp","alternateName":"Proud2beCloud Blog","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/blog.besharp.it\/it\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"it-IT"},{"@type":"Person","@id":"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/a9195473e4a658b45cb12d3df3fdf293","name":"Damiano Giorgi","image":{"@type":"ImageObject","inLanguage":"it-IT","@id":"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/302fe7b73fb8aab3dda1174b5fc62e3b5cb8ae007de5c2dee327a1bfda97f1d1?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/302fe7b73fb8aab3dda1174b5fc62e3b5cb8ae007de5c2dee327a1bfda97f1d1?s=96&d=mm&r=g","caption":"Damiano Giorgi"},"description":"Ex sistemista on-prem, pigro e incline all'automazione di task noiosi. Alla ricerca costante di novit\u00e0 tecnologiche e quindi passato al cloud per trovare nuovi stimoli. L'unico hardware a cui mi dedico ora \u00e8 quello del mio basso; se non mi trovate in ufficio o in sala prove provate al pub o in qualche aeroporto!","url":"https:\/\/blog.besharp.it\/it\/author\/damiano-giorgi\/"}]}},"_links":{"self":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/posts\/8127","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/comments?post=8127"}],"version-history":[{"count":4,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/posts\/8127\/revisions"}],"predecessor-version":[{"id":8151,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/posts\/8127\/revisions\/8151"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/media\/8134"}],"wp:attachment":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/media?parent=8127"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/categories?post=8127"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/tags?post=8127"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}