LIBRE@DIARIO/MADRID
Un ecommerce es un entorno web muy particular. Sus altos requisitos a nivel de disponibilidad, velocidad y escalabilidad hacen que la plataforma tecnológica que lo soporta deba estar diseñada en base a algunos principios. A continuación planteamos una breve introducción a la arquitectura en entornos cloud escalables y flexibles –no sólo en infraestructuras como la de Amazon Web Services, nuestro enfoque es vendor-agnostic.
Una de las cosas que diferencian las webs de éxito con arquitecturas elásticas se resume en una sola frase: Cattle, not pets. When they get sick, you shoot them (Ganado, no mascotas. Cuando se ponen enfermos, les disparas). Estas palabras fueron pronunciadas por Bill Baker de Microsoft y repetidas hasta la saciedad posteriormente, convirtiéndose en un mantra dentro del diseño de infraestructuras, y clave en servicios elásticos como por ejemplo AWS, Azure, Rackspace o VDC.
Tras esta particular afirmación descansa uno de los mayores requisitos para arquitecturas elásticas: separación de roles claramente diferenciados con configuración automatizada. Si una instancia (o máquina virtual), se comporta de forma anómala, sale más rentable económicamente eliminarla y recrearla que pasar por todo el proceso de troubleshooting, que puede ir desde unos pocos minutos a varias horas en las que el negocio está afectado.
ARQUITECTURAS RECOMENDADAS
Como aclaración antes de entrar en materia, aunque los casos aquí expuestos hacen uso de tecnologías Microsoft, los consejos y prácticas son aplicables a infraestructuras Linux por igual cambiando únicamente el software al que se haga referencia.
Vayamos manos a la obra y enseñemos alguna arquitectura de ejemplo.
Esta arquitectura está basada en una experiencia real. El cliente no estaba conforme con la capacidad de crecimiento que podía tener su plataforma en momentos puntuales de sobrecarga, sobre todo tras lanzar promociones y campañas.
Comprende:
Aunque se trataba de una plataforma operativa, veamos que es lo que se puede optimizar cambiando esta arquitectura por la siguiente:
Aquí, respecto al caso anterior, se desdoblan roles y se añaden nuevas capas que ayudan a la eficiencia y al crecimiento de la misma. Por otro lado, se hace uso de Chef y scripting en Powershell DSC para la gestión de las configuraciones de los servidores y para evitar el drifting en los mismos. Estos son sus elementos principales:
Hay que decir que las capas de balanceadores no tienen por qué ser independientes, pero se han representado así para que sea más entendible y visual (en un caso normal sería únicamente una zona distinta de los mismos).
¿QUÉ VENTAJAS APORTA?
La segunda arquitectura tiene, en primer lugar, muchísimo potencial de ampliación. Al desplegar nodos especializados con configuraciones estandarizadas se reducen drásticamente los tiempos de provisión, desde horas o incluso días a minutos, pudiendo adaptarse a la demanda de cada momento. Además, en el caso de una incidencia en la capa de aplicación, no se sufre una parada completa de la plataforma ya que se pueden rehacer los nodos rápidamente y aplicarles la configuración de manera automática.
Por otro lado, gracias a elementos como la CDN para el caching y la distribución del contenido, se gana sustancialmente en rapidez, lo cual impacta positivamente en la experiencia de usuario y elementos asociados como el SEO.