Prácticas recomendadas para los servicios canónicos

Nota: Los servicios canónicos son compatibles de forma automática en Cloud Service Mesh versión 1.6.8 y versiones posteriores.

Los servicios canónicos te permiten explorar muchas configuraciones diferentes. Para obtener la mejor experiencia con los paneles de servicio de Cloud Service Mesh, ten en cuenta las siguientes prácticas estándar cuando configures tus servicios:

  • Reserva un servicio único [espacio de nombres, nombre] en toda la malla.
  • Define solo una aplicación de software por servicio canónico.
    • No agrupes los servicios canónicos en todos los entornos (por ejemplo, producción/etapa de pruebas/desarrollo).
    • Usa los paneles de Cloud Monitoring para obtener vistas de nivel superior de varios servicios.
  • Planifica para que los servicios canónicos sean de larga duración en la etapa de producción.

Reserva un servicio único [espacio de nombres, nombre] en toda la malla.

Si un servicio canónico implementado en un clúster o región tiene el mismo nombre y espacio de nombres de Kubernetes que uno implementado en otro clúster o región, Cloud Service Mesh supone que se trata del mismo servicio lógico.

Este comportamiento es coherente con el principio de “similitud” de la flota, que dice que un espacio de nombres debe tener el mismo significado y representar a la misma entidad en toda la flota.

Una aplicación de software por servicio canónico

Los servicios canónicos están destinados a representar un único servicio o microservicio lógico. Están diseñados para abarcar cargas y objetos binarios homogéneos que representen la misma aplicación de software y función empresarial.

Si bien podrías definir un servicio canónico para agrupar varios microservicios diferentes de manera conceptual, los paneles de servicio no proporcionarían su valor completo, ya que mostrarían un conjunto de componentes diferentes que podrían tener rendimientos y parámetros de configuración muy diferentes. Sería difícil o incluso imposible comprender el estado, el rendimiento y la configuración de todo el conjunto.

Las siguientes prácticas no son necesariamente negativas, pero el servicio canónico podría ser demasiado grande si se dan las siguientes situaciones:

  • Existe tráfico de red entre diferentes cargas de trabajo dentro de un único servicio canónico.
  • Un servicio canónico abarca varias cargas de trabajo que se implementan en diferentes programas de actualizaciones.
  • Distintos equipos dentro de tu organización son responsables de operar diferentes partes de un mismo servicio canónico.

No agrupes un servicio canónico en varios entornos

Muchas organizaciones tecnológicas usan varios entornos de implementación para garantizar la calidad del software y limitar el riesgo. A menudo, estos entornos incluyen desarrollo, prueba, staging, producción o algún subconjunto.

Incluso si implementas el mismo servicio conceptual en cada uno de tus diversos entornos, no es una buena práctica convertirlos en un solo servicio canónico. Estos servicios no son iguales y no representan el mismo nivel de preocupación o enfoque operativo para tu organización.

Por ejemplo, una falla en un servicio de producción fundamental podría hacer sonar las alarmas a altas horas de la noche. Seguramente, no necesitas alertar a nadie si la implementación de la fase de desarrollo falla a mitad de la noche. Lo mismo se aplica para comprender el rendimiento, la capacidad y la seguridad de la versión.

Desde los más fáciles pero menos rigurosos hasta el más difícil pero más potente, hay tres maneras de separar los servicios en diferentes entornos:

  1. Sepáralos con varios nombres de servicio, por ejemplo, payments-prod y payments-test.
  2. Sepáralos con varios espacios de nombres, como billing-team y billing-team-test.
  3. Sepáralos con varias flotas, uno para cada entorno.

Usa los paneles personalizados de Cloud Monitoring para agregaciones arbitrarias

En lugar de ampliar artificialmente los servicios canónicos en alcances más grandes para datos agregados, usa los paneles de Cloud Monitoring a fin de crear vistas de nivel superior de varios servicios lógicos a la vez.

Los servicios canónicos están diseñados para ser de larga duración

Más allá de los casos de uso de desarrollo, exploración y prueba, los servicios canónicos deben representar servicios lógicos globales y de alto nivel. Estos servicios cambian lentamente y tienden a durar mucho tiempo. Esta longevidad incluye no cambiar los nombres de servicio. Si bien puedes hacerlo, esto afecta las métricas, los SLO y los registros. Sin embargo, puedes ajustar libremente el campo Display name sin interrupciones.

Un nuevo servicio canónico suele representar software nuevo o actualizado, mientras que un servicio canónico que desaparece suele representar un servicio que deja de estar disponible. Tu habilidad para ver el historial de rendimiento de la capacidad de tu servicio, plan y proyecto depende del mantenimiento de una única noción de ese servicio en Cloud Service Mesh durante su vida útil.

Ten en cuenta que esto contrasta con los recursos de nivel inferior, como las instancias de VM, los pods y las implementaciones de Kubernetes, y hasta con los clústeres completos, que a menudo surgen o dejan de estar disponibles como parte de la actualización y el mantenimiento de los sistemas de producción.

¿Qué sigue?