Una introducció als Microservices

Últimament hi ha hagut molt debat i hype al voltant dels Microservices. Però què són els microservices? Per què hi ha tant soroll al voltant d’aquest terme? Espero que aquest post introductori et pugui ajudar a entendre què és un microservice i introduir-te en el tema.

Foto de Glen Carrie

Què són els Microservices?

Parafrasejant Martin Fowlers al seu article sobre Microservices, “l’estil arquitectònic de microservice és un enfocament per desenvolupar una única aplicació com un conjunt de petits serveis, cadascun executant-se en el seu propi procés i comunicant-se amb mecanismes lleugers, sovint una API de recursos HTTP”. Tot i que fa referència a les APIs HTTP, no és l’únic mecanisme per comunicar serveis, però s’està convertint en el més utilitzat a causa de la creixent popularitat dels serveis web.

És bastant habitual veure gent confonent-se entre llibreries i microservices quan llegeixen sobre el tema per primera vegada. No et preocupis, ens ha passat a tots. Són diferents en el sentit que les llibreries s’executen en el mateix procés que l’aplicació principal, i es comuniquen mitjançant crides de funció dins del mateix procés. Un altre error comú és confondre una arquitectura basada en microservices amb una arquitectura modular. Encara que són semblants no són exactament el mateix. És cert que els microservices són implícitament modulars però és fals que tota arquitectura modular utilitzi microservices. De fet, la majoria d’aplicacions modulars són monolítiques.

Com a desenvolupadors, de vegades tendim a organitzar el nostre codi al voltant de funcionalitats tècniques, com frontend, backend, helpers, llibreries, etc. Els microservices s’organitzen al voltant de capacitats de negoci i per això sovint es confonen amb els mòduls d’una aplicació modular. Vol dir que cada servei realitza una funcionalitat de negoci i dins d’aquest servei pots organitzar el codi com vulguis. Pots pensar en un servei com una aplicació independent que és capaç d’executar-se sola i té valor per si mateixa.

“Smart endpoints and dumb pipes” — amb aquesta frase la comunitat de microservices intenta resumir com s’hauria d’estructurar l’aplicació en termes de comunicació. La part intel·ligent de l’aplicació hauria de residir als serveis (endpoints) i la comunicació s’hauria de fer tan simple com sigui possible, utilitzant APIs REST o cues de missatges, com RabbitMQ o ZeroMQ. De fet, les cues de missatges són el segon enfocament més utilitzat per comunicar serveis, especialment aquells que executen operacions de llarga durada o que no són d’alta prioritat. Per exemple, si un servei necessita comunicar-se amb un altre que només envia correus electrònics, les cues de missatges són una bona opció.

Pros i cons

El terme microservice ja fa anys que existeix, però últimament, a mesura que creixen els serveis web, ha generat una mica d’hype al voltant seu. No és la solució definitiva per a totes les arquitectures de la teva aplicació, per això has de conèixer els pros i els contres.

> Disseny evolutiu

Aquest és probablement un dels avantatges més grans de l’arquitectura de microservices. A mesura que la teva aplicació creix, és fàcil connectar nous serveis amb noves capacitats de negoci. Com que la majoria d’aplicacions de software estan orientades al negoci i el mercat canvia tan ràpid, acabaràs adorant aquest avantatge.

> Múltiples llenguatges de programació

Cada vegada que comences una aplicació has de decidir en quin llenguatge la construiràs. De vegades tries un depenent de les teves habilitats i de vegades depenent de la millor opció per a l’aplicació en qüestió. A mesura que passa el temps i la teva aplicació creix, acabes tenint que aferrar-te al llenguatge de programació seleccionat i les tecnologies relacionades que vas triar. Llavors t’adones que algunes noves funcionalitats funcionaran millor en un altre llenguatge/framework. O encara pitjor, que aquella tecnologia no té una llibreria per utilitzar amb el teu llenguatge de programació. Aquí és on els microservices poden ajudar molt. Com que cada servei és una aplicació desacoblada i independent, pots utilitzar un llenguatge/tecnologia diferent per a cadascun, depenent de les teves necessitats. Per exemple, la teva aplicació està escrita en Ruby on Rails i vols integrar un xat utilitzant Node.js.

> Múltiples tipus de bases de dades

De manera similar a l’anterior, pots tenir diferents tipus de bases de dades a la teva aplicació. Per exemple, diguem que la teva aplicació utilitza MySQL per gestionar la majoria de les dades relacionals però per a un xat potser prefereixes utilitzar una base de dades de sèries temporals com InfluxDB. No sóc un expert en BD, no em prenguis la paraula literalment sobre quin tipus de BD és el millor per a un xat, és només un exemple.

> Unitats desplegables independents

Com he dit abans, un microservice és una aplicació independent i, com a tal, es pot desplegar de manera independent. Vol dir que cada cop que necessites canviar un servei no cal tornar a desplegar l’aplicació sencera. Et farà sentir més segur quan estiguis a punt de desplegar.

> Resiliència del sistema

Com a sistema desacoblat i distribuït, quan algun dels serveis falla (i ho farà) només fallarà una funcionalitat de la teva aplicació, però l’aplicació seguirà sent usable. A més, pots tenir un servei monitoritzant la resta dels serveis i si un d’ells falla el podrà reiniciar.

> Fàcil d’escalar

Imagina que la teva aplicació permet pujar imatges i aplicar-hi efectes. Alguns d’aquests efectes poden consumir molta memòria i no vols que això afecti la resta de l’aplicació. Utilitzant microservices pots afegir fàcilment memòria (o altres recursos) al servidor/procés que executa aquest servei. És fàcil escalar recursos depenent de les necessitats del servei.

> Gestionar massa serveis

Quan decideixes en quants serveis vols dividir la teva aplicació, és fàcil embogir amb els límits dels serveis i acabar tenint un munt de serveis que hauràs de desenvolupar i mantenir. Serà molt fàcil introduir complexitat innecessària al sistema, i per tant errors. Vés amb compte amb això.

> Duplicació de codi

De la mateixa manera que és agradable tenir la capacitat d’utilitzar diferents llenguatges de programació, també és molt fàcil tenir el mateix codi en diferents llenguatges. Quan passa dins del mateix llenguatge, alguns suggereixen utilitzar aquest codi com a llibreria però llavors estaràs introduint acoblament.

> Testing

El testing és un pro i un contra. Encara que és relativament fàcil provar un únic servei, pot ser un maldecap provar tot el sistema i la seva integració, ja que cada vegada que vols provar l’aplicació sencera has de configurar i posar en marxa cada servei.

> Asincronia

Les operacions asíncrones introdueixen complexitat en la seva coordinació i ho fan realment difícil quan necessites operacions síncrones o transaccionals.

Moltes d’aquestes no són realment un desavantatge sinó només una manca d’eines per automatitzar o monitoritzar. Com diu un amic meu: “Necessitem una eina!”.

Hauria d’utilitzar Microservices avui?

Aquesta és una gran pregunta que sento sovint. Començaria analitzant les necessitats de l’aplicació amb cura. El meu consell és que és millor començar petit i senzill però sense menystenir que la teva aplicació pot créixer i no vols patir-ho, sinó gaudir-ho. Sigues pragmàtic, no dogmàtic. És cert que hi ha pràctiques ben conegudes que funcionaran per a la teva aplicació però no tinguis por d’adaptar-les a les teves necessitats.

Un enfocament comú que jo també segueixo és començar l’aplicació monolítica però modular. Després d’això, comença a separar aquests mòduls en serveis a mesura que realment ho necessitis. No serà fàcil, ja que cada crida dins del mateix procés que vas fer l’hauràs de reescriure com una Remote Procedure Call, necessitaràs muntar un nou servidor/procés amb els seus propis recursos i configurar-los, però creu-me, serà més fàcil que haver de començar amb una aplicació fortament acoblada.

Form Follows Function

Aquest títol és un extracte d’una bonica cita de Louis Sullivan:

“Whether it be the sweeping eagle in his flight, or the open apple-blossom, the toiling work- horse, the blithe swan, the branching oak, the winding stream at its base, the drifting clouds, over all the coursing sun, form ever follows function, and this is the law. Where function does not change, form does not change.” — Louis Sullivan

***
per Francisco Méndez Vilas
Full Stack Developer a Redbooth

Referències

• http://martinfowler.com/articles/microservices.html (post de James Lewis i Martin Fowler sobre Microservices)
• http://www.infoq.com/minibooks/emag-microservices (Una bona lectura sobre microservices, amb molts casos d’ús reals)
• http://samnewman.io/blog/2015/04/07/microservices-for-greenfield/(article de Sam Newman sobre utilitzar Microservices des del principi d’un projecte greenfield)