De Monòlits a Microserveis
La majoria de nosaltres ha sentit a parlar de “Microservicios“. Els experts en Tecnologia poden donar una explicació més profunda, però pocs hem tingut l’oportunitat de participar en el desenvolupament de microserveis, ja que la resta d’aplicacions, en gran part, són “Monòlits”.
En primer lloc, tots dos termes descriuen una arquitectura de software recolzada, la diferència està en que el monòlit sol ser una única aplicació que “fa de tot”, com subscriure’s a un servei, administrar pagaments, emmagatzemar les dades, administrar una certa informació com a administrador, etc. mentre que els microserveis són una col·lecció de mini aplicacions que es comuniquen entre si, per exemple, cada aplicació controla només una “preocupació” o aspecte del servei: una aplicació per a subscriure’s, una altra per a pagaments, etc. Hi ha més detalls, per descomptat, dels quals esmentaré alguns.
Una història habitual
La història habitual comença amb unes quantes persones que tenen una “idea” que podria ser la pròxima “gran cosa”, per la qual cosa fan un primer pas amb una startup i es concentren en les necessitats bàsiques essencials de la seva “idea”, que podrien desenvolupar ells mateixos o més endavant alguns desenvolupadors per a convertir la “idea” en un “servei” en línia, és una aplicació monolítica amb una sola base de dades i desplegada en algun servidor, ja que ara mateix no tenen molt trànsit ni clients.
Al cap d’un temps, la “idea” comença a agafar forma i la demanda del “servei” en línia és cada vegada més gran,de manera que la startup ha de duplicar les instàncies implementades del monòlit en el backend per a poder satisfer la demanda. Després, més tard sorgeixen algunes “idees complementàries” que podrien millorar la “idea” original i fer que l’experiència d’usuari del client sigui més amigable.
Per a que aquestes noves “idees” estiguin disponibles per al client, s’ha d’expandir el codi de l’aplicació original. on – amb sort, l’arquitectura de software que utilitza la startup està oberta per a extensions -. A mesura que va passant el temps, amb més clients i més trànsit i, per descomptat, igual que amb qualsevol startup reeixida, més “idees” noves, el monòlit s’ha tornat 100 vegades més gran en base de codi i complexitat (amb una estructura de dades igualment complexa a la base de dades) i, per descomptat, moltes més instàncies del monòlit ara s’implementen en els múltiples servidors (potser un proveïdor de serveis en el núvol com AWS o Google Cloud).
Estat monòlit
Considerem un temps per a verificar quin és l’estat del monòlit. Com he esmentat abans, la base del codi ha de ser enorme, amb sort els desenvolupadors han aconseguit mantenir els principis SOLID * i el software està fet amb un Codi net * (aconseguir això en un monòlit és díficil), però encara així, el més probable és que hi hagi moltes dependències en l’arquitectura que fan que corregir errors i agregar funcions sigui més tediós per als desenvolupadors. Una altra cosa que sí que és certa, és que no tots els serveis que ofereix el monòlit tenen una gran demanda, és possible que uns tres serveis que sempre estan sota demanda, mentre que la resta de serveis com a pagament s’utilitzen de manera moderada i el servei de subscripció no és utilitzat tan intensament com els altres. Independentment, quan escalen el monòlit (implementant més instàncies per a satisfer les necessitats dels clients), han de duplicar tots els serveis (els més utilitzats i els que amb prou feines s’utilitzen), consumint més recursos (CPU, RAM, DB …) del que és necessari. En resum, tenim un codi gran i difícil de mantenir o ampliar, i un ús ineficient dels servidors o hardware.
Posada en marxa: canvi d’arquitectura?
Ara, hem arribat a un punt crucial per a la posada en marxa, haurien de canviar a l’arquitectura de microserveis?, per a respondre a aquesta pregunta s’han de tenir en compte moltes coses, negocis, finances, creixement, etc. Personalment només puc donar la meva humil opinió des de la perspectiva de l’Enginyeria Informàtica, i compartiré la meva pròpia experiència amb aquest repte.
Història del monòlit
La història del monòlit que vaig esmentar al principi és semblant a la majoria de les startups que ofereixen algun tipus de servei web en línia, de fet, va ser la història de la meva antiga empresa, on també vam tenir que decidir si dividiem el monòlit o no.
La situació era de creixement en el mercat de reserves turístiques i en números, però per desgràcia, la pandèmia va arribar i van fer fallida totes les planificacions futures, quedant-se en mode de supervivència. Des de fa un temps estic treballant per a una nova empresa Trentia, la cual te una resposta positiva a algo que es fundamental per mi: explorar diferentes maneres de desenvolupament amb altres perspectives i aproximacions per al meu creixement professional com ho és endinsar-me en el món dels microserveis.
Ara sóc membre d’un equip que està desenvolupant alguns microserveis que gestionen algunes funcionalitats i hi ha altres equips, organitzats per jerarquies que prenen possessió de les altres funcionalitats de la propietat.
Experiència com a desenvolupador de Software: avantatges dels microserveis
Com a desenvolupador de software veig molts avantatges a l’hora de treballar d’aquesta manera, només em preocupa un conjunt específic de serveis i no tots els serveis del monòlit.
El codi és elegant, la seva qualitat està més controlada, el manteniment és més fluid, la detecció d’errors és més ràpida i més continguda.
El que més m’agrada de l’enfoc dels microserveis és que expandeix els conceptes de desacoblament / encapsulació que tenim a la Programació Orientada a Objectes amb classes i mòduls a un conjunt de “mini Softwares”, especialment si s’utilitzen cues com Kafka o RabbitMQ, que fan que els “mini Softwares”, agnòstics entre si, gairebé es desacoblin de la dependència que intentem aconseguir quan programem.
Mètodes àgils o scrum: encara més eficient
L’ús de mètodes àgils o scrum amb aquesta arquitectura, ho fa encara més eficient, ja que el cicle és més curt i menys complicat, i això és així perquè, igual que en la programació, la majoria dels problemes es resolen mitjançant l’abstracció i l’enfocament de “dividir per regnar”.
Es poden desenvolupar múltiples microserveis per a resoldre un problema, i cadascun amb un marc / tecnologia diferent (Java, NodeJs, Python …), i a la majoria dels desenvolupadors ens agrada canviar de llenguatges de programació i intentar aprofitar els avantatges que ens aporta cada tecnologia per a una millor solució.
Desavantatges
Puc esmentar avantatges que trobo en els microserveis però sería massa tècnic, així que anem als desavantatges: personalment i com a programador trobo que un dels principals desaventatges és la duplicació de codi, especialment en el Model, DTO, DAO … etc. Un altre desavantatge és que he de saltar entre múltiples bases de codi, diferents bases de dades / caixets, registres, etc. mentre depuro un problema.
Una cosa que trobo a faltar dels meus dies de monòlit, és l’ús intensiu d’algorismes per a resoldre problemes complexos, encara que, amb l’enfocament de microserveis, la complexitat del problema es resol en múltiples mini algorismes en diferents microserveis. Però en general, per a mi, els beneficis dels microserveis superen els inconvenients.
Posada en marxa: variables per a canviar a microserveis
Tornem a la nostra hipotètica “posada en marxa”. Haurien de canviar també als microserveis? Bé, per a mi sí, però no és tan fàcil, mantenir microserveis requereix múltiples equips, cada equip controlat per algun domini o subdomini dels “serveis”, un servei en el núvol amb suficients recursos per a controlar múltiples microserveis escalables, per tant la decisió no és només tècnica, sempre hi haurà un anàlisi de costos i retorns d’inversió a tenir en comote. La startup genera suficients ingressos per a controlar l’expansió i el creixement de l’equip? El cost de la nova infraestructura? El temps que suposarà migrar / dividir el monòlit en microserveis? i moltes més preocupacions que no estic contemplant del tot, només puc donar fe que com a desenvolupador, prefereixo els microserveis en lloc dels monòlits, però, com tota la resta, els prefereixo quan es fa correctament.
