Header Ads Widget

Ticker

6/recent/ticker-posts

Cómo Service Mesh previene un desorden de microservicios


 Uno de los mayores desafíos que enfrenta la arquitectura de microservicios es el crecimiento. Eso puede parecer contradictorio, pero a menudo es el caso, particularmente en la modernización heredada .

“Cuando hablamos de microservicios, a menudo hablamos de fragmentar un monolito existente en un montón de piezas más pequeñas”, dijo Geir Sjurseth de Google en nuestra Cumbre de Plataformas 2019 en Estocolmo.

Cuanto más se expande una arquitectura de microservicios, lo que a menudo equivale a más desintegración del monolito existente, más densa se vuelve la red de microservicios. Pero, en opinión de Sjurseth, la alternativa tampoco es demasiado atractiva:

“En lugar de descomponer el monolito existente, podríamos simplemente envolverlo con una API”, dice. Pero en realidad, argumenta, eso es simplemente "maquillar a un cerdo".

¿La solución? Malla de servicio .

El objetivo de usar una malla de servicios es, para usar las palabras de Google del video vinculado justo debajo, aumentar la velocidad del producto, administrar la complejidad del código, admitir la heterogeneidad y empoderar a los desarrolladores. Si está trabajando en microservicios, seguramente sonará bastante atractivo.

¿Qué es una malla de servicios?

En una charla en su canal de YouTube, Google Cloud Platform describe la malla de servicios como "una forma de generar inteligencia en la red". Eso es cierto, pero es un poco vago.

En otra parte de nuestro sitio , lo hemos expresado así: "La malla de servicios es un patrón de diseño que proporciona un marco de trabajo de red común, lo que ayuda a resolver un problema de introducir una arquitectura de microservicios".

El objetivo aquí es abordar un conjunto particular de problemas, definidos por Sjurseth de la siguiente manera: “Quiero que mi cliente tenga una buena experiencia, así que no quiero que tenga que usar SOAP para este servicio, REST para este servicio y algo de XML personalizado y original para este otro servicio ".

Es justo decir que la malla de servicios tiene como objetivo mejorar la consistencia, pero, como veremos a partir de los puntos de Sjurseth, hay más que eso.

¿Por qué utilizar Service Mesh?

En su charla, Sjurseth describe algunas de las ventajas de la malla de servicios de la siguiente manera:

  • Conectar : controle el flujo de tráfico, pruebas flexibles, implementaciones azul / verde
  • Seguro : proteja automáticamente sus servicios con autenticación, autorización y comunicación cifrada
  • Control : aplique políticas y asegúrese de que se cumplan en todos los servicios, administre el tráfico para usar los recursos de manera justa en todos los servicios
  • Observe : registro, seguimiento y seguimiento operativos enriquecidos

Además, la malla de servicios nos permite:

  • Gestionar la adición de mTLS
  • Aprovisionar certificados, distribuir políticas, recopilar registros
  • Delega toda la complejidad a un proxy (o sidecar)

Con esto resuelto, los desarrolladores pueden enfocar su atención donde corresponde: en las API que están construyendo en lugar de asegurar los servicios y administrar el tráfico. Ahora, considere esto junto con algunas de las ventajas de una gestión de API sólida:

  • Descubrir : el uso de un portal para desarrolladores hace que sus API sean detectables para los desarrolladores
  • Modernizar : usar un enfoque de afuera hacia adentro para diseñar API que la gente quiera consumir
  • Informe : acceso a métricas como la adopción por parte de los desarrolladores y el uso de la aplicación
  • Monetizar : genere ingresos a partir de sus datos y servicios

Sjurseth sugiere que, al combinar estos dos conceptos, podemos crear un entorno más óptimo para el consumo de API. Los clientes internos pueden conectarse directamente, mientras que los clientes externos se conectan a través de la puerta de enlace API.

Sin embargo, existe un problema potencial que persiste con este enfoque ...

Containerización y malla de servicios

A medida que agregamos más y más servicios, existe el riesgo de que terminemos con "una puerta de enlace que intenta facilitar todas estas piezas diferentes de una manera que realmente no puede manejar porque se implementan de forma independiente".

El resultado de esto es un lío de dependencias de las que es difícil realizar un seguimiento. Uno de los mayores escollos de la arquitectura de microservicios es que cuanto más "micro" haga las cosas, más servicios probablemente terminará administrando.

Una posible solución ofrecida por Sjurseth es contener estos servicios dentro de, digamos, un clúster de Kubernetes y agregar algo como Istio a eso con un adaptador Apigee.

Dos ventajas distintas de este enfoque son que las políticas de seguridad se pueden implementar en diferentes niveles de granularidad (servicio, espacio de nombres, malla) y todo se puede controlar desde un punto central, pero se mantiene el control sobre los elementos individuales. Además, tenemos un plano de control enchufable a través de Istio.

La idea de Sjurseth se puede resumir en una sola idea: los servicios y la API necesitan administración:

¿La razón de eso? Sin una malla de servicios, es muy fácil que la arquitectura de microservicios se vuelva desordenada, con los desarrolladores trabajando en su propio pequeño silo, sin ninguna coherencia entre sus resultados.

Eso puede parecer una aspiración para los desarrolladores solitarios que trabajan en un solo microservicio, pero eso es lo que pasa con los proyectos de microservicios; rara vez permanecen micro por mucho tiempo.

Pensamientos finales

En un mundo futuro, la malla de servicios y los microservicios pueden convertirse en sinónimos. Todavía no hemos llegado a ese punto, tal vez porque los orquestadores de contenedores como Kubernetes aliviaron muchos dolores de cabeza asociados con la arquitectura de microservicios. Sin embargo, en 2020 las mallas de servicio ganaron fuerza.

Además de Istio, Linkerd, Kuma y OpenShift, Amazon lanzó AWS App Mesh en 2019. Eso es notable porque, como hemos visto antes, a menudo es el caso donde Amazon lidera (incluso cuando no son los primeros en comercializar) , otros tienden a seguir.

Con tantas herramientas de malla de servicios de código abierto , Istio fue de código abierto en 2017 y Linkerd ha sido impulsado por la comunidad desde sus inicios, no es como si hubiera un alto costo asociado con la adopción de una malla de servicios, lo cual siempre es útil. para adopción.

Hasta cierto punto, la popularidad futura de la malla de servicios dependerá del crecimiento continuo de los microservicios. Probablemente no necesite que le digamos que es un espacio que no muestra signos de desaceleración en el corto plazo.

Publicar un comentario

0 Comentarios