Buena pregunta, respuesta complicada 🙂
Hay cuatro razones básicas para usar un microservicio: escalado, prueba, escalado nuevamente e implementación.
La primera escala se refiere al número de personas u organizaciones en un proyecto. Esperemos que esté lo suficientemente lejos en la ingeniería de software para darse cuenta de que las dependencias entre las partes son las que lo hacen difícil. Por ejemplo, si tiene SQL disperso en todo su código, dificulta la refactorización de la base de datos, pero si tiene un módulo que encapsula el SQL, entonces la refactorización se hace mucho más simple. Como es, más al punto, mantenimiento.
- ¿Qué desafíos de TI enfrentan las empresas de arquitectos?
- ¿Cómo se usa la geometría en la arquitectura? Necesito esta información para un proyecto escolar.
- Arquitectos: ¿Qué proyectos de vidrio ha realizado Rene González?
- Arquitectos: ¿Qué piensa sobre la practicidad de este sitio web de arquitectura?
- ¿Cuáles son algunos temas de investigación para un estudiante universitario de arquitectura?
A medida que crece un proyecto de software, esto se vuelve más difícil, por lo que tiene sentido factorizar partes del proyecto en servicios separados completos. En lugar de tener un módulo de base de datos, ahora tenemos un servicio de base de datos … que se hace preguntas en (normalmente) el resto y, por lo tanto, está completamente separado del resto del proyecto. Esto hace que el desarrollo y el mantenimiento del software sean mucho más simples.
También simplifica las pruebas. Ahora que hemos dividido la aplicación en fragmentos ejecutables por separado; y trozos que están diseñados para usarse como una caja negra, ahora tenemos un modelo de prueba de caja negra. En resumen, los autores del servicio deben proporcionar una declaración de lo que realmente hace el servicio expuesto; y “todo” que los probadores necesitan hacer es probar contra esta especificación. Obviamente, en la práctica, hay mucho más por probar, pero este es un respaldo realmente sólido de una estrategia de prueba.
Los microservicios, particularmente si no tienen estado o son leídos, también se escalan magníficamente. Todo lo que realmente necesita hacer para escalar tal cosa es ejecutar más de una instancia en más de un nodo y luego equilibrar la carga entre ellos. Hay algunas advertencias sobre su uso en máquinas virtuales, como que básicamente no tiene sentido ejecutar dos instancias en máquinas virtuales en el mismo nodo, pero de todos modos debería usar contenedores 🙂
Y, finalmente, para la implementación, los microservicios significan que los nuevos componentes se pueden insertar en aplicaciones en ejecución sin eliminarlos. Quizás lo más relevante es que estos nuevos componentes se pueden deshacer si algo sale mal. También da lugar a una amplia variedad de técnicas de prueba, tales como “despliegue canario” (poner un poco de tráfico en el nuevo servicio y asegurarse de que se comportará) y “prueba en vivo” (enviar datos reales a dos versiones del mismo servicio y ver si los resultados son los mismos).
Contras: para proyectos más pequeños, los microservicios imponen una sobrecarga de administración que simplemente no es necesaria: puede componer en un fragmento monolítico y que no sea un problema. Los microservicios también agregan latencia a la aplicación en cuestión, por lo que, incluso si la capacidad del sistema aumenta, su rendimiento, como lo atestigua el usuario final, no lo hará. Y finalmente, los microservicios reintroducen el infierno de dependencia de versiones, exactamente lo que estábamos tratando de evitar mediante el uso de contenedores en primer lugar. Las API que evolucionan (sí, lo harán) deben ser versionadas y el trabajo debe realizarse para garantizar que un microservicio siempre esté asociado con la versión correcta del servicio que lo utiliza, o que el microservicio sigue siendo compatible con versiones anteriores, o que algunos el control de versiones tiene lugar … lo que significa servicios web … lo que significa SOAP … lo que significa XML … y todo tipo de secuencias de validación über dolorosas con un rendimiento deficiente asociado.
En resumen: utilícelos si el proyecto será grande y se preocupa por la calidad, o si tiene una gran capacidad y / o requisitos de tiempo de actividad.
