Microservizi e Applicazioni monolitiche: come creare e attaccare debolezze e vivere con gioia con tanti punti sul tabellone

All’indirizzo http://www.chessgames.com/perl/chessgame?gid=1020368 abbiamo un modo elegante e accademico per imparare come si creano le debolezze e si attaccano per creare sconquassi nella posizione nemica. E’ bello vedere come in questa game giocata tra Garry Kasparov vs Ulf Andersson Match (1985), Belgrade YUG, rd 5, Catalan Opening: Closed Variation (E06) 1-0 in 50 mosse il bianco profredisce piano piano e lento lento fino a prendersi tutta la scacchiera e a guadagnare materiale. Colpisce la totale rilassatezza nello sfruttamento dei vantaggi acquisiti come se il gioco degli scacchi fosse facile una volta apprese quelle sicure tecniche posizionali che ti portano a vincere facile senza mollare un millimetro e rischiare alcunché. Ma la questione qui é un’ altra é molto incasinata, definisce Umbriaway Consulting. Microservizi dunque. Ci sono buone possibilità di essere internati, se prendi in esame le espressioni seguenti come MVC pattern architetturale. Fullstack application. Front Page, single page. JAVA SPRING. DAO. AJAX. REST. SOAP. Perché ebay, amazon e netflix hanno in simpatia il modello architetturale dei microservizi? Perché i servizi Soap stanne perdendo terreno rispetto a quelli REST (rest is ok perché lavora con JSON)?  Ma alla fine che cosa é un microservizio? Base dati, API, JSON, JPA e JWT? Chiamate asincrone JQuery? Applicazioni ibride, posso costruire funzionalità separate con richieste su porte diverse usando tecnologie poco omogenee come Java, PHP o Pyton? Perché le WEB APP stanno perdendo terreno rispetto alle funzionalità offerte dai microservizi? Porta 8080? Porta 8081 o 8082? FAT JAR o WAR? Quindi cerchiamo di rispondere alle domande base. Che cosa é un MICROSERVIZIO e perché sta acquistando più interesse delle applicazioni MONOLITICHE? Immaginiamo di aprire l’agenda al mattino e di leggere i seguenti microservizi: andare a comprare il giornale, portare a spasso il cane, andare a salutare quelli di equitalia etc etc e immaginiamo di arrivare a fine giornata dopo aver svolto in sequenza tutto questo calderone di impegni vari e assortiti spesso dipendenti da imprevisti di orario o ritardi naturali. Ora se arrivo a fine giornata e li barro tutti in quel giorno posso anche considerare la giornata come un contenitore complessivo e globale composto da layer che hanno condizionato l’intera successione di eventi. Il microservizio rimane come concetto logico legato a quella singola attività svolta in maniera unica e singolare, fine, senza vincoli di sangue con qualcosa che viene prima o dopo. Altro esempio ho una molecola e ho l’unità elementare che la compone, l’atomo. Possiamo considerare un microservizio come un animo autonomo e indipendente, e più atomi scritti anche con linguaggi diversi su porte diverse, possono offrire servizi indipendenti riutilizzabili senza vincoli generali con una scatole contenitore che li contiene. Ma che differenza c’è tra WAR e FAT JAR? con il WAR da non confondere con il nuovo tormentone calcistico della domenica sportiva, posso deploiare le mie applicazioni usando uno strumento aggiuntivo che si chiama web application e che ascolta le richieste per soddisfarle, non a caso si sente udire spesso l’espressione http listener. Il FAT JAR come estensione di file é tipico del framework SPRING BOOT e tra le due tipologie la differenza sostanziale é che nel secondo caso non abbiamo bisogno di un software aggiuntivo come TOMCAT che svolge la funzione di APPLICATION SERVER in quanto la stessa struttura interna ha tutte le risorse per lanciare in maniera autonoma l’applicazione. Sostanzialmente quando arriva la richiesta questi microservizi non hanno bisogno di deploy in quanto chi é predisposto a spacchettare nonfa altro che istanziare e attivare la risposta. Entrambi i file hanno al loro interno come struttura del folder una cartella TEST che serve a svolgere i controlli logici formali sulle istruzioni impartite in produzione. Con il microservizio io posso dividere l’applicazione in vari layer svincolandomi da un meccanismo globale, immaginiamo un CRM che deve gestire ORDINI, CLIENTI, PAGAMENTI e che deve lavorare come la cassa interna di un orologio. Ma con i microservizi io posso delegare a tre soluzioni atomiche appunto a tre microservizi indipendenti le funzionalità che svolgono quelle operazioni specifiche senza renderle dipendenti da un contenitore e questo mi consente di lavorare singolarmente sopra ogni servizio senza dover modificare un TUTTO. WAR sta per WEB JAR, una contrazione che prende la W di web e il finale dell’ estenzione. Un altra differenza sostanziale tra i due file WAR e FAT JAR consiste nel fatto che nel secondo non ho necessità di gestione all’ interno della cartella webapp con il file XML predisposto in quanto il FAT JAR non ha la cartella indicata ma solo il MAIN e la folder RESOURCES dove si intuisce che il MAIN svolge un compito primario in quanto consente di lanciare l’applicazione senza passare per APPLICATION SERVER e quindi senza usare software aggiuntivo. Il MAIN istanzia quindi e manda in esecuzione le richieste su una parte di application server già inclusa che non richiede software esterni per successive lavorazioni. Questo mi permette una maggiore flessibilità e indipendenza sulle chiamate http tipiche delle architetture client-server e trasforma il microservizio in qualcosa di estremamente modulare e facile da gestire dal momento che intorno a lui la complessità viene annullata delle sue componenti interdipendenti a un complesso meccanismo che tiene conto di tutte le singole parti che vivono solo all’ interno di un gruppo. Con il microservizio l’atomo ha la sua vita autonoma senza inficiare la funzionalità della molecola. Sostanzialmente per le applicazioni monolitiche full stack strutturate a layer si preannuncia un momento di sviluppo un pò complicato dal momento che i microservizi sempre di più suonano alla porta con insistenza.

Annunci

Crea un sito o un blog gratuitamente presso WordPress.com.

Su ↑