Conjunto de servicios acoplados de forma flexible que se utilizan para crear aplicaciones informáticas
En ingeniería de software , una arquitectura de microservicios es un patrón arquitectónico que organiza una aplicación como una colección de servicios de grano fino y acoplados de forma flexible , que se comunican a través de protocolos livianos . Una arquitectura basada en microservicios permite a los equipos desarrollar e implementar sus servicios de forma independiente, reducir la interdependencia del código y aumentar la legibilidad y la modularidad dentro de una base de código. Esto se logra reduciendo varias dependencias en la base de código, lo que permite a los desarrolladores desarrollar sus servicios con restricciones limitadas y reducir la complejidad adicional. [1] En consecuencia, las organizaciones pueden desarrollar software con un rápido crecimiento y escalabilidad, así como implementar servicios listos para usar con mayor facilidad. Estos beneficios vienen con el costo de tener que mantener una estructura desacoplada dentro de la base de código, lo que significa que su implementación inicial es más compleja que la de una base de código monolítica . [2] Las interfaces deben diseñarse con cuidado y tratarse como API .
Un microservicio es análogo a un contexto delimitado en el diseño impulsado por el dominio . [3]
Definición
No existe una única definición de microservicios. Con el tiempo, se ha desarrollado un consenso en la industria. Algunas de las características definitorias que se citan con frecuencia incluyen:
- Los servicios en una arquitectura de microservicios suelen ser procesos que se comunican a través de una red para cumplir un objetivo utilizando protocolos independientes de la tecnología, como HTTP . [4] [5] [6]
- Los servicios se organizan en función de las capacidades empresariales [ aclaración necesaria ] . [7]
- Los servicios se pueden implementar utilizando diferentes lenguajes de programación , bases de datos , entornos de hardware y software, dependiendo de lo que mejor se adapte. [8]
- Los servicios son de tamaño pequeño, están habilitados para mensajería, están limitados por contextos, se desarrollan de forma autónoma, se pueden implementar de forma independiente, [9] [8] están descentralizados y se construyen y lanzan con procesos automatizados . [9]
- Los microservicios son una especialización de un enfoque de implementación para arquitecturas orientadas a servicios que se utilizan para construir sistemas de software flexibles y que se pueden implementar de forma independiente . [7]
Un microservicio no es una capa dentro de una aplicación monolítica (por ejemplo, el controlador web o el backend para el frontend). [10] Más bien, es una pieza autónoma de funcionalidad empresarial con interfaces claras y puede, a través de sus propios componentes internos, implementar una arquitectura en capas. Desde una perspectiva estratégica, la arquitectura de microservicios sigue esencialmente la filosofía Unix de "hacer una cosa y hacerla bien". [11] Martin Fowler describe una arquitectura basada en microservicios como si tuviera las siguientes propiedades: [4]
- Se presta a un proceso de desarrollo de software de entrega continua . [12] Un cambio en una pequeña parte de la aplicación solo requiere reconstruir y volver a implementar solo uno o una pequeña cantidad de servicios. [13]
- Se adhiere a principios tales como interfaces de grano fino (para servicios implementables de forma independiente), desarrollo impulsado por el negocio (por ejemplo, diseño impulsado por el dominio ). [14]
Uso
Es común que las arquitecturas de microservicios se adopten para aplicaciones nativas de la nube , computación sin servidor y aplicaciones que utilizan la implementación de contenedores livianos . Según Fowler, debido a la gran cantidad (en comparación con las implementaciones de aplicaciones monolíticas) de servicios, la entrega continua descentralizada y DevOps con monitoreo holístico de servicios son necesarios para desarrollar, mantener y operar de manera efectiva dichas aplicaciones. [15] Una consecuencia (y una razón para) seguir este enfoque es que los microservicios individuales se pueden escalar individualmente. En el enfoque monolítico, una aplicación que admita tres funciones tendría que escalarse en su totalidad incluso si solo una de estas funciones tuviera una restricción de recursos. [16] Con los microservicios, solo el microservicio que admite la función con restricciones de recursos necesita escalarse, lo que brinda beneficios de optimización de recursos y costos. [17]
En febrero de 2020, el Informe de investigación de mercado de microservicios en la nube predijo que el tamaño del mercado global de arquitectura de microservicios aumentará a una CAGR del 21,37 % entre 2019 y 2026 y alcanzará los 3100 millones de dólares en 2026. [18]
Historia
En 1999, el desarrollador de software Peter Rodgers había estado trabajando en el proyecto de investigación Dexter en Hewlett Packard Labs , cuyo objetivo era hacer que el código fuera menos frágil y que los sistemas de software complejos a gran escala fueran resistentes al cambio. [19] En última instancia, este camino de investigación condujo al desarrollo de la computación orientada a recursos (ROC), una abstracción computacional generalizada en la que REST es un subconjunto especial. En 2005, durante una presentación en la conferencia Web Services Edge, Rodgers abogó por los " servicios REST " y afirmó que " los componentes de software son microservicios web... Los microservicios se componen utilizando tuberías similares a Unix (la Web se encuentra con Unix = verdadero acoplamiento flexible ). Los servicios pueden llamar a servicios (+ tiempos de ejecución de múltiples lenguajes). Los ensamblajes de servicios complejos se abstraen detrás de interfaces URI simples . Cualquier servicio, con cualquier granularidad, puede exponerse". Describió cómo una plataforma de microservicios bien diseñada "aplica los principios arquitectónicos subyacentes de los servicios web y REST junto con la programación y las canalizaciones similares a Unix para proporcionar una flexibilidad radical y una simplicidad mejorada en arquitecturas orientadas a servicios". [20]
También en 2005, Alistair Cockburn escribió sobre la arquitectura hexagonal , que es un patrón de diseño de software que se utiliza junto con los microservicios. Este patrón hace posible el diseño del microservicio, ya que aísla en capas la lógica de negocio de los servicios auxiliares necesarios para implementar y ejecutar el microservicio de forma completamente independiente de los demás.
Granularidad del servicio
Un paso clave para definir una arquitectura de microservicios es determinar el tamaño que debe tener un microservicio individual. No existe un consenso ni una prueba decisiva para esto, ya que la respuesta correcta depende del contexto empresarial y organizacional. [21] Por ejemplo, Amazon utiliza una arquitectura orientada a servicios donde el servicio a menudo se asigna 1:1 con un equipo de 3 a 10 ingenieros. [22]
Para encontrar el nivel adecuado de granularidad del servicio, los arquitectos deben iterar continuamente sus diseños de componentes con los programadores . Los arquitectos deben tener en cuenta los requisitos de los usuarios, las responsabilidades y las características arquitectónicas (también conocidos como requisitos no funcionales ). [3]
En el contexto de la arquitectura de software, los servicios dedicados a una única tarea, como llamar a un sistema backend específico o realizar un cálculo particular, se conocen como servicios atómicos. Los servicios que llaman a servicios atómicos para consolidar un resultado se conocen como servicios compuestos.
Se considera una mala práctica hacer que el servicio sea demasiado pequeño, ya que entonces la sobrecarga en tiempo de ejecución y la complejidad operativa pueden superar los beneficios del enfoque. Cuando los servicios se vuelven demasiado detallados, se deben considerar enfoques alternativos, como empaquetar la función como una biblioteca o integrarla en otros microservicios. [7]
Si se utiliza un diseño impulsado por el dominio para modelar el dominio para el cual se está construyendo el sistema, entonces un microservicio podría ser tan pequeño como un agregado o tan grande como un contexto limitado. [23]
En el debate sobre la granularidad de los microservicios, hay un espectro. En un extremo están los servicios anémicos, que no tienen una gran cantidad de responsabilidades, y en el otro extremo están los monolitos modulares, que son grandes módulos de un sistema.
Beneficios
Los beneficios de descomponer una aplicación en diferentes servicios más pequeños son numerosos:
- Modularidad : Esto hace que la aplicación sea más fácil de entender, desarrollar, probar y se vuelva más resistente a la erosión de la arquitectura. [8] Este beneficio se suele comparar con la complejidad de las arquitecturas monolíticas. [24]
- Escalabilidad : dado que los microservicios se implementan y despliegan independientemente unos de otros, es decir, se ejecutan dentro de procesos independientes, se pueden monitorear y escalar de forma independiente. [25]
- Integración de sistemas heterogéneos y heredados : los microservicios se consideran un medio viable para modernizar las aplicaciones de software monolíticas existentes. [26] [27] Existen informes de experiencias de varias empresas que han reemplazado con éxito partes de su software existente con microservicios o están en proceso de hacerlo. [28] El proceso de modernización del software de aplicaciones heredadas se realiza utilizando un enfoque incremental. [29]
- Desarrollo distribuido: paraleliza el desarrollo al permitir que pequeños equipos autónomos desarrollen, implementen y escalen sus respectivos servicios de forma independiente. [30] También permite que la arquitectura de un servicio individual emerja a través de una refactorización continua . [31] Las arquitecturas basadas en microservicios facilitan la integración continua , la entrega continua y la implementación. [32]
Críticas y preocupaciones
El enfoque de microservicios está sujeto a críticas por una serie de cuestiones:
- Los servicios forman barreras de información. [33]
- Las llamadas entre servicios a través de una red tienen un costo mayor en términos de latencia de red y tiempo de procesamiento de mensajes que las llamadas en proceso dentro de un proceso de servicio monolítico . [4]
- Las pruebas y la implementación son más complicadas. [34] [35]
- Trasladar responsabilidades entre servicios es más difícil. [8] Puede implicar comunicación entre diferentes equipos, reescribir la funcionalidad en otro lenguaje o adaptarla a una infraestructura diferente. [4] Sin embargo, los microservicios se pueden implementar independientemente del resto de la aplicación, mientras que los equipos que trabajan en monolitos necesitan sincronizarse para implementar juntos. [29]
- Considerar el tamaño de los servicios como el mecanismo de estructuración principal puede llevar a demasiados servicios cuando la alternativa de modularización interna puede llevar a un diseño más simple. [36] Esto requiere comprender la arquitectura general de las aplicaciones y las interdependencias entre los componentes. [37]
- Las confirmaciones en dos fases se consideran un antipatrón en las arquitecturas basadas en microservicios, ya que dan como resultado un acoplamiento más estrecho de todos los participantes dentro de la transacción. Sin embargo, la falta de esta tecnología provoca bailes incómodos que deben implementar todos los participantes de la transacción para mantener la coherencia de los datos. [38]
- El desarrollo y soporte de muchos servicios son más desafiantes si se construyen con diferentes herramientas y tecnologías; esto es especialmente un problema si los ingenieros se trasladan de un proyecto a otro con frecuencia. [39]
- El protocolo que se utiliza normalmente con microservicios (HTTP) fue diseñado para servicios públicos y, como tal, no es adecuado para el funcionamiento de microservicios internos que a menudo deben ser impecablemente confiables. [40]
- Si bien no es específica de los microservicios, la metodología de descomposición a menudo utiliza la descomposición funcional, que no maneja los cambios en los requisitos y, al mismo tiempo, agrega complejidad a los servicios. [40]
- El concepto mismo de microservicio es engañoso, ya que solo existen servicios. No existe una definición sólida de cuándo un servicio comienza o deja de ser un microservicio. [40]
- Agregación de datos. Para tener una visión completa de un sistema en funcionamiento, es necesario extraer conjuntos de datos de los repositorios de microservicios y agregarlos en un único esquema. Por ejemplo, para poder crear informes operativos que no son posibles utilizando un único repositorio de microservicios.
Complejidades
La arquitectura introduce complejidad adicional y nuevos problemas con los que lidiar, como latencia , diseño de formato de mensaje , [41] respaldo /disponibilidad/consistencia (BAC), [42] balanceo de carga y tolerancia a fallas . [35] Todos estos problemas deben abordarse a escala. La complejidad de una aplicación monolítica no desaparece si se reimplementa como un conjunto de microservicios. Parte de la complejidad se traduce en complejidad operativa. [43] Otros lugares donde la complejidad se manifiesta son el aumento del tráfico de red y el resultado en un rendimiento más lento. Además, una aplicación compuesta por cualquier número de microservicios tiene un mayor número de puntos de interfaz para acceder a su respectivo ecosistema , lo que aumenta la complejidad arquitectónica. [44] Se han aplicado varios principios organizativos (como hipermedia como motor del estado de la aplicación (HATEOAS), documentación de la interfaz y el modelo de datos capturados a través de Swagger , etc.) para reducir el impacto de dicha complejidad adicional.
Mejores prácticas
Según O'Reilly, cada microservicio debería tener sus propias características arquitectónicas (también conocidas como requisitos no funcionales ), y los arquitectos no deberían definir características uniformes para todo el sistema distribuido . [3]
La latencia se mide a menudo a través del "percentil 99" porque las latencias media y media pueden ser engañosas, ya que pueden pasar por alto valores atípicos . [45] [ página necesaria ] [46]
Tecnologías
Los microservicios informáticos se pueden implementar en diferentes lenguajes de programación y pueden utilizar diferentes infraestructuras. Por lo tanto, las opciones tecnológicas más importantes son la forma en que los microservicios se comunican entre sí (sincrónica, asincrónica, integración de UI) y los protocolos utilizados para la comunicación (HTTP RESTful, mensajería, GraphQL ...). En un sistema tradicional, la mayoría de las opciones tecnológicas, como el lenguaje de programación, afectan a todo el sistema. Por lo tanto, el enfoque para elegir tecnologías es bastante diferente. [47]
La Fundación Eclipse ha publicado una especificación para el desarrollo de microservicios, Eclipse MicroProfile. [48] [49]
Malla de servicio
En una malla de servicios, cada instancia de servicio se empareja con una instancia de un servidor proxy inverso, denominado proxy de servicio, proxy sidecar o sidecar. La instancia de servicio y el proxy sidecar comparten un contenedor, y los contenedores son administrados por una herramienta de orquestación de contenedores como Kubernetes , Nomad, Docker Swarm o DC/OS . Los servidores proxy de servicio son responsables de la comunicación con otras instancias de servicio y pueden admitir capacidades como el descubrimiento de servicios (instancias), el equilibrio de carga, la autenticación y autorización, las comunicaciones seguras y otras.
En una malla de servicios, se dice que las instancias de servicio y sus proxies secundarios conforman el plano de datos, que incluye no solo la gestión de datos sino también el procesamiento y la respuesta de solicitudes. La malla de servicios también incluye un plano de control para gestionar la interacción entre servicios, mediada por sus proxies secundarios. [ cita requerida ]
Una comparación de plataformas
Implementar una arquitectura de microservicios es muy difícil. Existen muchas preocupaciones (ver la tabla a continuación) que cualquier arquitectura de microservicios debe abordar. Netflix desarrolló un marco de microservicios para respaldar sus aplicaciones internas y luego publicó en código abierto [50] muchas partes de ese marco. Muchas de estas herramientas se han popularizado a través de Spring Framework ; se han vuelto a implementar como herramientas basadas en Spring bajo el paraguas del proyecto Spring Cloud [51] . La siguiente tabla muestra una comparación de una característica de implementación del ecosistema Kubernetes con un equivalente del mundo Spring Cloud [52] . Un aspecto notable del ecosistema Spring Cloud es que todas son tecnologías basadas en Java, mientras que Kubernetes es una plataforma de ejecución políglota.
Véase también
Referencias
- ^ "Arquitecturas de microservicios: ¿más que la suma de sus partes?". IONOS Digitalguide . 2 de marzo de 2020 . Consultado el 29 de marzo de 2022 .
- ^ Fowler, Martin (2002). Patrones de arquitectura de aplicaciones empresariales . Addison-Wesley Professional. ISBN 978-0321127426.
- ^ Fundamentos de la arquitectura de software: un enfoque de ingeniería . O'Reilly Media. 2020. ISBN 978-1492043454.
- ^ abcd Martin Fowler. «Microservicios». Archivado desde el original el 14 de febrero de 2018.
- ^ Newman, Sam (20 de febrero de 2015). Creación de microservicios . O'Reilly Media. ISBN 978-1491950357.
- ^ Wolff, Eberhard (12 de octubre de 2016). Microservicios: arquitecturas de software flexibles . Addison-Wesley. ISBN 978-0134602417.
- ^ abc Pautasso, Cesare (2017). "Microservicios en la práctica, parte 1: verificación de la realidad y diseño de servicios". IEEE Software . 34 (1): 91–98. doi :10.1109/MS.2017.24. S2CID 5635705.
- ^ abcd Chen, Lianping (2018). Microservicios: arquitectura para la entrega continua y DevOps. Conferencia internacional IEEE sobre arquitectura de software (ICSA 2018). IEEE.
- ^ ab Nadareishvili, I., Mitra, R., McLarty, M., Amundsen, M., Arquitectura de microservicios: alineando principios, prácticas y cultura, O'Reilly 2016
- ^ "Patrón de backends para frontends". Patrones de diseño de la nube de Microsoft Azure . Microsoft.
- ^ Lucas Krause. Microservicios: patrones y aplicaciones . ASIN B00VJ3NP4A.
- ^ Ford, N; Richards, M; Sadalage, P; Dehghani, Z. "Arquitectura de software: las partes difíciles". Thoughtworks . Consultado el 20 de enero de 2023 .
- ^ "CI/CD para arquitecturas de microservicios", Centro de arquitectura de Azure, Microsoft . Consultado el 9 de enero de 2018.
- ^ Josuttis, N. (2007). SOA en la práctica. Sebastopol, California, Estados Unidos: O'Reilly. ISBN 978-0-596-52955-0 .
- ^ Martin Fowler (28 de agosto de 2014). «Requisitos previos de microservicios». Archivado desde el original el 3 de octubre de 2023.
- ^ Richardson, Chris (noviembre de 2018). Patrones de microservicios . Manning Publications. 1.4.1 Cubo de escala y microservicios. ISBN 9781617294549.
- ^ Mendonca, Nabor C.; Jamshidi, Pooyan; Garlan, David; Pahl, Claus (16 de octubre de 2019). "Desarrollo de sistemas de microservicios autoadaptativos: desafíos y direcciones". IEEE Software . 38 (2): 70–79. arXiv : 1910.07660 . doi :10.1109/MS.2019.2955937. S2CID 204744007.
- ^ Investigación, Mercado verificado. "Tendencias del mercado de microservicios en la nube para 2020, participación de mercado, tamaño de la industria, oportunidades, análisis y pronóstico para 2026 - Instant Tech Market News" . Consultado el 18 de febrero de 2020 .
- ^
- ^ Rodgers, Peter (15 de febrero de 2005). "Desarrollo orientado a servicios en NetKernel: patrones, procesos y productos para reducir la complejidad del sistema". CloudComputingExpo . SYS-CON Media. Archivado desde el original el 20 de mayo de 2018 . Consultado el 19 de agosto de 2015 .
- ^ O. Zimmermann, Descomposición de servicios específicos de dominio con patrones de API de microservicios, Microservices 2019, https://www.conf-micro.services/2019/slides//keynotes/Zimmerman.pdf
- ^ "Mandato SOA de Amazon". 13 de octubre de 2011.
- ^ Vaughn, Vernon (2016). Diseño impulsado por el dominio, destilado . Addison-Wesley Professional. ISBN 978-0-13-443442-1.
- ^ Yousif, Mazin (2016). "Microservicios". IEEE Cloud Computing . 3 (5): 4–5. doi :10.1109/MCC.2016.101.
- ^ Dragoni, Nicola; Lanese, Ivan; Larsen, Stephan Thordal; Mazzara, Manuel; Mustafin, Ruslan; Safina, Larisa (2017). "Microservicios: cómo hacer que su aplicación escale" (PDF) . Perspectivas de la informática de sistemas . Apuntes de clase en informática. Vol. 10742. págs. 95–104. arXiv : 1702.07149 . Código Bibliográfico :2017arXiv170207149D. doi :10.1007/978-3-319-74313-4_8. ISBN 978-3-319-74312-7. Número de identificación del sujeto 1643730.
- ^ Newman, Sam (2015). Creación de microservicios . O'Reilly. ISBN 978-1491950357.
- ^ Wolff, Eberhard (2016). Microservicios: arquitectura de software flexible . Addison Wesley. ISBN 978-0134602417.
- ^ Knoche, Holger; Hasselbring, Wilhelm (2019). "Factores impulsores y barreras para la adopción de microservicios: una encuesta entre profesionales en Alemania". Arquitecturas de sistemas de información y modelado empresarial . 14 : 1:1–35–1:1–35. doi :10.18417/emisa.14.1.
- ^ ab Taibi, Davide; Lenarduzzi, Valentina; Pahl, Claus; Janes, Andrea (2017). "Microservicios en el desarrollo ágil de software: un estudio basado en talleres sobre problemas, ventajas y desventajas". Actas de los talleres científicos XP2017 . doi :10.1145/3120459.3120483. S2CID 28134110.
- ^ Richardson, Chris. "Patrón de arquitectura de microservicios". microservices.io . Consultado el 19 de marzo de 2017 .
- ^ Chen, Lianping; Ali Babar, Muhammad (2014). "Hacia una comprensión basada en evidencias del surgimiento de la arquitectura a través de la refactorización continua en el desarrollo ágil de software". Actas de la Conferencia de trabajo IEEE/IFIP sobre arquitectura de software 2014 WICSA 2014. La 11.ª Conferencia de trabajo IEEE/IFIP sobre arquitectura de software (WICSA 2014). IEEE. doi :10.1109/WICSA.2014.45.
- ^ Balalaie, Armin; Heydarnoori, Abbas; Jamshidi, Pooyan (mayo de 2016). "La arquitectura de microservicios permite DevOps: migración a una arquitectura nativa de la nube" (PDF) . IEEE Software . 33 (3): 42–52. doi :10.1109/ms.2016.64. hdl :10044/1/40557. ISSN 0740-7459. S2CID 18802650.
- ^ Stenberg, Jan (11 de agosto de 2014). "Experiencias de fracaso con microservicios".
- ^ Calandra, Mariano (7 de abril de 2021). "Por qué las pruebas unitarias no son suficientes cuando se trata de microservicios".
- ^ ab "Desarrollo de microservicios para PaaS con Spring y Cloud Foundry".
- ^ Tilkov, Stefan (17 de noviembre de 2014). "¿Qué tan pequeño debe ser tu microservicio?". Innoq . Consultado el 4 de enero de 2017 .
- ^ Lanza, Michele; Ducasse, Stéphane (2002). "Understanding Software Evolution using a Combined of Software Visualization and Software Metrics" (PDF) . En Actas de LMO 2002 (Langages et Modèles à Objets) : 135–149. Archivado desde el original (PDF) el 27 de febrero de 2021.
- ^ Richardson, Chris (noviembre de 2018). "Capítulo 4. Gestión de transacciones con sagas". Patrones de microservicios . Publicaciones Manning. ISBN 978-1-61729454-9.
- ^ Devoxx (30 de agosto de 2017). "10 consejos para fracasar estrepitosamente en microservicios por David Schmitz". YouTube . Archivado desde el original el 22 de abril de 2021.
- ^ abc Löwy, Juval (2019). Righting Software 1.ª ed . Addison-Wesley Professional. págs. 73–75. ISBN 978-0136524038.
- ^ Pautasso, Cesare (2017). "Microservicios en la práctica, parte 2: Integración de servicios y sostenibilidad". IEEE Software . 34 (2): 97–104. doi :10.1109/MS.2017.56. S2CID 30256045.
- ^ Pautasso, Cesare (2018). "Recuperación de desastres consistente para microservicios: el teorema BAC". IEEE Cloud Computing . 5 (1): 49–59. doi :10.1109/MCC.2018.011791714. S2CID 4560021.
- ^ Fowler, Martin . "Compensaciones en microservicios".
- ^ "BRASS Building Resource Adaptive Software Systems". Gobierno de EE. UU., DARPA, 7 de abril de 2015."Sin embargo, el acceso a los componentes del sistema y las interfaces entre los clientes y sus aplicaciones se realiza a través de una serie de mecanismos a menudo no relacionados, entre los que se incluyen interfaces de programación de aplicaciones (API) documentadas informalmente, interfaces de funciones externas idiosincrásicas, definiciones de modelos complejas y mal entendidas o formatos de datos ad hoc . Estos mecanismos suelen proporcionar solo una comprensión parcial e incompleta de la semántica de los propios componentes. En presencia de tal complejidad, no es sorprendente que las aplicaciones normalmente incorporen muchas suposiciones sobre el comportamiento esperado del ecosistema con el que interactúan".
- ^ Vitillo, Roberto (2021). Entendiendo los sistemas distribuidos: lo que todo desarrollador debe saber sobre las grandes aplicaciones distribuidas . Roberto Vitillo. ISBN 978-1838430207.
- ^ Bhargav, Nikhil (18 de marzo de 2024). "¿Cuál es la latencia P99?". baeldung.com . Consultado el 8 de junio de 2024.
La media y la mediana suelen enmascarar los valores atípicos
. - ^ Wolff, Eberhard (15 de abril de 2018). Microservicios: una guía práctica. Plataforma de publicación independiente CreateSpace. ISBN 978-1717075901.
- ^ Swart, Stephanie (14 de diciembre de 2016). "Microperfil de Eclipse". projects.eclipse.org .
- ^ "MicroPerfil". MicroPerfil . Consultado el 11 de abril de 2021 .
- ^ Netflix OSS, Centro de Git
- ^ Nube, primavera
- ^ "Spring Cloud para microservicios en comparación con Kubernetes", Desarrolladores , Red Hat, 9 de diciembre de 2016
- ^ Somashekar, Gagan; Gandhi, Anshul (26 de abril de 2021). "Hacia una configuración óptima de microservicios". Actas del 1.er taller sobre aprendizaje automático y sistemas . EuroMLSys '21. En línea, Reino Unido: Association for Computing Machinery. págs. 7–14. doi :10.1145/3437984.3458828.
- ^ Gestión de microservicios con la malla de servicios Istio, Kubernetes, mayo de 2017
- ^ El administrador de paquetes de Kubernetes, Helm
Lectura adicional
- Número especial sobre microservicios, IEEE Software 35(3), mayo/junio de 2018, https://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=8354413
- I. Nadareishvili et al., Arquitectura de microservicios: alineando principios, prácticas y cultura, O'Reilly, 2016, ISBN 978-1-491-95979-4
- S. Newman, Creación de microservicios: diseño de sistemas de grano fino, O'Reilly, 2015 ISBN 978-1491950357
- Wijesuriya, Viraj Brian (29 de agosto de 2016) Arquitectura de microservicios, notas de clase , Facultad de Informática de la Universidad de Colombo, Sri Lanka
- Christudas Binildas (27 de junio de 2019). Patrones arquitectónicos prácticos de microservicios: microservicios Java basados en eventos con Spring Boot y Spring Cloud. Apress. ISBN 978-1484245002 .