2. Escalat Horitzontal sobre arquitectures distribuïdes
Una estratègia diferent és la de distribuir l’aplicació en diferents components i augmentar el número de cadascun d’ells segons convingui. Aquí, és on trobem la clau principal, i és que, en lloc de dissenyar una aplicació de forma monolítica, la descomponem en diferents mòduls i cadascun d’ells executa una funció concreta. Només d’aquesta manera aconseguim créixer allà on és necessari en nombre de servidors (instàncies o nodes), en comptes d’augmentar CPU o la memòria d’un únic gran node, com passa en l’escalat vertical.
Si utilitzem l’escalat horitzontal, en tenir més d’una instància (servidor) per a cada servei, el que fem és balancejar les peticions entre els diferents nodes que donen aquest servei amb la possibilitat d’afegir més nodes segons les necessitats i la càrrega global de peticions.
Aquest balanceig de peticions ens ofereix un segon avantatge: l’alta disponibilitat del servei. Això es tradueix en la possibilitat de parar un node, sigui perquè té problemes o perquè necessitem realitzar algun tipus de manteniment com actualitzar el sistema operatiu, amb el que redirigirem les peticions cap als nodes restants de manera que l’usuari final no notarà cap interrupció de servei.
Addicionalment, una arquitectura distribuïda ens permet afrontar canvis en una part de l’aplicació sense afectar la resta facilitant el control de versions i la gestió del canvi. A més, ens ajuda també al fet que cada part de l’aplicació funcioni amb el sistema operatiu i versions més adequat, sense haver d’assumir compromisos ni tenir problemes de compatibilitat. Ara bé, l’escalat horitzontal també ens planteja una sèrie de reptes que hem de superar per a poder gaudir dels seus avantatges, per a això, serà necessari seguir un conjunt de bones pràctiques que veurem més endavant.
Exemples d’escalats
Un exemple d’arquitectura monolítica i que ha de créixer mitjançant escalat vertical és un Servidor Web amb una aplicació (PHP, Java, ASP, etc.) i una Base de dades (MySQL, SQL Server, etc.), tot executant-se en un mateix servidor.
Quan el nombre de visitants o el nombre de peticions simultànies en la base de dades fa que el nostre servidor arribi al màxim de memòria o CPU aquest deixarà de respondre i l’única cosa que podrem fer és parar l’equip, afegir més memòria RAM o CPU i tornar a encendre’l esperant que, els nous recursos addicionals siguin suficients per a assumir la càrrega. Si passat un temps baixa l’activitat i veiem que ja no necessitem aquells recursos extres i volem deixar de pagar-los, el que haurem de fer és similar: parar l’equip (un nou tall de servei), treure memòria RAM i/o CPU i tornar-lo a posar en marxa, i així successivament.
Tot això amb l’inconvenient afegit que un problema de recursos amb el servei web pot deixar sense memòria el servei de base de dades i viceversa, dificultant encara més les previsions i la gestió de la càrrega en moments crítics. És clar que això no és un bon exemple d’escalabilitat.
Quan pensem en arquitectures web distribuïdes probablement la primera idea que ens ve a la ment és separar la base de dades del servei web. D’aquesta manera cada funció és executada en un servidor diferent, cadascun pot tenir els recursos i versions del sistema operatiu que més s’adeqüin a la funció a realitzar, i si és necessari, podem afegir més nodes de cada tipus per a dividir la càrrega i augmentar la capacitat. Serà necessari que la nostra aplicació tingui en compte l’existència dels nodes addicionals, i aquí apareix un dels primers reptes.
Per a això, ens poden ser d’ajuda elements com els balancejadors de peticions web. En altres casos, el mateix codi de l’aplicació decideix enviar dades o peticions a diferents nodes per exemple quan tenim més d’una base de dades on guardem diferents tipus d’informació.
De totes maneres una arquitectura escalable al cloud va molt més enllà d’això, i per a aconseguir sistemes realment auto escalats i elàstics basats en plataformes cloud haurem d’incorporar un conjunt de metodologies i tecnologies addicionals.
