{"id":21041,"date":"2020-03-04T09:48:45","date_gmt":"2020-03-04T08:48:45","guid":{"rendered":"https:\/\/www.teldat.com\/sin-categorizar\/21041\/service-mesh-arquitectura-de-microservicios\/"},"modified":"2023-11-22T11:46:01","modified_gmt":"2023-11-22T10:46:01","slug":"service-mesh-arquitectura-de-microservicios","status":"publish","type":"post","link":"https:\/\/www.teldat.com\/es\/blog\/service-mesh-arquitectura-de-microservicios\/","title":{"rendered":"Los nuevos retos de las arquitecturas de microservicios"},"content":{"rendered":"

\"microservices\"Las arquitecturas basadas en microservicios<\/strong> est\u00e1n cambiando la forma en la que, a d\u00eda de hoy, dise\u00f1amos el software, lo que plantea nuevos retos en el desarrollo y la operaci\u00f3n.<\/p>\n

Estas arquitecturas est\u00e1n a\u00f1adiendo una fuerte dependencia de la red<\/strong> en la l\u00f3gica de negocio, incrementando el n\u00famero de peligros potenciales, que crecen proporcionalmente a las conexiones o enlaces que se crean entre los servicios.<\/p>\n

<\/p>\n

Arquitectura basada en microservicios vs arquitectura monol\u00edtica<\/h2>\n

La arquitectura monol\u00edtica<\/em> ha sido el modelo de desarrollo de software tradicionalmente utilizado.<\/strong> En esta, el software se compone de una aplicaci\u00f3n unificada y autocontenida, en la que sus componentes est\u00e1n fuertemente acoplados, de tal forma que, un cambio<\/strong> en una peque\u00f1a parte de la aplicaci\u00f3n implica la liberaci\u00f3n de una nueva versi\u00f3n.<\/strong><\/p>\n

La arquitectura de microservicios es una alternativa a la arquitectura monol\u00edtica<\/strong>. Esta, habitualmente, requiere descomponer la aplicaci\u00f3n en m\u00faltiples unidades d\u00e9bilmente acopladas, con el objetivo de tener servicios independientes con operaciones e interfaces<\/strong> definidas, a trav\u00e9s de los cuales interact\u00faan unos con otros para realizar una operaci\u00f3n requerida. Gracias a esta arquitectura nos podemos beneficiar, entre otras cosas, de:<\/p>\n

\u2022 Agilidad<\/strong>
\n\u2022 Innovaci\u00f3n<\/strong>
\n\u2022 Escalabilidad<\/strong>
\n\u2022 F\u00e1cil mantenimiento<\/strong><\/p>\n

Pero este tipo de arquitectura tambi\u00e9n pone sobre la mesa nuevos escenarios<\/strong> que conviene seguir muy de cerca.<\/p>\n

Los nuevos retos de las arquitecturas de microservicios<\/h2>\n

A finales de los a\u00f1os 90, James Glosing<\/strong>, dise\u00f1ador de la m\u00e1quina virtual Java,<\/strong> recogi\u00f3 una lista de falsas suposiciones que pueden hacer a un sistema distribuido ineficiente, inseguro y m\u00e1s dif\u00edcil de mantener. Una arquitectura distribuida necesita ser modelada cuidadosamente,<\/strong> y hacerlo sin manejar expl\u00edcitamente estos problemas es una fuente de fallos. Por lo tanto, es esencial, para una adopci\u00f3n exitosa de la arquitectura de microservicios, desgranar las conjeturas de Glosing:<\/strong><\/p>\n

\u2022 La red es robusta y confiable<\/strong>. Un fallo puede estar causado tanto por el software como por el hardware (por ejemplo,un switch), o un problema en el DNS entre otros servicios externos.
\n\u2022 La latencia es cero.<\/strong> Los lenguajes y librer\u00edas actuales enmascaran la l\u00f3gica repetitiva en la invocaci\u00f3n de llamadas a funciones de servicios remotos, pero los desarrolladores, a veces, asumen que se invocan como si de un servicio local se tratase. Y esto es totalmente falso, una llamada a trav\u00e9s de la red es much\u00edsimo m\u00e1s lenta que una llamada local. Si esta no es apropiadamente tratada se puede bloquear la aplicaci\u00f3n por un largo periodo de tiempo. La ca\u00edda de un servicio es un escenario extremo, que rara vez ocurre. Una situaci\u00f3n mucho m\u00e1s com\u00fan es que un servicio responda con lentitud a causa de la carga.
\n\u2022 El ancho de banda es infinito.<\/strong> Usualmente, la necesidad de una nueva funcionalidad nos lleva a la prematura conclusi\u00f3n de crear un nuevo microservicio para ello. Pero esto tiene un coste para los servicios ya desplegados en t\u00e9rminos de capacidad de red.
\n\u2022 La topolog\u00eda no cambia<\/strong>. Una de las razones por las cuales pueden adoptarse arquitecturas de microservicios es la agilidad. Con la que velozmente se podr\u00e1 construir, liberar y desplegar. Esto implica bajo acoplamiento entre servicios. Un simple escalado horizontal en un servicio puede cambiar flujos de tr\u00e1fico, e insertar fallos inesperados.
\n\u2022 La red es segura.<\/strong> Usualmente las aplicaciones realizan un intercambio en informaci\u00f3n en texto plano, exponiendo datos sensibles, en consecuencia la comunicaci\u00f3n debe estar securizada.
\n\u2022 Hay un solo administrador del sistema.<\/strong> En un entorno basado en microservicios, cada equipo debe ser responsable de mantener y operar sus propios servicios con independencia del resto.
\n\u2022 El coste de transporte es cero.<\/strong> Es importante tener en cuenta que la transferencia de datos consume recursos y puede incurrir tambi\u00e9n en costes.
\n\u2022 La red es homog\u00e9nea<\/strong>. Todo el ecosistema usa el mismo hardware y todos los servicios se comunican a trav\u00e9s de un protocolo est\u00e1ndar. Esta idea es completamente est\u00e9ril en una filosof\u00eda de microservicios formada por equipos de trabajo independientes y aut\u00f3nomos.<\/p>\n

Si profundizamos en cada uno de estos desaf\u00edos, descubriremos que no est\u00e1n relacionados con la l\u00f3gica de negocio de los microservicios, sino con la forma en que los diferentes sistemas interact\u00faan entre s\u00ed. En un ecosistema cloud-native<\/em><\/strong> como el Orquestador kubernetes<\/strong>, estos desaf\u00edos pueden abordarse mediante la implementaci\u00f3n de una service mesh<\/em> o malla de servicios.<\/strong><\/p>\n

En el pr\u00f3ximo art\u00edculo expondremos qu\u00e9 es una malla de servicios y c\u00f3mo nos ayuda a afrontar los nuevos retos.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"

Las arquitecturas basadas en microservicios est\u00e1n cambiando la forma en la que, a d\u00eda de hoy, dise\u00f1amos el software, lo que plantea nuevos retos en el desarrollo y la operaci\u00f3n. Estas arquitecturas est\u00e1n a\u00f1adiendo una fuerte dependencia de la red en la l\u00f3gica de negocio, incrementando el n\u00famero de peligros potenciales, que crecen proporcionalmente a […]<\/p>\n","protected":false},"author":183,"featured_media":19869,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_et_pb_use_builder":"off","_et_pb_old_content":"\"microservices\"Las arquitecturas basadas en microservicios<\/strong> est\u00e1n cambiando la forma en la que, a d\u00eda de hoy, dise\u00f1amos el software, lo que plantea nuevos retos en el desarrollo y la operaci\u00f3n.\r\n\r\nEstas arquitecturas est\u00e1n a\u00f1adiendo una fuerte dependencia de la red<\/strong> en la l\u00f3gica de negocio, incrementando el n\u00famero de peligros potenciales, que crecen proporcionalmente a las conexiones o enlaces que se crean entre los servicios.\r\n\r\n\r\n

Arquitectura basada en microservicios vs arquitectura monol\u00edtica<\/h2>\r\nLa arquitectura monol\u00edtica<\/em> ha sido el modelo de desarrollo de software tradicionalmente utilizado.<\/strong> En esta, el software se compone de una aplicaci\u00f3n unificada y autocontenida, en la que sus componentes est\u00e1n fuertemente acoplados, de tal forma que, un cambio<\/strong> en una peque\u00f1a parte de la aplicaci\u00f3n implica la liberaci\u00f3n de una nueva versi\u00f3n.<\/strong>\r\n\r\nLa arquitectura de microservicios es una alternativa a la arquitectura monol\u00edtica<\/strong>. Esta, habitualmente, requiere descomponer la aplicaci\u00f3n en m\u00faltiples unidades d\u00e9bilmente acopladas, con el objetivo de tener servicios independientes con operaciones e interfaces<\/strong> definidas, a trav\u00e9s de los cuales interact\u00faan unos con otros para realizar una operaci\u00f3n requerida. Gracias a esta arquitectura nos podemos beneficiar, entre otras cosas, de:\r\n\r\n\u2022 Agilidad<\/strong>\r\n\u2022 Innovaci\u00f3n<\/strong>\r\n\u2022 Escalabilidad<\/strong>\r\n\u2022 F\u00e1cil mantenimiento<\/strong>\r\n\r\nPero este tipo de arquitectura tambi\u00e9n pone sobre la mesa nuevos escenarios<\/strong> que conviene seguir muy de cerca.\r\n

Los nuevos retos de las arquitecturas de microservicios<\/h2>\r\nA finales de los a\u00f1os 90, James Glosing<\/strong>, dise\u00f1ador de la m\u00e1quina virtual Java,<\/strong> recogi\u00f3 una lista de falsas suposiciones que pueden hacer a un sistema distribuido ineficiente, inseguro y m\u00e1s dif\u00edcil de mantener. Una arquitectura distribuida necesita ser modelada cuidadosamente,<\/strong> y hacerlo sin manejar expl\u00edcitamente estos problemas es una fuente de fallos. Por lo tanto, es esencial, para una adopci\u00f3n exitosa de la arquitectura de microservicios, desgranar las conjeturas de Glosing:<\/strong>\r\n\r\n\u2022 La red es robusta y confiable<\/strong>. Un fallo puede estar causado tanto por el software como por el hardware (por ejemplo,un switch), o un problema en el DNS entre otros servicios externos.\r\n\u2022 La latencia es cero.<\/strong> Los lenguajes y librer\u00edas actuales enmascaran la l\u00f3gica repetitiva en la invocaci\u00f3n de llamadas a funciones de servicios remotos, pero los desarrolladores, a veces, asumen que se invocan como si de un servicio local se tratase. Y esto es totalmente falso, una llamada a trav\u00e9s de la red es much\u00edsimo m\u00e1s lenta que una llamada local. Si esta no es apropiadamente tratada se puede bloquear la aplicaci\u00f3n por un largo periodo de tiempo. La ca\u00edda de un servicio es un escenario extremo, que rara vez ocurre. Una situaci\u00f3n mucho m\u00e1s com\u00fan es que un servicio responda con lentitud a causa de la carga.\r\n\u2022 El ancho de banda es infinito.<\/strong> Usualmente, la necesidad de una nueva funcionalidad nos lleva a la prematura conclusi\u00f3n de crear un nuevo microservicio para ello. Pero esto tiene un coste para los servicios ya desplegados en t\u00e9rminos de capacidad de red.\r\n\u2022 La topolog\u00eda no cambia<\/strong>. Una de las razones por las cuales pueden adoptarse arquitecturas de microservicios es la agilidad. Con la que velozmente se podr\u00e1 construir, liberar y desplegar. Esto implica bajo acoplamiento entre servicios. Un simple escalado horizontal en un servicio puede cambiar flujos de tr\u00e1fico, e insertar fallos inesperados.\r\n\u2022 La red es segura.<\/strong> Usualmente las aplicaciones realizan un intercambio en informaci\u00f3n en texto plano, exponiendo datos sensibles, en consecuencia la comunicaci\u00f3n debe estar securizada.\r\n\u2022 Hay un solo administrador del sistema.<\/strong> En un entorno basado en microservicios, cada equipo debe ser responsable de mantener y operar sus propios servicios con independencia del resto.\r\n\u2022 El coste de transporte es cero.<\/strong> Es importante tener en cuenta que la transferencia de datos consume recursos y puede incurrir tambi\u00e9n en costes.\r\n\u2022 La red es homog\u00e9nea<\/strong>. Todo el ecosistema usa el mismo hardware y todos los servicios se comunican a trav\u00e9s de un protocolo est\u00e1ndar. Esta idea es completamente est\u00e9ril en una filosof\u00eda de microservicios formada por equipos de trabajo independientes y aut\u00f3nomos.\r\n\r\nSi profundizamos en cada uno de estos desaf\u00edos, descubriremos que no est\u00e1n relacionados con la l\u00f3gica de negocio de los microservicios, sino con la forma en que los diferentes sistemas interact\u00faan entre s\u00ed. En un ecosistema cloud-native<\/em><\/strong> como el Orquestador kubernetes<\/strong>, estos desaf\u00edos pueden abordarse mediante la implementaci\u00f3n de una service mesh<\/em> o malla de servicios.<\/strong>\r\n\r\nEn el pr\u00f3ximo art\u00edculo expondremos qu\u00e9 es una malla de servicios y c\u00f3mo nos ayuda a afrontar los nuevos retos.<\/strong>","_et_gb_content_width":"","footnotes":""},"categories":[1156],"tags":[1102],"class_list":["post-21041","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-servicios-en-la-nube","tag-servicios-micro"],"acf":[],"wpml_current_locale":"es_ES","wpml_translations":[{"locale":"en_US","id":19866,"slug":"service-mesh-microservices-architecture","post_title":"The operational challenges of distributed software architecture","href":"https:\/\/www.teldat.com\/service-mesh-microservices-architecture\/"}],"_links":{"self":[{"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/posts\/21041","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/users\/183"}],"replies":[{"embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/comments?post=21041"}],"version-history":[{"count":0,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/posts\/21041\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/media\/19869"}],"wp:attachment":[{"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/media?parent=21041"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/categories?post=21041"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/tags?post=21041"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}