{"id":7381,"date":"2024-10-30T17:42:02","date_gmt":"2024-10-30T16:42:02","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=7381"},"modified":"2024-10-30T17:41:27","modified_gmt":"2024-10-30T16:41:27","slug":"halloween-special-infrastrutture-cloud-da-incubo-episodio-3","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/halloween-special-infrastrutture-cloud-da-incubo-episodio-3\/","title":{"rendered":"Halloween Special: Infrastrutture Cloud da Incubo – Episodio 3"},"content":{"rendered":"\n

“Hai visto cose orribili. Un esercito di creature da incubo. Ma non sono nulla in confronto a ci\u00f2 che \u00e8 venuto prima. Ci\u00f2 che si trova sotto. \u00c8 nostro compito placare gli Antichi. Come \u00e8 tuo essere offerto a loro. Perdonaci. E facciamo presto.”<\/em>   <\/p>\n\n\n\n

The Cabin in the Woods<\/strong><\/p>\n\n\n\n

Ciao cari amanti dell’horror! Bentornati nel nostro piccolo angolo spaventoso!<\/p>\n\n\n\n

Come molti di voi gi\u00e0 sanno, questo periodo dell’anno \u00e8 perfetto per raccontare tutte le storie spaventose su errori e problemi di design che si sono rivelati veri e propri mostri da combattere.\u00a0<\/p>\n\n\n\n

In questo articolo, vedremo cosa \u00e8 andato storto negli ultimi 12 mesi, perch\u00e9 e come evitare certe cose in futuro…\u00a0<\/p>\n\n\n\n

Come sempre, non siamo qui a puntare il dito contro nessuno: a volte, le pessime decisioni dipendono dal contesto e dal momento… e fanno anche un po’ crescere!<\/p>\n\n\n\n

Quindi, sedetevi, rilassatevi (se ci riuscite) e continuate con la lettura! <\/p>\n\n\n\n

Se ve li siete persi, ecco il primo<\/a> e il secondo<\/a> episodio.<\/p>\n\n\n\n

Complessit\u00e0 complessa<\/h2>\n\n\n\n

“A volte morto \u00e8 meglio.”<\/em><\/p>\n\n\n\n

Pet Sematary<\/strong><\/p>\n\n\n\n

<\/p>\n\n\n

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

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

Cosa fare quando troviamo un potenziale problema che si auto-alimenta e cresce senza che nessuno provi a fermare questo comportamento? <\/p>\n\n\n\n

La nostra storia inizia durante una soleggiata giornata estiva. <\/p>\n\n\n\n

Durante una Well-Architected Review, ci siamo imbattuti in un workload critico in esecuzione su EKS su EC2 ed un secondo cluster EKS basato su Fargate. Come sempre, alla ricerca di possibili miglioramenti su gestione ed elasticit\u00e0, abbiamo domandato se ci fosse un piano per adottare Fargate per il workload EKS su EC2.\u00a0<\/p>\n\n\n\n

Non c’era nessun piano: il workload poteva girare su Fargate, ma Karpenter si occupava dello scaling del cluster. Abbiamo pensato che, comunque, fosse una cosa pi\u00f9 che buona: Karpenter \u00e8 un ottimo strumento ed \u00e8 appena stato promosso uscendo dallo stato di beta. Eravamo piuttosto soddisfatti di questa scoperta perch\u00e9 \u00e8 stata presa in considerazione la possibilit\u00e0 di\u00a0 automatizzare l’eliminazione e l’aggiunta automatica di risorse quando necessario, anche se alcuni miglioramenti potevano essere fatti pensando all’aspetto della gestibilit\u00e0.\u00a0<\/p>\n\n\n\n

Abbiamo aperto una piccola parentesi per farci raccontare di come siano stati affrontati il tema dell’elasticit\u00e0 e il lavoro di ricerca e sviluppo fatto per comparare le soluzioni visto che il carico dell’applicazione era piuttosto imprevedibile. Alla fine abbiamo convenuto che fosse stato fatto un ottimo lavoro!<\/p>\n\n\n\n

Abbiamo quindi dato un’occhiata al cluster EKS basato su Fargate e abbiamo scoperto che veniva utilizzato… per eseguire Karpenter! <\/p>\n\n\n\n

A questo punto ci \u00e8 venuto naturale domandare se il primo cluster analizzato fosse stato migrato da Autoscaler a Karpenter. Come purtroppo temevamo la risposta \u00e8 stata no: avevano creato un secondo cluster per migrare l’applicazione.<\/p>\n\n\n\n

Eravamo perplessi: perch\u00e9 non usare Fargate (o, ancora meglio, aggiungere\u00a0un profilo Fargate al cluster e iniziare a migrare pod) se era necessaria una migrazione? La risposta \u00e8 stata semplice semplice: “Perch\u00e9 usiamo Karpenter!” A questo punto eravamo ancora pi\u00f9 confusi, ma dovevamo proseguire; abbiamo preso nota del fatto per il report (e questo articolo!).\u00a0<\/p>\n\n\n\n

La complessit\u00e0 legata all’esecuzione ed al mantenimento di uno strumento per gestire la scalabilit\u00e0 di risorse che in realt\u00e0 possono scalare nativamente ed in modo gestito porta sicuramente a errori e problemi in futuro (soprattutto per quanto riguarda aggiornamenti e modifiche). Invece di gestire un solo componente, occorre prendersi cura di un elemento aggiuntivo e valutarne l’interazione. <\/p>\n\n\n\n

In questo caso, un pattern potrebbe emergere: cosa succederebbe se in futuro venisse messo a disposizione\u00a0 un componente che implementa una GUI per Karpenter? Possiamo scommetterci: troveremmo la GUI in esecuzione durante la Well-Architected review! \u00c8 un ciclo infinito che aggiunge complessit\u00e0 a un sistema per gestire la sua complessit\u00e0.\u00a0<\/p>\n\n\n\n

Quando aggiungiamo un componente, dobbiamo valutarne l’impatto. Anche se sembra facilitare il nostro lavoro, dobbiamo sempre chiederci: c’\u00e8 un servizio gestito progettato per questo?<\/p>\n\n\n\n

CI\/CR (Continuous Integration, Continuous Rollback)<\/h2>\n\n\n\n

“Le forze diaboliche sono formidabili. Queste forze sono eterne ed esistono ancora oggi. La fiaba \u00e8 vera. Il diavolo esiste. Dio esiste. E per noi, come persone, il nostro stesso destino dipende da quale di essi scegliamo di seguire.” <\/em><\/p>\n\n\n\n

The Conjuring<\/strong><\/p>\n\n\n\n

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