Respuesta.

Arquitectura de microservicios — es un enfoque para construir sistemas de software donde la aplicación consiste en pequeños servicios aislados, cada uno responsable de una tarea comercial específica, desarrollándose y desplegándose de forma independiente de los demás.

Ventajas:

• Escalabilidad: cada servicio se escala por separado.
• Independencia en el desarrollo: diferentes equipos pueden desarrollar rápidamente servicios individuales.
• Resiliencia a fallos: una falla en un servicio no provoca la caída de todo el sistema.

Desventajas:

• Complejidad en la gestión: se requiere configurar interacciones, monitoreo, balanceo.
• Complejidad en el despliegue: coordinar múltiples servicios es complicado.
• Aumento de los costos de comunicación: los servicios se comunican a través de la red, lo que aumenta las latencias y requiere una integración confiable.

Ejemplo de un REST mock de un microservicio en Python (Flask):

from flask import Flask, jsonify
app = Flask(__name__)

@app.route('/user/<int:user_id>')
def get_user(user_id):
    return jsonify({"user_id": user_id, "name": "Ivan"})

if __name__ == "__main__":
    app.run(port=5001)

Características clave:

• Cada servicio es una aplicación autónoma.
• Es fácil introducir nuevas tecnologías o lenguajes para diferentes servicios.
• Se requiere tener en cuenta los errores de las interacciones en red y asegurar la consistencia de los datos.

Preguntas capciosas.

¿Pueden los microservicios trabajar en una sola base de datos?

Esto es aceptable en la etapa de migración desde un monolito, pero contradice la ideología, ya que cada servicio debe almacenar sus datos por separado para minimizar dependencias y garantizar la independencia del desarrollo.

¿Es obligatorio usar Docker para la arquitectura de microservicios?

No, Docker facilita el despliegue y la aislamiento, pero los microservicios se pueden implementar sin contenerización, utilizando, por ejemplo, máquinas virtuales o incluso servidores físicos separados.

¿Qué sucede si el contrato API entre servicios está roto, pero en el pipeline de CI/CD todo está verde?

Un fallo en el contrato API llevará a errores de interacción entre los servicios, que solo se pueden detectar mediante pruebas de integración. Un build verde en CI/CD no garantiza que diferentes versiones de servicios sean compatibles entre sí.