Hoy iniciamos una serie de artículos relacionados con preguntas comunes que son realizadas en las entrevistas para aplicar al puesto como desarrollador en el área de los microservicios, además obviamente daremos las respuestas. En otro artículo, hablamos sobre preguntas pero no dimos las respuestas, en este caso será una serie de artículos donde de 5 en 5 traeremos preguntas y respuestas. También estarán en formato de vídeo disponibles en nuestro canal de Youtube, te animamos a suscribirte y recibirás notificaciones en cada entrega.

Las preguntas de esta serie han sido elegidas de 3 fuentes:

1. Experiencia personal.
2. Experiencia de amigos y colegas de trabajo.
3. Recopilación de medios.

Preguntas y respuestas de una entrevista técnica para desarrollador microservicios (I)

A continuación, las preguntas y sus respuestas.

Defina la arquitectura microservicios

Podemos definir la arquitectura microservicios mediante los siguientes puntos:

• Es un enfoque para desarrollar una sola aplicación como un conjunto de pequeños servicios. 
• Cada uno de los cuales se ejecuta en su propio proceso. 
• Se comunica con mecanismos ligeros, a menudo una API de recursos HTTP.
• Estos servicios se basan en el negocio y se pueden implementar de forma
• independiente. 
• Existe un mínimo de gestión centralizada de estos servicios, que pueden escribirse en diferentes lenguajes de programación y utilizar diferentes tecnologías de almacenamiento de datos”.

Puedes aprender más acá [INGLES] https://martinfowler.com/articles/microservices.html

Enuncie las ventajas de la arquitectura microservicios

Las ventajas principales de la arquitectura microservicios son:

• Permite asignar equipos específicos, pequeños y manejables al desarrollo de cada componente o microservicio.
• Permite implementar pruebas de forma más atómicas, unitarias y sencillas a cada funcionalidad.
• Permite implementar pruebas de integración sectorizadas por microservicios y grupos de microservicios, para ir viendo cómo se acoplan paulatinamente.
• Es posible usar las tecnologías más adecuadas en cada microservicio, por ejemplo, para operaciones de búsqueda de clientes y productos, podremos incorporar un ElasticSearch para búsquedas de texto completo.
• Facilita desagregar el despliegue de ciertos microservicios en diversos nodos, con múltiples instancias a demanda (escalabilidad horizontal)

¿Cuáles son algunos retos de adoptar la arquitectura microservicios?

Los retos principales de la arquitectura microservicios son:

• Lograr un diseño adecuado, es -sino- la tarea más compleja a enfrentar.
• Gestión de la infraestructura.
• Evitar las dependencias cíclicas y que la arquitectura se convierta en un “spaguetti”.
• Correcta gestión de la transaccionalidad y la consistencia de los datos.
• Gestión del entorno distribuido y asumir que “Las 8  falacias de la computación distribuida” son un elemento a tener en cuenta en la implementación.
• Necesidad de la implementación de la cultura DevOps.

En la arquitectura cómo puede resolverse el problema de los parámetros de configuración de los microservicios y sus instancias.

Los microservicios tienen como características que están distribuidos en la red, además de que se ponen en operación y bajan instancias en función de la demanda, por lo que manejar configuración local a nivel de instancia no es viable. La solución para resolver este problema es aplicar un enfoque de configuración centralizada.

La configuración centralizada es un patrón de la arquitectura microservicios, su funcionamiento es sencillo: cuando una instancia está en proceso de inicialización se conecta a un proveedor de configuraciones y lee de ahí sus parámetros de configuración, luego culmina su inicialización.

Subpregunta trampa posible: ¿ Es posible actualizar las properties de un microservicio bajo el esquema de configuración centralizada en caliente?

La respuesta sencilla es que si se puede pero su implementación no tiende a ser sencilla, básicamente el proveedor de configuración centralizada deberá enviar una notificación a las instancias (acorde a la propiedad cambiada) y pedirle que la “recarguen”. Sin embargo se debe ser extremadamente cuidadoso porque puede traer fallos transitorios o pérdidas de transacciones (por ej: Se manda a cambiar una property de configuración de una base de datos que tiene operaciones en curso). En Spring Boot / Cloud esto puede lograrse alrededor de Spring Actuator / @RefreshScope.  

En una arquitectura microservicios son comunes las llamadas servicio a servicio, ¿ qué mecanismos pueden implementarse para evitar posibles fallos? 

En este caso, nos están evaluando temas asociados a la resiliencia, la cual es una debilidad de los sistemas distribuidos. Responder adecuadamente esta pregunta lleva conocer “Las falacias de la computación distribuida” y cómo la arquitectura microservicios puede combatirla.

La respuesta definitiva a esta pregunta es los mecanismos a implementar son:

• Mecanismo de reintentos.
• Mecanismo de Circuit Breaker

Reintentos

El mecanismo de reintentos permite que cuando un microservicio A llame hacia un microservicio B y el B no de una respuesta satisfactoria A reintente nuevamente por un número de veces hasta obtener una respuesta adecuada (normalmente con status diferente de 500). Existen dos estrategias de reintentos: lineal y con backoff.

Circuit Breaker

Es un mecanismo similar al de reintentos, pero va un paso más allá funcionando como un sistema eléctrico, dejando pasar o no las solicitudes de A hacia B con controles de tiempo. Ayuda a evitar que se reintente continuamente sobre B si B no ha dado una respuesta satisfactoria. Maneja tres estados: Abierto, Cerrado y Medio Abierto.

En ambos casos se pueden implementar políticas de fallback (recuperación) que son invocadas cuando no es posible alcanzar a B. El fallback debe ser siempre sencillo y debe dar una respuesta adecuada para el solicitante.

Si deseas ver el vídeo donde explicamos más detalles, acá lo dejamos:

Espero te sea útil el artículo, nos vemos en el próximo.