Arquitectura de microservicios
Ing. Yonatan Romero
Universidad Nacional de La MatanzaMicroservicio
Un estilo de arquitectura para desarrollar una aplicación como un conjunto de pequeños servicios
Librerías vs Servicios
Los servicios son componentes out-of-process que se comunican por peticiones de web services o RPC.
Componente
Unidad de software que es independientemente remplazable, actualizable y desplegable.Ventajas
Pequeños cambios en la aplicación no requieren un despliegue completo
Actualizaciones de dependencias internas y/o externas sin impacto (si no se modifica la interfaz pública, claro)
Desventajas
Las llamadas remotas son más costosas que llamadas intra-proceso
Es dificil definir correctamente las interfaces y estructura de los servicios
Pérdida de integridad referencial
Organización de equipos de trabajo
Equipos inter-funcionales
Al dividir grandes aplicaciones en servicios es posible crear equipos de trabajo inteligentemente
Optimiza la comunicación entre equipos de trabajo y minimiza la cantidad de aprobaciones
Todas las habilidades necesarias para desarrollo: UI, base de datos y middleware
Cada equipo interfuncional es encargado de construir y operar cada PRODUCTO
Productos ≠ Proyectos
Los productos no son proyectos
Los equipos interfuncionales son los dueños del producto durante toda la vida del mismo
"You build, you run it"
Equipo de desarrollo totalmente responsable del producto en producción.
En vez de ver el software como una lista de funcionalidades que debe ser completada
Esta arquitectura enfatiza en la relaciones interpersonales dónde la pregunta es cómo el software puede asistir a los usuarios en mejorar su productividad en el negocio
¿Qué tan grandes deben ser los equipos?
Amazon utiliza la noción "dos pizzas"
Equipos no mucho más grandes que la cantidad de personas que comen dos pizzas sin quedarse con hambre
Gobierno descentralizado
Una de las tendencias del gobierno centralizado es intentar estandarizar una sóla tecnología para todos los problemas
No todos los problemas son clavos, ni todas las soluciones son martillos
Dividir en servicios permite elegir las mejores herramientas, lenguajes y plataformas técnológicas más adecuadas para el problema a resolver
Mayor uso de lenguajes no "clásicos" como R, Ruby, Python, Scala, Matlab, etc
Datos descentralizados
En aplicaciones monolíticas se suele usar una sola base de datos donde conviven todas la información que necesitan los módulos. Se usa la misma plataforma para todas las aplicaciones de la organización
Los microservicios utilizan el almacen de datos más correcto para su funcionalidad. Por ejemplo base de datos documentales (MongoDB) o de clave-valor (Redis)
GRAN DESAFÍO: Consistencia de datos
Automatización de infraestructura
La automatización de infraestructura ha mejorado notablemente los últimos años.
Reduce errores humanos
Permite la integración continúa y la entrega continua
Diseñar para el fallo
Las instancias de los microservicios pueden fallar. Es necesario un sistema de monitoreo y de recuperación automática.
Generalmente se desarrolla un panel de control para monitorear el estado de todas las instancias de la aplicación
Cambios frecuentes, rápidos y bien controlados
Casos de éxito
Amazon AWS
Netflix
Spotify
