La intención de este artículo es ayudar a aquellos que están considerando una arquitectura de microservicios a entender qué partes de la aplicación se ven más afectadas por el nuevo proceso de diseño, y luego tomar una decisión informada. También cubriremos cómo se pueden aprovechar las ofertas de la nube en este espacio, y algunos pasos básicos para empezar a recorrer el camino de los microservicios.
Ventajas y desventajas de los microservicios
Los microservicios tienen ventajas y desventajas significativas. Sopesar los aspectos positivos y negativos nos ayudará a determinar si el beneficio compensa el coste y si las desventajas son algo con lo que su organización puede vivir a largo plazo. Profundicemos en las desventajas y ventajas, y veamos si los microservicios son la respuesta adecuada para su espacio problemático.
Desventajas de los microservicios
Varias de las desventajas de los microservicios son intencionales al diseño. El deseo de evitar estas desventajas puede conducir a problemas más grandes y, a veces aterrizar con un "microservicio-monolito", sufriendo lo peor de ambos enfoques.
Al considerar cada una de estas desventajas, piense en qué patrones y/o procesos necesitará adoptar su equipo u organización para asegurarse de que está preparado para manejarlas sin caer en viejos hábitos. Un ejemplo de esto es cómo las medidas de seguridad mejoradas dificultan el acceso, pero pueden eliminar el único punto de fallo en la protección de tus activos.
1. LA COMPLEJIDAD ESTRUCTURAL DE LA SOLUCIÓN DE MICROSERVICIOS CRECE RÁPIDAMENTE
En una arquitectura de microservicios, añadir comportamientos al sistema y ampliar los problemas que está resolviendo, significa añadir estructuras y servicios adicionales para lograrlo.
El mantenimiento de esta estructura se convierte en un espacio problemático cada vez mayor. Gran parte de esta complejidad adicional puede gestionarse con la base DevOps y las herramientas de automatización adecuadas. Pero sin ellas, puede convertirse en una pesadilla de mantenimiento.
2. CUANDO COMPARTIR INFORMACIÓN Y DATOS ENTRE MICROSERVICIOS SE CONVIERTE EN UNA PREOCUPACIÓN
Cuando los servicios necesitan datos de múltiples dominios para realizar una tarea, nos enfrentamos a la implementación de patrones de integración (un buen tema a explorar si se decide implementar microservicios).
Uno de los patrones de integración más comunes es la doble recuperación de datos o el almacenamiento duplicado. Acabamos intercambiando espacio de almacenamiento por separación de comportamientos. Tratar de evitar este inconveniente puede crear problemas mucho mayores y resultar en un único punto de fallo para todo el sistema.
3. LA MODIFICACIÓN DEL COMPORTAMIENTO TRANSVERSAL IMPLICA MÚLTIPLES MICROSERVICIOS
Cuando se trata de preocupaciones transversales como el registro, la auditoría o la seguridad, necesitamos diseñar una solución que funcione a través de múltiples servicios o que replique estos comportamientos a través de un conjunto compartido de utilidades. Si compartimos ese conjunto de utilidades, podemos crear restricciones sobre el cambio y el despliegue.
Es importante crear utilidades con un versionado adecuado que no acople innecesariamente el sistema a otras versiones (versión del marco de trabajo, por ejemplo) o que tenga cambios perjudiciales que restrinjan la adopción.
Ventajas de los microservicios
Las ventajas de los microservicios no son menos intencionadas en el diseño que las desventajas.
1. LA SEPARACIÓN DE PREOCUPACIONES ES ESTRUCTURAL
Cuando se construyen sistemas complejos, evitar consecuencias no deseadas requiere un cuidado y diligencia significativos. A menudo, esto se basa en el conocimiento y la disciplina del equipo de desarrollo de software.
Con los microservicios, parte de esta complejidad es estructural y puede limitarse. Los contratos de API pueden ser versionados y obsoletos según sea necesario. Algunas partes del sistema se pueden versionar varias veces más rápido que otras. Esta complejidad estructural también se automatiza más fácilmente con las herramientas DevOps modernas.
2. LA ESCALA ESTÁ ORIENTADA
Los sistemas construidos con una arquitectura de microservicios pueden tener escala dirigida aplicada a ciertas funciones escalando el hardware para ese conjunto de servicios. Esto permite gestionar más fácilmente el rendimiento y las ráfagas de demanda, a menudo de forma automatizada utilizando proveedores de nube modernos.
3. LA COMPLEJIDAD PUEDE DISPERSARSE EN MUCHOS EQUIPOS
Trabajar con sistemas monolito es difícil, especialmente para grandes grupos de desarrollo formados por varios equipos. La arquitectura de microservicios ayuda a compartimentar esto de alguna manera, al tiempo que permite que varios equipos trabajen en un sistema a gran escala con más flexibilidad y menos conflictos.
Esto no quiere decir que estén totalmente aislados, pero sí que lo están bastante más que una única base de código de una gran aplicación desarrollada como un monolito.
¿Por dónde empezar? Quizá por el principio
Al considerar un cambio de arquitectura, es importante fijarse en los procesos de toma de decisiones y de diseño. Si abordamos un cambio en la arquitectura pero no cambiamos nuestra forma de diseñar, es probable que volvamos a crear problemas peores que los actuales. ¿Por qué peores? Porque hoy tenemos sistemas basados en esos procesos.
En cambio, el futuro que estamos considerando probablemente tendrá conflictos entre los principios de diseño y los procesos implementados. El enfoque de diseño en el que nos apoyamos mucho para la transformación a microservicios es el Domain Driven Design.
Si no has explorado el Domain Driven Design, consulta este libro de Eric Evans. Da un gran conjunto de tácticas y pasos para avanzar. En resumen, es una estructura de diseño que ayuda a descomponer grandes ámbitos de complejidad en ámbitos más pequeños. Esto tiene la ventaja de limitar el alcance de la complejidad y permite variar el diseño en los espacios problemáticos. Cuando separamos los problemas en ámbitos empresariales y, a continuación, separamos las conexiones de los ámbitos con los conceptos raíz, cada uno de estos ámbitos puede verse influido por los demás, pero no controlado.
La similitud en la terminología y la segregación de responsabilidades al pasar del enfoque de diseño a la implementación que nos proporciona el Diseño Orientado a Dominios nos permite eliminar la complejidad de la comunicación y llegar rápidamente a la raíz de los problemas.
Sin esta coincidencia, los desarrolladores se ven obligados a traducir la intención a otro modelo mental. Esa traducción conlleva esfuerzo, confusión y, a menudo, una pérdida de fidelidad.
Componentes clave de los equipos de microservicios de éxito
Cuando nos fijamos en el paso a los microservicios, hay algunos temas comunes que vemos en los equipos de éxito. Vamos a profundizar en ellos ahora.
1. BUENOS PROCESOS DE AUTOMATIZACIÓN Y DEVOPS
No es fácil desplegar múltiples servicios en múltiples versiones y también garantizar que la fiabilidad no se vea afectada negativamente. Los equipos que hacen de esta preocupación un ciudadano de primera clase de su proceso de desarrollo tienen una tasa de éxito significativamente mayor que la mayoría (no sólo en microservicios). Los fundamentos de una tubería de construcción y liberación en entornos de prueba y producción pueden hacer un mundo de diferencia.
2. EQUIPOS DE DESARROLLO DISCIPLINADOS
La colaboración, el diseño, las pruebas y, en última instancia, el éxito del producto, se pueden resumir en la disciplina del equipo de desarrollo. Habrá un montón de atajos en el camino que pueden degradar el valor del sistema, y conducir a una deuda técnica a largo plazo. Si el equipo no puede ver y evitar esos atajos, tendrá dificultades. Esto parece sencillo, pero cuando el "camino corto" lleva 2 horas y el "camino correcto" lleva 6, incluso un propietario de producto se inclinará por el atajo.
La mayoría de las veces se trata de un compromiso que no se comprende y que conduce a importantes cambios en el futuro. La disciplina de diseño e implementación para un equipo es algo raro de encontrar, pero cuando se hace correctamente conduce a resultados sorprendentes.
3. PROBAR, PROBAR Y PROBAR MÁS
Descomponer la complejidad no la elimina, y hay que añadir más pruebas de las que a la mayoría de los equipos les gusta hacer. Las definiciones que transmiten las pruebas suelen encontrar errores antes de que se ejecuten. Los bordes y casos límite de un servicio se convierten en las restricciones de los servicios con los que interactúa. Un conjunto de pruebas sólido que esté bien mantenido y en crecimiento resolverá muchos problemas antes de que sucedan.
4. BUENOS PATRONES DE MENSAJERÍA E INTEGRACIÓN
Los sistemas distribuidos son difíciles de construir y comprender sin patrones claros. Esta es una de las mayores influencias para el éxito de los equipos. Se puede empezar con buen pie con el marco adecuado y algunos conocimientos. Eche un vistazo a MassTransit y Patrones de integración empresarial. Tanto el marco como el libro le ayudarán a empezar por el buen camino.
Si sufre las consecuencias de un cambio arquitectónico que ha salido mal o quiere evitarlas por completo, no dude en llamarnos. Nos encantaría compartir nuestras experiencias con usted.
