Porque cambiar a microservicios y como no morir en el intento
Arquitectura de Software
El uso de un enfoque de microservicios para el desarrollo de aplicaciones puede mejorar la resiliencia y agilizar su tiempo de comercialización, pero dividir las aplicaciones en servicios específicos ofrece complicaciones. Esto es lo que puede esperar.
Microservicios ha estado haciendo olas entre las organizaciones de desarrollo de aplicaciones con visión de futuro desde que el término se acuñó por primera vez en 2011. Unos pocos años más tarde, los microservicios están a punto de convertirse en la corriente principal, ya que, según una encuesta reciente de Nginx, el 36 por ciento de las empresas encuestadas están utilizando actualmente microservicios, con otro 26 por ciento en la fase de investigación. Pero, ¿qué es exactamente la arquitectura de microservicios y cuál es la adecuada para la cultura, las habilidades y las necesidades de su organización?
Revisemos las principales razones por las que debería considerar los microservicios para su próximo proyecto de desarrollo de aplicaciones, y los principales obstáculos que tendrá que superar para tener éxito.
El caso de los microservicios.
Una variante de la arquitectura orientada a servicios (SOA), los microservicios es un estilo arquitectónico en el que las aplicaciones se descomponen en servicios acoplados libremente. Con servicios en un nivel de granularidad fina y protocolos ligeros, los microservicios ofrecen una mayor modularidad, lo que hace que las aplicaciones sean más fáciles de desarrollar, probar, implementar y, lo que es más importante, cambiar y mantener.
Lo más probable es que su organización todavía está limitada con aplicaciones desarrolladas en la era monolítica, cuando se utilizaron arquitecturas centralizadas de múltiples niveles para crear aplicaciones completas en un solo código base. Ese modelo de servicio al cliente fue una excelente elección cuando los escritorios gobernaron la TI. Pero con el aumento de los dispositivos móviles y la nube, los datos de back-end siempre deben estar disponibles para una amplia gama de dispositivos, y esa arquitectura monolítica no lo hará fácil para usted, ya que cada vez que se realiza un cambio, todo la aplicación debe actualizarse, lo que abre la posibilidad de nuevos errores cada vez que intente agregar una característica o ajustarse a un nuevo contexto. Peor aún, con todo lo relacionado con un solo código base, no puede escalar una función o servicio específico; Tiene que ampliar la aplicación completa, lo que lleva a costos mucho más altos.
Con los microservicios, su código se divide en servicios independientes que se ejecutan como procesos separados. La salida de un servicio se utiliza como una entrada a otro en una orquestación de servicios de comunicación independientes. Microservices es especialmente útil para las empresas que no tienen una idea preestablecida de la variedad de dispositivos que soportarán sus aplicaciones. Al ser un dispositivo y una plataforma agnóstica, los microservicios permiten a las empresas desarrollar aplicaciones que brindan experiencias consistentes a los usuarios en una amplia gama de plataformas, que abarcan entornos de web, móviles, IoT, wearables y rastreadores de condición física. Netflix, PayPal, Amazon, eBay y Twitter son solo algunas de las empresas que actualmente utilizan microservicios.
Walmart Canadá, por ejemplo, reformuló su arquitectura de software para microservicios en 2012. La compañía, que no había podido manejar los 6 millones de páginas vistas por minuto que estaba soportando en ese momento, obtuvo resultados inmediatos con un aumento significativo en su tasa de conversión. durante la noche. El tiempo de inactividad también se minimizó, y la empresa pudo reemplazar el hardware caro con servidores virtuales x86 más baratos, lo que resultó en un ahorro general de costos entre el 20% y el 50% antes del año.
Incluso si su organización no es del tamaño de un Walmart o Amazon, los microservicios pueden proporcionar un gran valor. Estos son algunos de los beneficios que su organización disfrutará al cambiar a microservicios.
Beneficios de MicroServicios
Mayor resiliencia
Con los microservicios, toda la aplicación se descentraliza y se desacopla en servicios que actúan como entidades separadas. A diferencia de la arquitectura monolítica en la que una falla en el código afecta a más de un servicio o función, acá solo hay un impacto mínimo de una falla al usar microservicios. Incluso cuando varios sistemas se desactivan por mantenimiento, sus usuarios no lo notarán.
Escalabilidad mejorada
La escalabilidad es el aspecto clave de los microservicios. Debido a que cada servicio es un componente separado, puede escalar una sola función o servicio sin tener que escalar toda la aplicación. Los servicios críticos para el negocio se pueden implementar en múltiples servidores para aumentar la disponibilidad y el rendimiento sin afectar el rendimiento de otros servicios.
La habilidad de usar la herramienta correcta para la tarea correcta.
Con los microservicios, no tiene que atarse con un solo proveedor. En su lugar, tiene la flexibilidad de usar la herramienta adecuada para la tarea correcta. Cada servicio puede usar su propio idioma, marco o servicios auxiliares, al mismo tiempo que puede comunicarse fácilmente con los otros servicios en su aplicación.
Salir a producción en el menor tiempo
Debido a que los microservicios funcionan con servicios acoplados libremente, no es necesario volver a escribir todo el código base para agregar o modificar una función. Usted hace cambios solo a un servicio específico. Al desarrollar aplicaciones en incrementos más pequeños que se pueden probar y desplegar de forma independiente, puede hacer que sus aplicaciones y servicios se comercialicen más rápido.
Depuración y mantenimiento más sencillos.
Microservices también facilita la depuración y prueba de aplicaciones. Con módulos más pequeños que atraviesan un proceso continuo de entrega y prueba, su capacidad para entregar aplicaciones sin errores ha mejorado enormemente.
ROI mejorado con TCO reducido
Los microservicios también te permiten optimizar recursos. Con los microservicios, varios equipos trabajan en servicios independientes, lo que le permite implementarse más rápidamente y girar más fácilmente cuando lo necesita. El tiempo de desarrollo se reduce y el código de sus equipos será más reutilizable. Al desacoplar los servicios, no tendrá que operar en máquinas caras. Las máquinas x86 básicas lo harán. La mayor eficiencia de los microservicios no solo reduce los costos de infraestructura, sino que también minimiza el tiempo de inactividad.
Entrega continua
A diferencia de las aplicaciones monolíticas, en las que los equipos dedicados trabajan en funciones discretas como IU, base de datos, lógica del lado del servidor y capas tecnológicas, los microservicios utilizan equipos multifuncionales para manejar todo el ciclo de vida de una aplicación utilizando un modelo de entrega continua. Cuando los desarrolladores, las operaciones y los equipos de pruebas trabajan simultáneamente en un solo servicio, las pruebas y la depuración se vuelven fáciles e instantáneas. Con este enfoque de desarrollo incremental, el código se desarrolla, se prueba y se implementa continuamente, y puede usar el código de las bibliotecas existentes en lugar de reinventar la rueda.
Microservicios no es para todos los negocios.
Las empresas que han adoptado los microservicios han obtenido beneficios significativos y las organizaciones que ignoran este hecho pueden quedarse atrás. Pero mientras los microservicios parecen prometedores, no todas las empresas pueden capitalizar la arquitectura. Asegúrese de que su negocio sea lo suficientemente capaz para administrarlo. Aquí hay algunas advertencias organizacionales.
Necesitará estar equipado para un rápido aprovisionamiento y despliegue de aplicaciones.
Con el desarrollo incremental y la entrega continua, los microservicios mantienen a su organización en estado de alerta. El personal debe poder proporcionar al instante recursos para mantenerse al día con el ritmo requerido para aprovechar al máximo los microservicios. Si demora días o meses aprovisionar un servidor, se encontrará con serios problemas. Del mismo modo, debería poder desplegar rápidamente nuevos servicios o aplicaciones.
El monitoreo robusto es una necesidad
Debido a que cada servicio se basa en su propio lenguaje, plataforma y API, y estará orquestando múltiples equipos trabajando simultáneamente en diferentes entidades de su proyecto de microservicios, necesita un monitoreo robusto para monitorear y administrar efectivamente toda la infraestructura, porque si no lo hace saber cuándo falla un servicio o falla una máquina, puede ser imposible rastrear los problemas cuando surgen.
Debes abrazar la cultura devops.
Para trabajar en equipos multifuncionales, su empresa debe incorporar prácticas y cultura de devops. En un entorno tradicional, los desarrolladores se centran en las características y funcionalidades, y el equipo de operaciones está enganchado a los desafíos de producción. En los devops, todos son responsables de la provisión del servicio, y el fracaso.
Las pruebas pueden ser complejas
Con los microservicios, las pruebas no son sencillas. Cada servicio tiene sus propias dependencias, algunas directas, otras transitivas. A medida que se agregan funciones, aparecerán nuevas dependencias. Mantener un control sobre todo esto rápidamente se vuelve poco práctico. Además, a medida que aumenta su número de servicios, también lo hace la complejidad. Ya sea que se trate de errores en la base de datos, latencia de red, problemas de almacenamiento en caché o falta de disponibilidad del servicio, la arquitectura de los microservicios podrá manejar un nivel razonable de fallas. Por lo tanto, las pruebas de resistencia y la inyección de fallas son una necesidad.
Necesitas diseñar teniendo en cuenta el fracaso.
Diseñar para el fracaso es esencial. Debe estar preparado para manejar múltiples problemas de fallas, como el tiempo de inactividad del sistema, el servicio lento y las respuestas inesperadas. Aquí, el equilibrio de carga es importante, pero tener un plan B es otra opción importante. Cuando surge una falla, el servicio problemático aún debería ejecutarse en una funcionalidad degradada si
Artículos relacionados
Descubre los cientos de artículos en nuestro blog