MICROSERVICE ARCHITECTURE: LECCIONES APRENDIDAS

1. Por qué te interesa está arquitectura?

La arquitectura de microservicios es la moda en estos momentos, pero eso no quiere decir que la mejor decisión sea adoptarla para tu software. Preguntaté realmente ¿Por qué? ya qué la construcción de microservicios bien hechos es más costoso y díficil que un monolito.

2. Define el tamaño del microservicio!

Fragmentar en exceso su aplicación te puede generar demasiada complejidad de administración lo que va en contra de lo que brinda una arquitectura orientada a microservicios.

3. Ventajas

• Escalabilidad: Haciéndolo bien puede identificar que requisitos tecnológicos necesita cada componente y así escalar diferentes partes del sistema.
• Mantenibilidad: Permite que diferentes equipos de desarrollo puedan evolucionar capacidad con una menor dependencia entre ellos.
• Mejor Implementación: Puedes realizar pasos a producción sin afectar a otros. Eso sí controla el versionamiento de tus endpoints.
• Detección de fallas: El aislamiento facilita cercar el error y encontrar el problema.
• Expertis: El equipo conoce su componente desde todas las aristas.
• Curva de aprendizaje: Es más sencillo aprender una capacidad o parte del sistema.

4. Desventajas

• Controla el exceso de lenguajes de programación ya que esto puede limitar la mantenibilidad y reutilización de código.
• Asegúrese de que sus componentes trabajen bien juntos, interbloqueos, dependencias, librerías y frameworks. Aislarlos a nivel de despliegue es una solución.
• Es más dificil en comparación a un monolito realizar pruebas de integración.
• La arquitectura debe estar bien definida desde el comienzo, si se genera mucha cohesión se perderán todas las ventajas.
• Enfocate en la comunicación. se requiere más esfuerzo de comunicación entre los servicios por lo que nos tiende a generar fallas.
• Entre más servicios, más complejo y difícil de monitorear.
• Si no tienes bien tu proceso de arquitectura y construcción de software terminarás con servicios sin usar o servicios repetidos.

5. Tipicos problemas

*. Migrar de una arquitectura monolítica a una arquitectura de microservicio no se puede hacer de inmediato, te aseguro que tienes repositorios, servidores, tareas y procesos de implementación y monitoreo.

• Puedes mantener el monolito en su lugar y las nuevas funcionalidad y capacidades orientarlas a microservicios, así en un futuro tendrás un microservicio grande y viejo.

*. No hay una regla para separar tus componentes, necesitas definir procesos e interacción y es complejo si los servicios se acoplaron desde el comienzo.

• Diagnostica tu monolito y lo que mas te genere problema debes sacarlo y convertirlo en microservicio (Incrementalmente)

*. El cambio cultural y tecnológico para tu equipo ya que deben cambiar de un escenario de extremo a extremo a uno fraccionado.

• Inicia con una capacidad sencilla pero que genere beneficio. Haga evidente que es mejor y escale a todos los equipos. (Incrementalmente).

6. Recuerda

• Si tienes un monolito no lo cambies todo de una vez.
• Escribir cada microservicio en diferente lenguaje es una mala practica
• Centraliza el monitoreo
• Evita compartir datos entre microservicios, Si dos servicios manipulan los mismos datos, comenzará a experimentar problemas.
• No sobre fragmentes tu aplicación si no es necesario.

Proximamente:
Iniciar sesión en un solo lugar es un desafío .










Referencias

- Daniel Ben-Zvi , VP of R&D at SimilarWeb
- Steven McCord , Founder and CTO at ICX Media

https://codingsans.com/blog/microservice-architecture-best-practices