Estamos entusiasmados de traer Transform 2022 en la persona el 19 de julio y prácticamente del 20 al 28 de julio.Únase a los líderes de IA y Data para conversaciones perspicaces y emocionantes oportunidades de redes.¡Regístrese hoy!
Para 2025, el 85% de las empresas tendrán un principio de nube primero, una forma más eficiente de alojar datos en lugar de locales.El cambio a la computación en la nube amplificado por Covid-19 y el trabajo remoto ha significado una gran cantidad de beneficios para las empresas: menores costos de TI, mayor eficiencia y seguridad confiable.
Con esta tendencia continuando en auge, la amenaza de interrupciones y interrupciones del servicio también está creciendo.Los proveedores de la nube son muy confiables, pero "no son inmunes al fracaso."En diciembre de 2021, Amazon informó haber visto múltiples API de Amazon Web Services (AWS) afectadas y, en cuestión de minutos, muchos sitios web ampliamente utilizados cayeron.
Entonces, ¿cómo pueden las empresas mitigar el riesgo de la nube, prepararse para la próxima escasez de AWS y acomodar picos repentinos de demanda?
La respuesta es la escalabilidad y la elasticidad: dos aspectos esenciales de la computación en la nube que benefician enormemente a las empresas.Hablemos sobre las diferencias entre la escalabilidad y la elasticidad y veamos cómo se pueden construir a nivel de infraestructura en la nube, aplicación y base de datos.
Comprender la diferencia entre escalabilidad y elasticidad
Tanto la escalabilidad como la elasticidad están relacionadas con el número de solicitudes que se pueden hacer simultáneamente en un sistema de nubes, no son mutuamente excluyentes;Ambos pueden tener que ser apoyados por separado.
La escalabilidad es la capacidad de un sistema para seguir respondiendo a medida que el número de usuarios y el tráfico aumenta gradualmente con el tiempo.Por lo tanto, es el crecimiento a largo plazo lo que se planifica estratégicamente.La mayoría de las aplicaciones B2B y B2C que obtienen el uso requerirán esto para garantizar la confiabilidad, el alto rendimiento y el tiempo de actividad.
Con algunos cambios menores de configuración y clics de botones, en cuestión de minutos, una empresa podría escalar su sistema en la nube hacia arriba o hacia abajo con facilidad.En muchos casos, esto puede ser automatizado por plataformas en la nube con factores de escala aplicados en los niveles de servidor, clúster y red, reduciendo los gastos de mano de obra de ingeniería.
La elasticidad es la capacidad de un sistema para permanecer respondiendo durante las explosiones a corto plazo o altos picos instantáneos en la carga.Algunos ejemplos de sistemas que regularmente enfrentan problemas de elasticidad incluyen aplicaciones de boletos de la NFL, sistemas de subastas y compañías de seguros durante los desastres naturales.En 2020, la NFL pudo apoyarse en AWS para transmitir en vivo su borrador virtual, cuando necesitaba mucha más capacidad de nube.
Una empresa que experimenta cargas de trabajo impredecibles pero no quiere una estrategia de escala previa prepasada podría buscar una solución elástica en la nube pública, con costos de mantenimiento más bajos.Esto sería administrado por un proveedor de terceros y se compartiría con múltiples organizaciones utilizando Internet público.
Entonces, ¿su empresa tiene cargas de trabajo predecibles, muy variables o ambas?
Elaborar opciones de escala con infraestructura en la nube
Cuando se trata de escalabilidad, las empresas deben tener en cuenta el sobreprovisionamiento o la subprovisión.Esto sucede cuando los equipos tecnológicos no proporcionan métricas cuantitativas en torno a los requisitos de recursos para las aplicaciones o la idea de escala de back-end no está alineada con los objetivos comerciales.Para determinar una solución de tamaño derecho, las pruebas de rendimiento continuas son esenciales.
Los líderes empresariales que leen esto deben hablar con sus equipos tecnológicos para descubrir cómo descubren sus esquemas de aprovisionamiento en la nube.Los equipos de TI deben medir continuamente el tiempo de respuesta, el número de solicitudes, la carga de la CPU y el uso de la memoria para observar el costo de los bienes (COG) asociados con los gastos de la nube.
Existen varias técnicas de escala disponibles para las organizaciones basadas en las necesidades comerciales y las limitaciones técnicas..Entonces, ¿escalarás o saldrás?
Vertical scaling involves scaling up or down and is used for applications that are monolithic, often built prior to 2017, and may be difficult to refactor.Implica agregar más recursos como RAM o energía de procesamiento (CPU) a su servidor existente cuando tiene una carga de trabajo aumentada, pero esto significa que la escala tiene un límite basado en la capacidad del servidor.No requiere cambios en la arquitectura de aplicaciones, ya que está moviendo la misma aplicación, archivos y base de datos a una máquina más grande.
Horizontal scaling involves scaling in or out and adding more servers to the original cloud infrastructure to work as a single system.Cada servidor debe ser independiente para que se puedan agregar o eliminar los servidores por separado.Implica muchas consideraciones arquitectónicas y de diseño sobre el equilibrio de carga, la gestión de sesiones, el almacenamiento en caché y la comunicación..La migración de aplicaciones heredadas (o anticuadas) que no están diseñadas para la computación distribuida deben refactorizar cuidadosamente.La escala horizontal es especialmente importante para las empresas con servicios de alta disponibilidad que requieren tiempo de inactividad mínimo y alto rendimiento, almacenamiento y memoria.
Si no está seguro de qué técnica de escala se adapta mejor a su empresa, es posible que deba considerar una plataforma de automatización de ingeniería en la nube de terceros para ayudar a administrar sus necesidades de escala, objetivos e implementación.
Pesar cómo las arquitecturas de aplicaciones afectan la escalabilidad y la elasticidad
Tomemos una aplicación de salud simple, que también se aplica a muchas otras industrias, para ver cómo se puede desarrollar en diferentes arquitecturas y cómo eso afecta la escalabilidad y la elasticidad.Los servicios de atención médica estaban fuertemente bajo presión y tuvieron que escalar drásticamente durante la pandemia Covid-19, y podría haberse beneficiado de las soluciones basadas en la nube.
En un alto nivel, hay dos tipos de arquitecturas: monolítico y distribuido. Monolithic (or layered, modular monolith, pipeline, and microkernel) architectures are not natively built for efficient scalability and elasticity — all the modules are contained within the main body of the application and, as a result, the entire application is deployed as a single whole.Existen tres tipos de arquitecturas distribuidas: microservicios y microservicios en el espacio..
La aplicación de salud simple tiene un:
Los servicios del hospital tienen una gran demanda y, para apoyar el crecimiento, deben escalar los módulos de programación de citas y registro del paciente..Esto significa que solo necesitan escalar el portal del paciente, no el médico u portales de consultorio.Desglosemos cómo se puede construir esta aplicación en cada arquitectura.
Arquitectura monolítica
Las startups habilitadas para la tecnología, incluida la atención médica, a menudo van con este modelo tradicional y unificado para el diseño de software debido a la ventaja de velocidad al mercado.Pero no es una solución óptima para las empresas que requieren escalabilidad y elasticidad.Esto se debe a que hay una única instancia integrada de la aplicación y una base de datos centralizada centralizada.
Para la escala de la aplicación, agregar más instancias de la aplicación con equilibrio de carga termina escalando los otros dos portales, así como el portal del paciente, a pesar de que el negocio no necesita eso..
La mayoría de las aplicaciones monolíticas utilizan una base de datos monolítica, uno de los recursos en la nube más caros.Los costos de la nube crecen exponencialmente con la escala, y este acuerdo es costoso, especialmente con respecto al tiempo de mantenimiento para los ingenieros de desarrollo y operaciones.
Otro aspecto que hace que las arquitecturas monolíticas no sean adecuadas para apoyar la elasticidad y la escalabilidad es el tiempo medio a la inicio (MTTS): el momento en que se necesita una nueva instancia de la aplicación para comenzar.Por lo general, lleva varios minutos debido al gran alcance de la aplicación y la base de datos: los ingenieros deben crear las funciones de soporte, dependencias, objetos y grupos de conexión y garantizar la seguridad y la conectividad a otros servicios.
Arquitectura basada en eventos
La arquitectura basada en eventos es más adecuada que la arquitectura monolítica para la escala y la elasticidad.Por ejemplo, publica un evento cuando sucede algo notable.Eso podría parecer comprar en un sitio de comercio electrónico durante un período ocupado, ordenando un artículo, pero luego recibir un correo electrónico diciendo que está agotado.La mensajería asíncrona y las colas proporcionan retroceso cuando la parte delantera se escala sin escalar la parte trasera mediante las solicitudes de colas.
En este estudio de caso de aplicación de salud, esta arquitectura distribuida significaría que cada módulo es su propio procesador de eventos;Hay flexibilidad para distribuir o compartir datos en uno o más módulos..Hay cierta flexibilidad a nivel de aplicación y base de datos en términos de escala, ya que los servicios ya no están acoplados.
Arquitectura de microservicios
Esta arquitectura ve cada servicio como un servicio de un solo propósito, brindando a las empresas la capacidad de escalar cada servicio de forma independiente y evitar consumir recursos valiosos innecesariamente.Para la escala de la base de datos, la capa de persistencia se puede diseñar y configurar exclusivamente para cada servicio para la escala individual.
Junto con la arquitectura basada en eventos, estas arquitecturas cuestan más en términos de recursos en la nube que las arquitecturas monolíticas a bajos niveles de uso.Sin embargo, con el aumento de las cargas, las implementaciones de múltiples múltiples y en los casos en que hay explosiones de tráfico, son más económicos.El MTTS también es muy eficiente y se puede medir en segundos debido a los servicios de grano fino.
Sin embargo, con la gran cantidad de servicios y la naturaleza distribuida, la depuración puede ser más difícil y puede haber mayores costos de mantenimiento si los servicios no están completamente automatizados..
Arquitectura basada en el espacio
Esta arquitectura se basa en un principio llamado procesamiento espaciado por tupla: procesadores paralelos múltiples con memoria compartida.Esta arquitectura maximiza tanto la escalabilidad como la elasticidad a nivel de aplicación y base de datos.
Todas las interacciones de la aplicación tienen lugar con la red de datos en memoria.Las llamadas a la cuadrícula son asíncronas, y los procesadores de eventos pueden escalar de forma independiente.Con la escala de la base de datos, hay un escritor de datos de fondo que lee y actualiza la base de datos.Todas las operaciones de inserción, actualización o eliminación son enviadas al escritor de datos por el servicio correspondiente y en cola para ser recogidas.
MTTS es extremadamente rápido, generalmente toma algunos milisegundos, ya que todas las interacciones de datos son con datos en memoria.Sin embargo, todos los servicios deben conectarse al corredor, y la carga de caché inicial debe crearse con un lector de datos.
En esta era digital, las empresas quieren aumentar o disminuir los recursos de TI según sea necesario para satisfacer las demandas cambiantes.El primer paso es pasar de grandes sistemas monolíticos a la arquitectura distribuida para ganar una ventaja competitiva: esto es lo que han hecho Netflix, Lyft, Uber y Google.Sin embargo, la elección de la arquitectura es subjetiva, y las decisiones deben tomarse en función de la capacidad de los desarrolladores, la carga media, la carga máxima, las limitaciones presupuestarias y los objetivos de crecimiento empresarial.
Sashank es un emprendedor en serie con un gran interés en la innovación.
DataDecision Makers
¡Bienvenido a la comunidad VentureBeat!
DataDecisionmakers es donde los expertos, incluidas las personas técnicas que hacen trabajo de datos, pueden compartir información e innovación relacionadas con los datos.
Si desea leer sobre ideas de vanguardia e información actualizada, las mejores prácticas y el futuro de los datos y la tecnología de datos, únase a nosotros en Datecisionmakers.
¡Incluso podría considerar contribuir con su propio artículo!
Lea más de DataDecisionmakers
