Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Suggerimento
Questo contenuto è un estratto dell'eBook Architecting Cloud Native .NET Applications for Azure, disponibile in .NET Docs o come PDF scaricabile gratuito che può essere letto offline.
Un altro giorno, in ufficio, lavorando su "la prossima cosa grande".
Il tuo cellulare squilla. È il tuo selezionatore amichevole - quello che chiama quotidianamente con nuove opportunità interessanti.
Ma questa volta è diverso: Start-up, equity e un sacco di finanziamenti.
La menzione del cloud, dei microservizi e della tecnologia all'avanguardia spinge l'utente oltre il limite.
Dopo alcune settimane, sei ora un nuovo dipendente in una sessione di progettazione, occupato a definire l'architettura di un'importante applicazione di eCommerce. Stai per competere con i principali siti e-commerce.
Come lo costruirai?
Se si seguono le indicazioni degli ultimi 15 anni, è probabile che si crei il sistema illustrato nella figura 1.1.
Figura 1-1. Progettazione monolitica tradizionale
Si costruisce un'applicazione core di grandi dimensioni contenente tutta la logica di dominio. Include moduli come Identity, Catalog, Ordering e altro ancora. Comunicano direttamente tra loro all'interno di un singolo processo del server. I moduli condividono un database relazionale di grandi dimensioni. Il core espone le funzionalità tramite un'interfaccia HTML e un'app per dispositivi mobili.
Congratulazioni! È stata appena creata un'applicazione monolitica.
Non tutto è male. I monoliti offrono alcuni vantaggi distinti. Ad esempio, sono semplici da...
- costruire
- prova
- implementare
- risolvere problemi
- scalare verticalmente
Molte app di successo esistenti oggi sono state create come monoliti. L'app è un successo e continua a evolversi, iterazione dopo l'iterazione, aggiungendo altre funzionalità.
A un certo punto, tuttavia, si inizia a sentirsi a disagio. Ci si trova a perdere il controllo dell'applicazione. Man mano che il tempo va avanti, la sensazione diventa più intensa, e alla fine si entra in uno stato noto come Fear Cycle
:
- L'app è diventata così estremamente complicata che nessuna singola persona lo capisce.
- Si teme di apportare modifiche - ogni modifica ha effetti collaterali imprevisti e costosi.
- Le nuove funzionalità/correzioni diventano complicate, dispendiose in termini di tempo e costose da implementare.
- Ogni versione viene resa il più compatta possibile e richiede una distribuzione completa dell'intera applicazione.
- Un componente instabile può arrestare l'intero sistema.
- Le nuove tecnologie e i framework non sono un'opzione.
- È difficile implementare metodologie di distribuzione agile.
- L'erosione architetturale si manifesta mentre la base di codice si degrada con "correzioni rapide" senza fine.
- Infine, i consulenti arrivano e vi dicono di riscriverlo.
Sembra familiare?
Molte organizzazioni hanno affrontato questo ciclo monolitico di paura adottando un approccio nativo del cloud alla creazione di sistemi. La figura 1-2 mostra lo stesso sistema creato applicando tecniche e procedure native del cloud.
Figura 1-2. Progettazione nativa del cloud
Si noti che l'applicazione viene scomposta in un set di microservizi isolati di piccole dimensioni. Ogni servizio è indipendente e incapsula il proprio codice, i dati e le dipendenze. Ogni viene distribuito in un contenitore software e gestito da un agente di orchestrazione del contenitore. Anziché un database relazionale di grandi dimensioni, ogni servizio è proprietario del proprio archivio dati, il tipo di che varia in base alle esigenze dei dati. Si noti come alcuni servizi dipendono da un database relazionale, ma da altri database NoSQL. Un servizio archivia lo stato in una cache distribuita. Si noti come tutti i percorsi di traffico attraversano un servizio API Gateway responsabile del routing del traffico ai servizi back-end principali e dell'applicazione di molte preoccupazioni trasversali. Soprattutto, l'applicazione sfrutta appieno le funzionalità di scalabilità, disponibilità e resilienza disponibili nelle piattaforme cloud moderne.
Elaborazione nativa del cloud
Hmm... È stato appena usato il termine Cloud Native. Il tuo primo pensiero potrebbe essere: "Che cosa significa esattamente?" Un'altra parola chiave del settore concotta dai fornitori di software per commercializzare più roba?"
Fortunatamente è molto diverso, e spero che questo libro vi aiuterà a convincervi.
In breve tempo, il cloud nativo è diventato una tendenza trainante nel settore del software. È un nuovo modo per costruire sistemi complessi di grandi dimensioni. L'approccio sfrutta appieno le moderne procedure di sviluppo software, le tecnologie e l'infrastruttura cloud. Il cloud cambia il modo in cui si progettano, implementano, distribuiscono e operazionalizzano i sistemi.
A differenza dell'hype continuo che guida il nostro settore, il cloud nativo è for-real. Si consideri cloud Native Computing Foundation (CNF), un consorzio di oltre 400 grandi società. La sua carta è quella di rendere onnipresente il cloud native computing tra tecnologie e stack cloud. Come uno dei gruppi open source più influenti, ospita molti dei progetti open source in rapida crescita in GitHub. Questi progetti includono Kubernetes, Prometheus, Helm, Envoy e gRPC.
La CNCF promuove un ecosistema di open source e neutralità rispetto ai fornitori. Seguendo questa indicazione, questo libro presenta principi, modelli e pratiche cloud-native che sono indipendenti dalla tecnologia. Allo stesso tempo, vengono illustrati i servizi e l'infrastruttura disponibili nel cloud di Microsoft Azure per la costruzione di sistemi nativi del cloud.
Quindi, che cos'è esattamente Cloud Native? Siediti, rilassati e lasciaci aiutarti a esplorare questo nuovo mondo.