L’architettura dei servizi è un approccio di progettazione software che risolve un problema con una serie di servizi autonomi.

Analogia

Un’analogia ragionevole per l’architettura dei servizi è un’organizzazione come una banca. La banca suddivide il lavoro in una varietà di servizi come servizio clienti, servizi IT e servizi di gestione delle risorse umane. Ogni servizio è indipendente e può essere distribuito a diversi uffici. Ai clienti di ogni servizio viene offerto un contratto che stabilisce cosa ci si può aspettare dal servizio. Ad esempio, la gestione delle risorse umane può aiutare un team a reclutare nuovo personale con un modulo che il team compila per avviare il processo. La struttura dei servizi dell’azienda scompone il complesso problema della gestione di una banca in piccole porzioni di funzionalità gestionali.

Servizi

I servizi sono unità di software che eseguire una funzione. Sono utilizzati per suddividere problemi complessi in una serie di problemi più semplici. I servizi sono progettati anche per essere distribuiti separatamente. Questo è un grande vantaggio in quanto consente di creare sistemi altamente scalabili e resilienti.

Resilienza

La resilienza è un termine per software affidabile in condizioni del mondo reale che include vari stress e fallimenti. L’architettura dei servizi è una tecnica utile per costruire sistemi che continuano a funzionare quando le cose falliscono. Ciò viene fatto progettando i servizi in modo che siano autonomi in modo che non dipendano l’uno dall’altro. I servizi possono quindi essere distribuiti nell’infrastruttura cloud e scalati su e giù secondo necessità. Quando un’istanza ha esito negativo, i servizi sono abbastanza intelligenti da rilevarlo e automaticamente trova un’istanza che funzioni.

Servizi vs componenti

Servizi e componenti sono due modi diversi per suddividere il lavoro in blocchi gestibili e riutilizzabili. La differenza è che i servizi possono essere implementati da soli. I componenti vengono distribuiti con qualcos’altro e quindi non sono autonomi. I servizi possono essere costruiti da componenti. Allo stesso modo, i componenti possono utilizzare i servizi.

Architettura orientata ai servizi (SOA)

L’architettura orientata ai servizi era un termine iniziale per l’architettura dei servizi che è stata adottata e commercializzata da molti grandi fornitori IT che lo utilizzavano per vendere piattaforme SOA e middleware. Questa è stata una grande moda della tecnologia dell’informazione intorno al 2005 che ha visto molte implementazioni dall’alto verso il basso che hanno comportato l’acquisto di una serie di software e quindi la riprogettazione dei sistemi esistenti per adattarli a un paradigma SOA. Gran parte di questa attività perdeva completamente il punto della SOA e i fallimenti del progetto erano comuni. La confusione è piovuta quando gli esperti IT hanno promosso o criticato la SOA, spesso rendendo le cose il più complesse possibile.

Microservizi

Tutte le grandi idee e le sciocchezze Ciò che ha circondato la SOA all’apice della sua popolarità non ha impedito ad architetti esperti di utilizzare le sue idee fondamentali in modi efficaci e leggeri che hanno prodotto sistemi e applicazioni affidabili, scalabili, gestibili ed economici. Ciò si è evoluto in una nuova cultura della progettazione del software nota come microservizi, organizzata attorno a una serie di principi per la progettazione dei servizi.

Esempio

Una società di telecomunicazioni progetta un sistema di fatturazione come una serie di servizi implementabili separatamente. Ogni servizio è visto come un prodotto separato che può essere sviluppato, mantenuto e gestito da persone diverse. I servizi vengono distribuiti nel cloud e liberamente accoppiati. Quando un’istanza del servizio ha esito negativo, gli altri servizi passano automaticamente a un’istanza ancora funzionante. Sebbene il problema della fatturazione delle telecomunicazioni sia estremamente complesso, nessun singolo servizio nell’architettura è complesso in modo tale che ciascuno sia relativamente economico da sviluppare e gestire. I servizi sono essenzialmente auto-organizzati. Ciascuno pubblica un’API per gli altri servizi. Ognuno sa di cosa ha bisogno dagli altri servizi ed è abbastanza intelligente da indirizzare le istanze fallite per trovare servizi che rispondano. In altre parole, l’architettura non ha un controller centrale o middleware.

Panoramica: architettura del servizio
Tipo
Definizione	Un approccio alla progettazione di software che risolve un problema con una serie di servizi autonomi.
Concetti correlati