En Jitterbit, nuestra misión es simplificar incluso los desafíos de conectividad más complejos y permitir que cualquiera se conecte en el mundo digital actual. Si bien enfatizamos que no necesita ser un desarrollador para usar los productos de Jitterbit, detrás de cada gran solución de software hay un equipo de desarrolladores fantásticos. En la charla técnica de Jitterbit blog serie, los miembros del equipo de desarrollo de Jitterbit nos dan una idea de cómo construir una plataforma en la nube de clase empresarial y los desafíos que tuvieron que resolver en torno a la multiempresa, la escalabilidad y la seguridad.
Esta semana, Pankaj Arora, nuestro director sénior de tecnología, analiza cómo diseñar y diseñar una plataforma de nube de clase empresarial altamente escalable.
La Nube ofrece a las empresas una poderosa forma de ofrecer sus productos y servicios a la que es fácil acceder desde cualquier lugar y en cualquier dispositivo. También proporciona enormes beneficios al proveedor, incluida la visibilidad de cómo se utiliza su oferta, un rápido desarrollo e implementación y reducciones generales en los costos de mantenimiento y TI. Como resultado, casi todos company hoy busca que sus soluciones estén disponibles en la nube.
Pero hay mucho más para convertirse en una verdadera nube company en lugar de instalar software en un servidor alojado y colocar "Nube" en sus materiales de marketing.
Hace poco conversé con un estratega de tecnología y notaron que alrededor del 75 % de las empresas quisieran migrar sus ofertas empresariales heredadas a la nube. Sorprendentemente, el 90 % de ellos redacta un plan inicial que se basaría en una arquitectura en la que sus aplicaciones heredadas simplemente se implementarían en un servidor en la nube de acceso público. Este enfoque niega todos los beneficios que ofrece la nube.
La creación de una verdadera plataforma en la nube multiinquilino requiere resolver una serie de diferentes tipos de desafíos, como seguridad, confiabilidad, escalabilidad, alta disponibilidad, tolerancia a fallas, registro, monitoreo, sistema de notificación, capacidad de implementación continua y más.
En la publicación de hoy, analizaremos más a fondo cómo manejamos el desafío de la "escalabilidad" al desarrollar nuestra plataforma de integración en la nube de múltiples inquilinos.
El grado de escalabilidad de una aplicación está ligado a su capacidad para escalar vertical y horizontalmente. En un entorno de nube, esto significa diseñar servicios que atiendan solicitudes externas que se escalen para que puedan aprovechar los sistemas de back-end internos, como bases de datos, cachés, capas de mediadores, procesos por lotes (motor analítico, motor de recomendaciones), etc. para manejar solicitudes prácticamente infinitas en un tiempo razonable. breve cantidad de tiempo. No siempre es posible predecir la cantidad de usuarios que acceden a su plataforma. Diseñar una arquitectura que tenga esto en cuenta en el modelo de múltiples arrendatarios ayuda a convertir esta incertidumbre en un problema de escalabilidad genérico.
Escalado vertical
La escalabilidad vertical implica agregar recursos como CPU o memoria adicionales a un solo nodo en un sistema, y esto debería ser lo primero en lo que debe pensar al escalar sus servicios. Es muy importante diseñar sus aplicaciones para que utilicen estos recursos de manera óptima. Tome el caso de uso común para nuestra plataforma de nube de integración híbrida, donde las operaciones de integración son atendidas por un nodo de servidor local o en la nube. Aquí los servicios deben tomar una solicitud para ejecutar integraciones, pasar la solicitud a los nodos del servidor y continuar atendiendo más solicitudes. La capa de servicios no debe depender de los procesos que ocurren en varias capas del sistema ni estar bloqueada por ellos. Como tal, es muy importante tener una arquitectura asincrónica basada en eventos.
Una forma sencilla de entender la arquitectura asíncrona es pensar en su arquitectura como un restaurante. Un camarero toma los pedidos de una mesa y se los pasa al chef. Mientras que el chef, el corredor de alimentos y el ayudante de autobús se encargan de actividades como cocinar, servir y limpiar, el mesero continúa sirviendo a nuevos clientes y realiza comprobaciones al final del servicio.
Es muy importante mantener la asincronía mientras el sistema funciona con todos los componentes, como la base de datos, la caché y la capa mediadora. Pasar la carga a nodos de servidor agrupados y de alta disponibilidad que ejecutan integraciones libera los recursos para que la capa de servicio tome más solicitudes y responda cuando se completen los procesos.
Escala horizontal
La siguiente consideración clave debe ser que los servicios estén escritos de manera que no importe cuántas instancias de esos servicios se están ejecutando y qué sistema compartido está realizando transacciones en un momento dado. Esto le da a nuestra plataforma en la nube flexibilidad para escalar automáticamente la capa de servicios. Cada parte del backend tiene alta disponibilidad y es autoescalable para mantenerse al día con la demanda de contenedores de servicios en crecimiento.
Sin embargo, no podemos tener contenedores infinitos que ejecuten capas de servicio que usen componentes compartidos. Ese no es el diseño óptimo. Volvamos a nuestro ejemplo del restaurante. Con el escalado vertical, un solo restaurante podría volverse altamente escalable al agregar más personal, pero en cierto punto, la cantidad de recursos (cocineros, corredores, ayudantes de autobús) alcanzará un punto de saturación. Para escalar aún más, este negocio necesitaría abrir ubicaciones adicionales que ayudarían a distribuir a los clientes y equilibrar la carga.
Es mejor dividir toda la plataforma en múltiples zonas, con cada zona comportándose como una réplica de la zona inicial. Esto nos permite usar varias zonas para equilibrar la carga de las necesidades futuras.
Este modelo tiene múltiples ventajas:
1. Posible escalado horizontal infinito, ya que podemos incorporar cualquier número de zonas
2. Tolerancia a fallas, en caso de que toda la zona falle debido a un desastre natural
3. Separación de datos, en el caso de una plataforma SaaS que requiera una segregación de metadatos incluso basada en la ubicación, como para las zonas de EE. UU., EMEA, etc.
El resultado deseado aquí es que la experiencia de un usuario sea la misma sin importar dónde se encuentre y en qué zona se encuentre. No se debe requerir la intervención manual de un usuario para realizar el trabajo.
En nuestros nube de integración híbrida blog, discutimos cómo nos encontramos con el desafío de usar una capa mediadora de una manera que admitiera una escala vertical limitada. Al escribir nuestra propia capa de conexión sin bloqueo personalizada basada en el transporte HTTPS seguro, pudimos ampliar la arquitectura para tener una escala vertical de 50x. Por supuesto, también es escalable horizontalmente. Esta combinación de escalamiento vertical y horizontal nos dio una capa menos costosa y fácilmente extensible para satisfacer nuestras crecientes necesidades.
Optimización del uso de componentes compartidos:
Los componentes compartidos deben ser escalables y de alta disponibilidad para admitir la plataforma en la nube. Pero los componentes compartidos se comparten y, como resultado, no son tan escalables como la capa de servicios. Es muy importante cuidar algunos componentes que pueden ser sensibles a una carga elevada, por ejemplo las bases de datos. Un modelo puede ser priorizar y poner en cola el uso de componentes compartidos donde múltiples cargas simultáneas de alto volumen pueden causar problemas. La priorización puede reducir la carga y mitigar el error en cualquier solicitud de misión crítica. En nuestro restaurante, la cocina es un componente compartido y, si bien el mesero puede tomar el pedido de un comensal para un aperitivo, un plato principal y un postre, la cocina priorizará la cocción de estos artículos y equilibrará su carga.
Otra forma de abordar la carga puede ser el almacenamiento en caché de datos que rara vez cambian para evitar un uso elevado de esos componentes. Si las papas fritas son un artículo popular en el menú, el restaurante puede decidir "almacenar" un lote continuo en lugar de freírlas por pedido.
Monitorización de componentes:
Finalmente, es muy importante monitorear cada componente y conocer sus limitaciones. El sistema debe poder aumentar el ancho de banda automáticamente y en el momento adecuado para mantener los sistemas en funcionamiento según las necesidades de la plataforma en la nube. El monitoreo puede ser externo o iniciado por la aplicación, pero en cualquier caso, el objetivo final es permitir que el sistema se escale automáticamente en función de la carga.
En el proximo blog post, hablaremos sobre monitoreo, registro y otros elementos de la arquitectura.
