Este post es el primero de una serie de artículos sobre cómo diseñar arquitecturas para plataformas cloud según la aplicación y el fin para los cuales son requeridas. Las siguientes entregas son: Exchange, Desktop as a Service y Disaster Recovery
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:
- Una capa de balanceo (compartido o dedicado)
- Una capa de servicio web, que tenía en las máquinas tanto el servidor web como el servidor de aplicaciones, cuyas configuraciones estaban íntimamente relacionadas 1 a 1
- Una capa de backend sobre base de datos SQL Server
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:
- Capa de CDN (Content Delivery Network), que se encarga de cachear la parte estática de la web y entregarla lo más rápidamente posible a los usuarios allí donde estén.
- Capa de balanceadores web, que hará que los usuarios estén uniformemente distribuidos entre los servidores web.
- Capa de servidores web, que puede ser rápidamente ampliada desplegando nuevos nodos especializados.
- Capa de balanceadores de aplicación.
- Capa de servidores de aplicación, que pueden ser rápidamente ampliados desplegando nuevos nodos especializados.
- Capa de bases de datos en SQL Server AlwaysOn, que provee a la plataforma de una alta redundancia y tolerancia a fallos, ya que cada servidor SQL Server tiene una copia propia de las bases de datos.
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.
Más sobre Hosting para Ecommerce
Contenidos relacionados: