Microservices - Patterns

Come gestire al meglio un'applicazione a microservizi ?

• Ogni servizio dovrebbe leggere la propria configurazione da variabili d'ambiente.
• Ogni servizio dovrebbe verificare che il numero di richieste ricevute non superi delle soglie configurate.
• Ogni servizio dovrebbe eseguire un denial of service sulla porta su cui ascolta in modo da minimizzare il numero di richieste in arrivo.
• Ogni servizio dovrebbe essere sviluppato in modalità stateful.
• Ogni servizio dovrebbe avere embedded la propria configurazione in modo da girare nella stessa maniera in vari ambienti.

Ipotizzando che tutti i servizi di un'ipotetica applicazione a microservices espongano un entrypoint HTTP sulla porta 8080, applicando quale pattern di depoy si avrebbe un problema di binding ?

• Single Service per Host
• Service per VM
• Multiple Service per Host
• Service per Container
• Function / Lambda

Quale affermazione è vera nel contesto del pattern Saga ?

• Ogni azione svolta verso i servizi gestiti deve essere memorizzata per poter riprendere il processo dal punto interrotto.
• Ad ogni azione svolta verso i servizi gestiti deve poter essere associata un'azione contraria che annulla l'effetto dell'azione, tranne che per l'azione finale poichè chiude il processo.
• E' ragionevole che il componente che implementa Saga sia invocato in maniera sincrona.
• E' necessario che il datastore utilizzato dal componente che implementa il saga patern sia di tipo ad eventi.
• Saga Pattern prescrive l'utilizzo transazionale dei servizi che gestisce.

Quale deployment pattern scegliere per sfruttare appieno un'ipotetica infrastruttura VMWare ?

• Single Service per Host
• Service per VM
• Multiple Service per Host
• Service per Container
• Function / Lambda

Come responsabilità dovrebbero essere in carico ad un microservizio ?

• Tutte quelle proprie di una singola business capability.
• Tutte quelle di un layer tecnologico, ad esempio: persistenza, business logic, user interface.
• Quelle conosciute dal team di sviluppo che si prende in carico lo sviluppo del microservizio.
• Disponibilità di piattaforme elastic cloud quali AWS, Google Cloud.
• Librerie per l'I/O non bloccante come quelle utilizzate da webserver quali Nginx.

Si ipotizzi un'applicazione a microservice in cui un servizio in particolare è soggetto a scale up in base al carico misurato su di esso. Qual'è il modo migliore per accedere a tale servizio, tra quelli elencati qui di seguito ?

• Predisporre uno short circuit breaker per evitare che un possibile problema in una delle istanze del servizio di diffonda alle altre.
• Predisporre un registry a cui le istanze del servizio di registrano e in caso di chiamata accedere al registry per ottenere l'indirizzo di una delle istanze.
• Far si che ogni servizio, allo start up, pubblichi un messaggio con le coordinate necessarie alla sua invocazione: IP e porta. I client interessati possono stare in ascolto e scoprire così il nuovo servizio.
• Instrumentare opportunamente le istanze dei servizi perchè loggino le chiamare ricevute, in modo da poter tracciare eventuali problemi.
• Anteporre davanti alle varie istanze un api gateway che nasconda ai client i dettagli delle varie istanze e che esponga ad essi un unico entry point.

Quale componente si prende normalmente in carico il controllo che il numero di richieste provenienti da un client esterno non superi un limite predefinito ?

• Service Registry
• Netflix Ribbon
• Api Gateway
• Circuit Breaker
• Netflix Eureka

Avendo applicato ad un servizio il pattern "Event Sourcing", quale pattern si dovrà ragionevolmente utilizzare per garantire la scrittura e la lettura di dati verso e dal microservice ?

• Events Generated by Application
• API Composition
• Saga
• Command Query Responsibility Segregation
• Event Retrieval

Quale di queste affermazioni è vera ?

• Un test end-to-end di un monolite e più complicato del test end-to-end di un'app a microservizi.
• L'utilizzo di stub nel test di servizi è sconsigliato.
• L'Anti Breakdown pattern garantisce, compatibilmente con la copertura che si riesce ad ottenere, che un servizio non venga meno alla retro compatibilità.
• E' complicato garantire che un servizio, durante la sua evoluzione non cambi il contratto dell'API esposta in una maniera non retrocompatibile. Per questo ci sono metodologie basati sui contratti definiti dai client.
• E' possibile mitigare l'effetto dell'evoluzione delle API applicando l'Ontology Test alle strutture dati dei messaggi scambiati tra i servizi.

In un'applicazione a microservizi dedicata alle forze dell'ordine è previsto un servizio che gestisce tutti i contatti avvenuti tra individui sospetti e un servizio che associa ad ogni individuo le targhe delle auto che possiede. Quale pattern utilizzeresti ?

• Database per Service. Per il primo un database relazionale, per il secondo un sistema LDAP.
• Shared Database, utilizzare lo stesso Database con l'accortezza di utilizzare schemi diversi.
• Database per Service. Entrambi potrebbero però utilizzare un key store.
• Shared Database, utilizzare lo stesso Database con le tabelle "CONTATTI" e "AUTO_POSSEDUTE".
• Database per Service. Il primo servizio potrebbe utilizzare un DB a grafi, il secondo un database relazionale.