Cuando los microservicios se usan en exceso, la complejidad y los costos se disparan. Así es como consolidamos 25 servicios en 5, simplificando la arquitectura y la reducción de la nube sin sacrificar la estabilidad.
Es difícil predecir exactamente cómo evolucionará la arquitectura de microservicio, qué ventajas y contras surgirán y qué impacto a largo plazo tendrá. Los microservicios pueden ofrecer beneficios significativos, como escalabilidad, implementaciones independientes y un mejor aislamiento de fallas, pero también introducen desafíos ocultos, como una mayor complejidad, gastos generales de comunicación y costos de mantenimiento.
Si bien este enfoque arquitectónico brinda flexibilidad en la gestión de sistemas, priorizando componentes críticos y racionalización de procesos de liberación y prueba, no arreglará mágicamente todo; la arquitectura aún debe tener sentido. Aplicar la arquitectura incorrecta puede crear más problemas de los que resuelve. Los microservicios mal diseñados pueden conducir a ineficiencias, un acoplamiento apretado en lugares inesperados y una sobrecarga operativa que supera sus ventajas.
Punto de entrada: recuperación de la simplicidad arquitectónica
El proyecto que asumimos fue un ejemplo de arquitectura de microservicio aplicada sin adaptarlo a la forma y las necesidades reales del sistema. Las aplicaciones relativamente pequeñas y simples fueron excesivas. No solo se dividieron diferentes módulos y dominios en servicios separados, sino que incluso las capas individuales, como la API REST, los servicios que contienen lógica comercial y repositorios de bases de datos, se extrajeron en microservicios separados. Este es un caso clásico de resolver un problema easy con una herramienta compleja, sin adaptarse al contexto.
Nuestra misión period refactorizar el sistema, no solo a nivel de código, sino a nivel arquitectónico, con un enfoque principal en reducir los costos de mantenimiento a largo plazo. Para lograr esto, hemos decidido retener el enfoque de microservicio, pero con un nivel de granularidad más pragmático. En lugar de 25 microservicios, consolidamos el sistema en solo 5 servicios cuidadosamente agrupados, redujo las instancias de caché de 3 a 1 y migramos 10 bases de datos a 5.
Consultar el sistema
Antes de tomar cualquier decisión, realizamos una auditoría exhaustiva de la arquitectura del sistema, el rendimiento de la aplicación, la eficiencia y el costo common. Mirar solo el diagrama arquitectónico RAW rara vez es suficiente: queríamos observar el sistema en acción y prestar mucha atención a las métricas clave. Este análisis en vivo proporcionó información crítica sobre la configuración de las nuevas aplicaciones para cumplir mejor los requisitos originales del sistema al tiempo que cut back los costos operativos.
Acceso al proveedor de la nube
Para comprender realmente la arquitectura de un sistema, es esencial tener acceso al entorno del proveedor de la nube, con un amplio conjunto de permisos. Este nivel de visibilidad vale la pena significativamente. Cuanto más detallada su comprensión en esta etapa, más oportunidades descubrirá para la optimización y el ahorro de costos durante la consolidación.
Acceso a herramientas de monitoreo
La mayoría de los sistemas incluyen herramientas de monitoreo para rastrear su salud y rendimiento. Estas concepts ayudan a identificar qué métricas son más críticas para el sistema. Dependiendo del caso de uso, el issue clave puede ser la potencia calculadora, el uso de la memoria, el recuento de instancias o la concurrencia. En nuestro caso, descubrimos que algunos microservicios estaban siendo innecesariamente autoscalados. El uso de la CPU estaba aumentando, no debido a la falta de recursos, sino debido a las solicitudes de acumulación en los siguientes microservicios en la cadena que realizó cálculos pesados e interactuó con API externas. Comprender estos patrones nos permitió tomar decisiones informadas sobre las configuraciones de contenedores de aplicaciones y las estrategias de escala automática.
Refactorización, consolidación y optimización de la arquitectura en la nube
Consolidamos con éxito 25 microservicios en 5 aplicaciones independientes y autosuficientes, cada una respaldada por una de las 5 bases de datos estandarizadas, por debajo de un conjunto previamente fragmentado de 10 y una sola instancia de caché en lugar de 3. A lo largo de esta transformación, nos mantenemos en un principio de refactorización central: las entradas y salidas del sistema deben permanecer sin cambios. Internamente, sin embargo, la arquitectura y el flujo de datos se rediseñaron para mejorar la eficiencia y la mantenibilidad.
Definimos cuidadosamente los límites de dominio para determinar qué servicios podrían fusionarse. En la mayoría de los casos, se reunieron en una aplicación unificada dentro de un solo dominio de un solo dominio. Algunas aplicaciones requerían migraciones de bases de datos, lo que resulta en bases de datos consolidadas estructuradas en múltiples esquemas para preservar los límites heredados.
Aunque estimamos los requisitos de recursos para los nuevos servicios, el comportamiento de producción puede ser impredecible, especialmente cuando las pruebas de carga de trabajo previas al lanzamiento no son posibles. Para mantenernos seguros, aprovisionamos un búfer de rendimiento para manejar picos inesperados.
Si bien la reducción de costos period nuestro objetivo principal, sabíamos que estábamos lidiando con aplicaciones orientadas al cliente donde la estabilidad y la experiencia del usuario son lo primero. Es por eso que adoptamos un enfoque seguro y reflexivo: centrarnos en la consolidación y la optimización inteligentes sin arriesgar la confiabilidad. Nuestro objetivo no period solo reducir los costos, sino hacerlo de una manera que también mejorara el sistema sin afectar a los usuarios finales.
Desafíos y riesgos de la refactorización de la arquitectura
Conocimiento limitado de dominio comercial
Es un desafío difícil cuando trabaja con aplicaciones y dominios sin una visión profunda de la lógica comercial. Por un lado, no period estrictamente requerido ya que estábamos operando en un nivel de arquitectura más alto. Pero cada vez que necesitábamos probar y solucionar problemas después de la consolidación, tuvimos que investigar desde cero, a menudo sin una guía clara o experiencia en el dominio.
Falta de oportunidades de prueba
En proyectos de fase de mantenimiento, es común que el soporte de management de calidad dedicado o los probadores con conocimiento profundo del sistema no estén disponibles, lo que es totalmente comprensible. En este punto, a menudo confiamos en el trabajo realizado por desarrolladores anteriores: verificar qué tipos de pruebas existen, qué tan bien cubren el código y la lógica comercial y cuán efectivos son para atrapar problemas reales.
Limitaciones de consolidación paralela
La granularidad del sistema unique dificultó que más de un desarrollador trabajara para consolidar un solo microservicio simultáneamente. Por lo common, cada dominio fue manejado por un desarrollador, pero en algunos casos, tener varias personas trabajando juntas podría haber ayudado a prevenir problemas durante un proceso tan complejo.
Compatibilidad con atrasado
Cada aplicación consolidada tenía que ser 100% appropriate con los microservicios previos a la consolidación para permitir reversiones si fuera necesario. Eso significaba que no podíamos introducir ningún cambio de ruptura durante la transición, agregando presión adicional para acertar las cosas la primera vez.
Configuración distribuida
La configuración dispersa de diseño sobre granular del antiguo sistema en múltiples servicios y un servidor de configuración. La reconstrucción de eso en una configuración unificada requirió una investigación cuidadosa para localizar, alinear y centralizar todo en una sola aplicación.
Impacto del usuario ultimate
Dado que el sistema estaba orientado al cliente, cualquier brecha de error o funcionalidad después de la consolidación podría afectar directamente a los usuarios. Esto elevó las apuestas para cada cambio y reforzó la necesidad de un despliegue cauteloso y reflexivo.
La refactorización arquitectónica viene con riesgos y comprenderlos por adelantado es clave para entregar tanto la confiabilidad del sistema como la eficiencia rentable.
Lo que ganamos: menores costos, mayor confiabilidad y un sistema sostenible
Reducción de costos de nubes
Después de la consolidación, Los costos generales de la infraestructura de la nube se redujeron en un 82%. Este fue un resultado directo de la refactorización arquitectónica, la reducción de microservicios y el uso de recursos más eficiente.
Eficiencia de la herramienta de monitoreo
La nueva arquitectura también bajó la carga en herramientas de monitoreo externas, lo que llevó a una caída de hasta un 70% en los costos relacionados.
Ahorro de costos indirectos
Si bien no teníamos acceso completo a algunas métricas de facturación, sabemos que muchas herramientas cobran según factores como el volumen de solicitud, el recuento de microservicios y el tráfico interno. Simplificar el núcleo del sistema también trajo ahorros en estas áreas.
Mantenimiento simplificado
Contracción de 25 microservicios a 5 Redujo drásticamente el esfuerzo requerido para el desarrollo de características, los lanzamientos específicos del dominio y la gestión de la tubería de CI/CD. Una vez que eliminamos la fachada de complejidad, quedó claro que el sistema no period tan complicado como parecía. La incorporación de los nuevos desarrolladores ahora es mucho más rápido y más fácil, lo que también abre la puerta para repensar cuántos ingenieros son realmente necesarios para el apoyo continuo.
Despliegue de tiempo de inactividad cero
Como estábamos trabajando con un sistema orientado al cliente, minimizar el tiempo de inactividad para cada lanzamiento fue crítico. Al consolidar la funcionalidad en 5 aplicaciones de alcance de dominio claramente definidas, permitimos lograr implementaciones de tiempo de inactividad cero en la producción.
Complejidad reducida
La consolidación aclaró cómo funciona el sistema y les dio a los desarrolladores una visión más amplia de sus componentes. Con dominios cohesivos y lógica alojados en menos aplicaciones, ahora es más fácil seguir flujos comerciales, implementar soluciones eficientes, depurar problemas y escribir pruebas efectivas.
–
Cada decisión tomada en un momento dado generalmente se siente como la correcta, y a menudo lo es. Pero si algo sigue siendo importante con el tiempo, vale la pena volver a visitar esa decisión a la luz del nuevo contexto y las circunstancias en evolución. Como nuestro caso muestra claramente, tomarse el tiempo para reevaluar realmente puede dar sus frutos, tanto literal como figurativamente.
