stringtranslate.com

Microservicios

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]

Introducció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:

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]

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]

Historia

Existen numerosas afirmaciones sobre el origen del término microservicios. Ya en 2005, Peter Rodgers introdujo el término "microservicios web " durante una presentación en la conferencia Web Services Edge. En contra del pensamiento convencional y en el auge de la arquitectura orientada a servicios (SOA) SOAP , defendió los " servicios REST " y en la diapositiva n.° 4 de la presentación de la conferencia, analiza que " los componentes de software son microservicios web". [18] Continúa diciendo que "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 conjuntos de servicios complejos se abstraen detrás de interfaces URI simples . Se puede exponer cualquier servicio, con cualquier granularidad". 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". [18]

El trabajo de Rodgers se originó en 1999 con 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 y de 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 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.

En 2007, Juval Löwy, en sus escritos [20] y discursos [21] [22], hizo un llamado a construir sistemas en los que cada clase fuera un servicio. Löwy se dio cuenta de que esto requería el uso de una tecnología que pudiera soportar ese uso granular de los servicios, y extendió Windows Communication Foundation (WCF) para hacer justamente eso, [23] [24] tomando cada clase y tratándola como un servicio mientras mantenía el modelo de programación convencional de clases.

En mayo de 2011, un taller de arquitectos de software celebrado cerca de Venecia utilizó el término "microservicio" para describir un estilo arquitectónico común que muchos participantes habían estado explorando recientemente. [25] En mayo de 2012, el mismo grupo había decidido que "microservicios" era el nombre más apropiado. James Lewis presentó algunas de esas ideas como un caso de estudio en marzo de 2012 en el 33rd Degree en Cracovia en Microservices - Java, the Unix Way, [26] al igual que Fred George [27] aproximadamente al mismo tiempo. Adrian Cockcroft, ex director de Cloud Systems en Netflix, [28] describió este enfoque como "SOA de grano fino", fue pionero del estilo a escala web, al igual que muchos de los otros mencionados en este artículo: Joe Walnes, Dan North, Evan Bottcher y Graham Tackley. [29]

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 e independientes que se pueden implementar . [7] El enfoque de microservicios es la primera realización de SOA que siguió a la introducción de DevOps y se está volviendo más popular para construir sistemas implementados de forma continua . [30]

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. [31]

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. [32] 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. [33]

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, las responsabilidades y las características arquitectónicas de los usuarios (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. [34]

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:

Críticas y preocupaciones

El enfoque de microservicios está sujeto a críticas por una serie de cuestiones:

Complejidades

La arquitectura introduce complejidad adicional y nuevos problemas con los que lidiar, como latencia , diseño de formato de mensaje , [52] respaldo /disponibilidad/consistencia (BAC), [53] balanceo de carga y tolerancia a fallas . [46] 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. [54] 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. [55] Se han aplicado varios principios de organización (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 . [56] [ página necesaria ] [57]

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. [58]

La Fundación Eclipse ha publicado una especificación para el desarrollo de microservicios, Eclipse MicroProfile. [59] [60]

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 [61] 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 [62] . La siguiente tabla muestra una comparación de una característica de implementación del ecosistema Kubernetes con un equivalente del mundo Spring Cloud. [63] 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

  1. ^ "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 .
  2. ^ Fowler, Martin (2002). Patrones de arquitectura de aplicaciones empresariales . Addison-Wesley Professional. ISBN 978-0321127426.
  3. ^ Fundamentos de la arquitectura de software: un enfoque de ingeniería . O'Reilly Media. 2020. ISBN 978-1492043454.
  4. ^ abcd Martin Fowler. «Microservicios». Archivado desde el original el 14 de febrero de 2018.
  5. ^ Newman, Sam (20 de febrero de 2015). Creación de microservicios . O'Reilly Media. ISBN 978-1491950357.
  6. ^ Wolff, Eberhard (12 de octubre de 2016). Microservicios: arquitecturas de software flexibles . Addison-Wesley. ISBN 978-0134602417.
  7. ^ 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.
  8. ^ abcd Chen, Lianping (2018). Microservicios: arquitectura para la entrega continua y DevOps. Conferencia internacional IEEE sobre arquitectura de software (ICSA 2018). IEEE.
  9. ^ ab Nadareishvili, I., Mitra, R., McLarty, M., Amundsen, M., Arquitectura de microservicios: alineando principios, prácticas y cultura, O'Reilly 2016
  10. ^ "Patrón de backends para frontends". Patrones de diseño de la nube de Microsoft Azure . Microsoft.
  11. ^ Lucas Krause. Microservicios: patrones y aplicaciones . ASIN  B00VJ3NP4A.
  12. ^ Ford, N; Richards, M; Sadalage, P; Dehghani, Z. "Arquitectura de software: las partes difíciles". Thoughtworks . Consultado el 20 de enero de 2023 .
  13. ^ "CI/CD para arquitecturas de microservicios", Centro de arquitectura de Azure, Microsoft . Consultado el 9 de enero de 2018.
  14. ^ Josuttis, N. (2007). SOA en la práctica. Sebastopol, CA, EE. UU.: O'Reilly. ISBN 978-0-596-52955-0 . 
  15. ^ Martin Fowler (28 de agosto de 2014). «Requisitos previos de microservicios». Archivado desde el original el 3 de octubre de 2023.
  16. ^ Richardson, Chris (noviembre de 2018). Patrones de microservicios . Manning Publications. 1.4.1 Cubo de escala y microservicios. ISBN 9781617294549.
  17. ^ 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.
  18. ^ ab 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 .
  19. ^ Russell, Perry; Rodgers, Peter; Sellman, Royston (2004). "Arquitectura y diseño de una plataforma de aplicaciones XML". HP Technical Reports . p. 62 . Consultado el 20 de agosto de 2015 .
  20. ^ Löwy, Juval (2007). Programación de servicios WCF, 1.ª ed . O'Reilly Media. págs. 543–553. ISBN 978-0-596-52699-3.
  21. ^ Juval Löwy "Cada clase es un servicio WCF" (Channel9, ARCast.TV, octubre de 2007).
  22. ^ Juval Löwy "Every Class As a Service" (Conferencia Microsoft TechEd, mayo de 2009), SOA206. Archivado desde el original el 2010.
  23. ^ Löwy, Juval (2007). Programación de servicios WCF, 1.ª ed . O'Reilly Media. pp. 48–51. ISBN 978-0-596-52699-3.
  24. ^ Löwy, Juval (2010). Programación de servicios WCF, 3.ª ed . O'Reilly Media. págs. 74-75. ISBN 978-0-596-80548-7.
  25. ^ Dragoni, Nicola; Giallorenzo, Saverio; Lafuente, Alberto Lluch; Mazzara, Manuel; Montesi, Fabricio; Mustafin, Ruslán; Safina, Larisa (2017). "Microservicios: ayer, hoy y mañana". Ingeniería de Software Presente y Ulterior . págs. 195-216. arXiv : 1606.04036 . doi :10.1007/978-3-319-67425-4_12. ISBN 978-3-319-67424-7.S2CID14612986  .​
  26. ^ James Lewis. "Microservicios: Java, al estilo Unix".
  27. ^ Fred George (20 de marzo de 2013). "Arquitectura de microservicios: un viaje personal de descubrimiento".
  28. ^ Farrow, Rik (2012). "Netflix se dirige a las nubes" (PDF) .
  29. ^ James Lewis y Martin Fowler. "Microservicios".
  30. ^ "Implementación continua: estrategias". javacodegeeks.com . 10 de diciembre de 2014 . Consultado el 28 de diciembre de 2016 .
  31. ^ 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 .
  32. ^ 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
  33. ^ "Mandato SOA de Amazon". 13 de octubre de 2011.
  34. ^ Vaughn, Vernon (2016). Diseño impulsado por el dominio, destilado . Addison-Wesley Professional. ISBN 978-0-13-443442-1.
  35. ^ Yousif, Mazin (2016). "Microservicios". IEEE Cloud Computing . 3 (5): 4–5. doi :10.1109/MCC.2016.101.
  36. ^ 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.S2CID 1643730  .
  37. ^ Newman, Sam (2015). Creación de microservicios . O'Reilly. ISBN 978-1491950357.
  38. ^ Wolff, Eberhard (2016). Microservicios: arquitectura de software flexible . Addison Wesley. ISBN 978-0134602417.
  39. ^ 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.
  40. ^ 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.
  41. ^ Richardson, Chris. "Patrón de arquitectura de microservicios". microservices.io . Consultado el 19 de marzo de 2017 .
  42. ^ 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.
  43. ^ 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.
  44. ^ Stenberg, Jan (11 de agosto de 2014). "Experiencias de fracaso con microservicios".
  45. ^ Calandra, Mariano (7 de abril de 2021). "Por qué las pruebas unitarias no son suficientes cuando se trata de microservicios".
  46. ^ ab "Desarrollo de microservicios para PaaS con Spring y Cloud Foundry".
  47. ^ Tilkov, Stefan (17 de noviembre de 2014). "¿Qué tan pequeño debe ser tu microservicio?". Innoq . Consultado el 4 de enero de 2017 .
  48. ^ 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.
  49. ^ Richardson, Chris (noviembre de 2018). "Capítulo 4. Gestión de transacciones con sagas". Patrones de microservicios . Publicaciones Manning. ISBN 978-1-61729454-9.
  50. ^ 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.
  51. ^ abc Löwy, Juval (2019). Righting Software 1.ª ed . Addison-Wesley Professional. págs. 73–75. ISBN 978-0136524038.
  52. ^ 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.
  53. ^ 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.
  54. ^ Fowler, Martin . "Compensaciones en microservicios".
  55. ^ "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".
  56. ^ Vitillo, Roberto (2021). Entendiendo los sistemas distribuidos: lo que todo desarrollador debe saber sobre las grandes aplicaciones distribuidas . Roberto Vitillo. ISBN 978-1838430207.
  57. ^ 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 .
  58. ^ Wolff, Eberhard (15 de abril de 2018). Microservicios: una guía práctica. Plataforma de publicación independiente CreateSpace. ISBN 978-1717075901.
  59. ^ Swart, Stephanie (14 de diciembre de 2016). "Microperfil de Eclipse". projects.eclipse.org .
  60. ^ "MicroPerfil". MicroPerfil . Consultado el 11 de abril de 2021 .
  61. ^ Netflix OSS, Centro de Git
  62. ^ Nube, primavera
  63. ^ "Spring Cloud para microservicios en comparación con Kubernetes", Desarrolladores , Red Hat, 9 de diciembre de 2016
  64. ^ 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.
  65. ^ Gestión de microservicios con la malla de servicios Istio, Kubernetes, mayo de 2017
  66. ^ El administrador de paquetes de Kubernetes, Helm

Lectura adicional