Prácticas recomendadas para los servicios canónicos

Nota: Los servicios canónicos se admiten automáticamente en Cloud Service Mesh 1.6.8 y versiones posteriores.

Los servicios canónicos te permiten explorar muchas configuraciones diferentes. Para obtener la mejor experiencia con Cloud Service Mesh Paneles de servicio, 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 y el nombre del servicio canónico, como uno implementado en otro clúster o Cloud Service Mesh supone que es el 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 conceptualmente diferentes, los paneles de servicio no proporcionarían su valor completo. Los paneles de servicio mostrarían una agregación de componentes dispares que podrían tener un rendimiento y una configuración muy diferentes de forma individual. 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 se debe agrupar un servicio canónico entre los 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. No debes alertar a nadie si la cadena “dev” el objeto Deployment falla en en medio de la noche. Lo mismo se aplica para comprender el rendimiento, la capacidad y la seguridad de la versión.

Desde las más fáciles, pero menos rigurosas, hasta las que más se esfuerzan y son más poderosas, Existen tres maneras de separar servicios en entornos diferentes:

  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 capacidad para ver el historial de rendimiento de tu servicio, plan y proyecto dependen de mantener una noción única de ese servicio en Cloud Service Mesh por toda 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?