És fàcil trobar en fòrums, seminaris i pàgines de proveïdors diferents maneres per descriure què és el cloud computing. La manca d'una definició comuna és deguda, en part, al fet que el cloud no és una tecnologia sinó un concepte de negoci que permet una nova forma d'accedir a una sèrie de serveis i recursos prèviament existents. Tot i això hi ha una sèrie de característiques fonamentals comuns en la majoria definicions:

• Agilitat en la provisió
• Pagament per ús
• Elasticitat

Aquest últim concepte es confon sovint amb la escalabilitat. L'elasticitat, aplicada a l'entorn dels servidors, es caracteritza per: 

• Funciona en ambdós sentits: ampliació o reducció dels recursos de la plataforma.
• És instantània i automàtica: No requereix la nostra intervenció.

L'elasticitat no és una tecnologia o un component, sinó una propietat de l'arquitectura de la nostra plataforma. Tot i que l'escalabilitat és intrínseca a l'elasticitat, la primera sol fer referència únicament a la capacitat d'una plataforma de créixer de forma planificada, mentre que en la segona es contempla la possibilitat de créixer o decréixer de forma automàtica segons una sèrie de condicions (mètriques, disparadors) establertes per endavant. L'elasticitat no és exclusiva del Cloud Computing, però és més fàcil aconseguir arquitectures elàstiques a partir de les eines que proporciona el Cloud, especialment a través de la virtualització i el pagament per ús.

Hi ha graus d'elasticitat dins d'una arquitectura de servidors per a l'allotjament d'aplicacions web. El més habitual és que la primera capa (servidors web) sigui elàstica, mentre que la capa de base de dades sigui simplement escalable.

Arquitectura Escalable LAMP

Una de les configuracions més comuns per a l'allotjament d'aplicacions web és LAMP (Linux, Apache, MySQL i PHP). Les arquitectures més habituals per a aquesta configuració es componen de servidors Web (Apache) i servidors de bases de dades (MySQL). El més habitual és que hi hagi diversos servidors Apache i un servidor MySQL (o dos, si es vol alta disponibilitat). Un balancejador reparteix les peticions entre els servidors Apache i tots consulten a la mateixa base de dades (figura 1).

Si el nombre de visites al web augmenta i els servidors Apache no són capaços d'atendre tota la demanda, podem afegir nous servidors Apache i configurar el balanç perquè reparteixi la càrrega entre tots. Això requereix la instal·lació i configuració manual dels nous servidors, canvis en les polítiques de balanceig i, en el pitjor dels casos, canvis en el codi de l'aplicació. En aquest cas hem aprofitat l'escalabilitat del sistema per créixer quan era necessari, però de forma manual. A més, això només ho fem quan és evident que no hi ha capacitat per servir a tots els usuaris (típicament, quan la web ja ha caigut).

El principal problema d'aquest plantejament és que la reacció és molt lenta i depèn de la detecció precoç del problema. Un cop detectat el problema mitjançant la monitorització 24×7 o a través de les queixes dels nostres clients, serà necessari un temps de resolució, al qual haurem de sumar-li els processos de contractació i presa de decisions necessàries. Tota aquesta demora en el procés de reactivació o ampliació del servei pot implicar pèrdues al negoci.

Un altre problema és la reducció de recursos. ¿Quan ens sentirem prou segurs per reduir el nombre de servidors un cop hagi passat el nostre "pic" de demanda? Si sabem que hi ha una demora significativa entre la planificació i la posada en marxa efectiva de nous recursos, probablement mai reduïm servidors instal·lats. Això ens porta per norma general a sobredimensionar la plataforma (i, per tant, pagar més del que hauríem).

Exemple d'una arquitectura LAMP elàstica

Com fem elàstica l'arquitectura prèviament plantejada?

En primer lloc, hem d'assegurar que els servidors Apache poden ser creats i destruïts sense que això afecti l'aplicació ni als altres nodes. Per a això cal convertir-los en servidors "stateless" (mancades d'estat). Això s'aconsegueix traient d'aquests servidors tota la informació de negoci: dades i configuració. Tant els fitxers de l'aplicació web com els paràmetres de configuració del software instal·lat han d'estar fora del servidor. Aquestes dades s'emmagatzemen en un dipòsit compartit per tots els servidors Apache. Es tracta d'un volum de dades a què qualsevol servidor Apache acabat de crear pot connectar-se per obtenir les dades d'aplicació i la seva configuració.

D'aquesta manera la creació d'un nou servidor Apache consisteix simplement en la clonació d'una plantilla única. Això és possible gràcies a la virtualització (un dels motius pels quals és més fàcil l'elasticitat en el cloud computing), que ens permet clonar servidors en qüestió de minuts. Aquesta plantilla és una instal·lació bàsica d'un servidor Apache stateless configurada per connectar-se al repositori de dades compartit a la recerca de la seva configuració i de les dades de l'aplicació que ha de servir.

Una vegada que podem assegurar que qualsevol clon pot fer la feina en tant que és creat, hem d'introduir un element més en l'arquitectura: el orquestrador cloud. El orquestrador és el responsable de detectar el nivell de servei que la plataforma està donant (mesurant el temps de resposta a l'usuari, el consum de CPU dels servidors, etc.) I disparar accions de creació o eliminació de servidors per mantenir un nivell de qualitat acceptable.

Aquest orquestrador pot ser el balancejador de càrrega (Zeus per exemple) o un sistema de monitoratge amb la capacitat de crear i destruir servidors dins del nostre entorn virtual (en general, això es fa invocant l'API d'un hipervisor com VMWare, Xen, etc.).

Exposem a continuació un exemple pràctic sobre com actuaria una arquitectura LAMP elàstica (figura 2):

En un moment donat augmenta el nombre de vistes a la web de forma molt pronunciada.

Els servidors comencen a saturar. Això es pot veure en el consum de CPU.

El orquestrador té definides una sèrie de regles que li indiquen com actuar quan la CPU dels servidors Apache està per sobre d'un determinat llindar durant un determinat període de temps. A partir d'aquests paràmetres decideix crear 4 nous servidors Apache i posar-los en producció. Per això, fa crides a la API del hipervisor VMware i modifica les polítiques de balanceig per incloure els nous servidors.

Posteriorment disminueix el nombre de visites de forma pronunciada, tornant a nivells anteriors.

El orquestrador té definides una sèrie de regles que li indiquen com actuar quan la CPU dels servidors està per sota d'un determinat llindar. A partir d'aquests paràmetres el orquestrador destrueix els 4 servidors creats. Primer els retira de les polítiques de balanceig i finalment els elimina invocant l'API del hipervisor.

El proveïdor de serveis només cobra per aquests 4 servidors durant el període que han estat actius (hores o dies). No hi ha tràmits administratius en el procés.

Elasticitat en bases de dades

L'objecció més evident en l'exemple anterior és: Què passa quan es saturen les bases de dades? La resposta depèn en gran mesura dels recursos emprats. Algunes tecnologies permeten implementar el concepte d'elasticitat en major o menor mesura. Així doncs Oracle RAC segueix un disseny altament escalable, el que la converteix en bona candidata per a arquitectures elàstiques (encara que els costos de llicència la fan romandre en el món de la escalabilitat planificada). SQL Server és un cas similar. Per contra, amb altres plataformes com MySQL, l'elasticitat és molt difícil i l'escalabilitat implica que els programadors entenguin l'arquitectura i modifiquin el seu codi per treballar eficientment amb ella. Això pot ser un inconvenient, ja que lliga les nostres aplicacions a una arquitectura molt concreta i limita la nostra flexibilitat per a migrar a altres solucions més endavant (figura 3).

En general, i encara que la idea de substituir l'escalabilitat planificada per l'elasticitat automàtica, són molt pocs els escenaris que justifiquen això en el món de les bases de dades.

Beneficis de l'elasticitat

• Mantenir la qualitat de servei davant els usuaris independentment del nombre de sol · licituds.
• Disminuir els temps d'indisponibilitat (arquitectures redundades).
• En cas d'indisponibilitat, es disminueix el temps de recuperació (els nodes no té estat, hi ha plantilles de tot). Al cap ia la fi és més fàcil substituir d'arreglar.
• Estalvi de costos per sobredimensionament mitjançant l'ús d'un model de pagament per ús.
• Es pot implementar polítiques de Autohealing.

L'elasticitat aplicada a les infraestructures TIC és un dels elements clau que permeten als proveïdors com Nexica oferir serveis de cloud computing, permetent ampliar o reduir els recursos sense canviar de servidor o realitzar detencions programades.