Abbiamo parlato di IT/Ops e Batching, un ultimo approccio ricade sotto il nome di Proxy.
Quello che abbiamo detto è che a fronte di una domanda è sempre possibile identificare un responsabile per la risposta, parlando di tecnologia potremmo quindi dire che a fronte di una richiesta HTTP identificata da un URI c’è sempre un endpoint che si prenderà carico di gestire/orchestrare la risposta.
Per uno sviluppatore .NET viene quasi istintivo tradurre la frase precedente in “…a fronte di una richiesta HTTP identificata da un URI c’è sempre una Action MVC che si prenderà carico…”.
Ma HTTP non è ASP.Net MVC, nulla ci vieta, ad esempio, di piazzare davanti al nostro bel web server un reverse proxy, come ad esempio nginx, che ci permette di fare una serie di cose alquanto interessanti:
- prendere in carico la richiesta HTTP e in base ad una serie di regole decidere chi sia responsabile di gestirla
- data la risposta del responsabile, risposta che può contenere una serie di TAG/Attributi custom, applicare altre regole per decidere se ci sono altri attori che devono partecipare a quella risposta
- invocare gli altri attori
- aggregare le risposte così ottenute per comporre una risposta HTTP completa
È molto semplice e lineare, e se lo volete vedere in azione vi consiglio questa bella sessione del Team di Auto Scout 24.
È ancora più semplice: è tutto oro quel che luccica?
Come al solito non esiste la soluzione definitiva. Un reverse proxy come nginx è ovviamente un approccio interessante, approccio che porta con se tanta semplicità apparente e un paio di insidie nascoste, che il sottoscritto tende ad identificare sotto il termine di Orchestrator. E se a qualcuno si sono rizzati i peli sulla schiena pensando a BizTalk ha pensato bene.
All’aumentare della complessità le regole che abbiamo citato diventano il collo di bottiglia della soluzione di cui sopra, non necessariamente in termini prestazionali, quanto piuttosto in termini di gestione e complessità. Abbiamo cioè un robo che alla lunga diventerà il centro della nostra attenzione, robo in cui sarà concentrata tanta logica di business nonostante il robo non sia assolutamente pensato per gestire logica di business.
Ma anche un reverse proxy resta un possibile approccio che in certi scenari potrebbe rivelarsi semplice e diritto al punto con pochi fronzoli.
Post in questa serie:
Piccolo spazio pubblicità:
Tratterò di questi temi, e molto altro ancora, in un workshop durante l’edizione milanese di Codemotion 2016: Microservices development deep dive.