Resumen
Crear nombres significativos para servicios, que sea poco probable que cambien con el tiempo y que no repliquen datos en identificadores existentes, componiendo el nombre de tres elementos que describen lo que hace el servicio.
Nombre del Servicio
SemServ = [Espacio de Nombres] - [Dominio | Entidad] - [Rol]
Donde
[Espacio de Nombres] - una palabra o cadena opcional utilizada para nombrar un área o subsistema de la solución general.
[Dominio | Entidad] - un sustantivo que describe el Dominio O entidad principal sobre la que opera el servicio.
[Rol] la responsabilidad principal del servicio en el dominio, o lo que hace hacia, o para, la entidad.
Usa los nombres de servicios como raíz para nombrar otros objetos
Ejecutable del Servicio
[SemServ] : [SemVer]
Nombre de Despliegue del Servicio
[SemServ] : [EstrategiaDeDespliegue]
Nombre de Instancia del Servicio
[SemServ] : [EstrategiaDeDespliegue] : [IdDeInstancia]
Introducción
Cuando los sistemas basados en la nube maduran, entran en una fase de evolución continua: se agregan nuevos servicios, los servicios antiguos se deprecan y retiran, los monolitos se descomponen, y los despliegues crecen y se extienden por múltiples regiones y zonas. Los orquestadores de contenedores y las soluciones sin servidor aceleran este proceso al permitir que los servicios cobren vida bajo demanda y desaparezcan cuando no son necesarios.
Los responsables de desarrollar y operar sistemas grandes luchan por dar sentido a soluciones que comprenden cientos de servicios con nombres sin sentido, obscuros y dispares. Estas soluciones son una pesadilla para operar y evolucionar. Cualquier intento de cambio debe comenzar con una expedición arqueológica de proporciones desconocidas para primero identificar el alcance del cambio, ya que los ingenieros que desarrollaron el sistema a menudo ya no están.
Para empeorar las cosas, los nombres de servicios a menudo comprenden elementos semánticos que ya no son verdaderos: los nombres de organizaciones que ya no existen, detalles de despliegue que han cambiado, tecnologías de implementación que han sido retiradas, etc.
Como solución a este problema, proponemos un conjunto simple de reglas que dictan cómo deben crearse los nombres de servicios. Estas reglas se basan en prácticas comunes generalizadas utilizadas por muchas de las empresas con las que hemos trabajado y evitan muchos de los problemas que hemos encontrado.
Para que este enfoque funcione, debes identificar los subdominios y entidades de tu sistema y las acciones realizadas sobre estos objetos. Ya conoces estos términos; están incrustados en el lenguaje que usas para describir tu solución.
Llamamos a este sistema “Nomenclatura Semántica de Servicios” (SemServ) inspirándonos en el Versionado Semántico (SemVer) porque los nombres creados bajo este esquema transmiten significado sobre el propósito y función subyacentes del servicio, evitan deliberadamente duplicar información almacenada en otros lugares por proveedores de PaaS e IaaS y no incluyen datos que probablemente cambien causando que los nombres de servicios queden desactualizados y confusos. Este enfoque no resolverá todos los problemas con los nombres de servicios, pero cuando se combina con un buen esquema de etiquetado, reducirá o evitará muchos de los problemas más comunes.
Especificación de Nomenclatura Semántica de Servicios (SemServ)
Las palabras clave “DEBE”, “NO DEBE”, “REQUERIDO”, “DEBERÁ”, “NO DEBERÁ”, “DEBERÍA”, “NO DEBERÍA”, “RECOMENDADO”, “PUEDE”, y “OPCIONAL” en este documento deben interpretarse como se describe en RFC 2119.
Todos los nombres de servicios DEBEN estar compuestos de al menos dos partes descriptivas
Primero el [Dominio | Entidad]
Segundo, el [Rol] que el servicio desempeña con respecto al dominio o entidad.
Ejemplos: Payment-Processor, Settlement-Distributor, Job-Scheduler, Ticket-Dispatcher. etc.En soluciones grandes, donde múltiples servicios comprenden un solo subsistema, cada servicio en el subsistema PUEDE recibir un prefijo común o [Espacio de Nombres]. Los espacios de nombres NO DEBERÍAN nombrarse según cosas que PUEDAN cambiar, como Nombres de Organizaciones, sino que DEBERÍAN recibir nombres arbitrarios, fáciles de recordar, distintivos o nombres que describan el área funcional general
Ejemplos: Hydra, Periscope, Albion, Toolchain, Finance, etc.Los [Espacios de Nombres] PUEDEN agruparse en temas para indicar alguna característica común invariante entre subsistemas.
Ejemplos: Diosas Nórdicas; Eir, Skuld, y Weth, para subsistemas de observabilidad o Ríos Antiguos; Finke, Meuse, Rhine para subsistemas de mensajería.El [Espacio de Nombres], [Dominio | Entidad], y [Rol] DEBEN estar separados por un “-”
Ejemplos Finke-Message-Decorator, Toolchain-Pipeline-Scheduler, o simplemente Payment-Processor si no se requiere espacio de nombres.Los nombres de componentes de múltiples partes PUEDEN usarse pero cada parte DEBE indicarse mediante un cambio de mayúsculas o por “_” y NO DEBE separarse por un “-”
Ejemplo PaymentFraud-Monitor, o Payment_Fraud-monitorUn Nombre de Servicio Semántico DEBE identificar únicamente un servicio lógico dentro de un Sistema. El servicio lógico es distinto de sus varias estrategias de despliegue, instancias, o ejecutables versionados cuyos nombres DEBERÍAN derivarse todos del Nombre del Servicio.
Ejemplos: El Servicio Lógico Hydra-Job-Scheduler puede usarse como raíz para los siguientes nombresEjecutable del Servicio
[SemServ] : [SemVer]
Hydra-Job-scheduler:7.12.4Nombre de Despliegue del Servicio
[SemServ] : [EstrategiaDeDespliegue]
Hydra-Job-Scheduler:Green
Hydra-Job-Scheduler:Blue
Hydra-Job-Scheduler:CanaryNombre de Instancia del Servicio
[SemServ] : [EstrategiaDeDespliegue] : [IdDeInstancia]
Hydra-Job-Scheduler:Green:0b22a22eec53b9321Depende de ti asegurarte de poder distinguir entre diferentes tipos de objetos. Por ejemplo, una lista que contenga una mezcla de ejecutables, despliegues e instancias de los ejemplos anteriores puede ser confusa a menos que sepas cómo distinguir entre un SemVer, una EstrategiaDeDespliegue y un IdDeInstancia. La coincidencia de patrones RegEx puede ser útil a este respecto.
Por qué usar Nomenclatura Semántica de Servicios
Todos los servicios requieren nombres. Cualquiera que haya trabajado en una solución SaaS grande y exitosa puede dar fe de que hay muchas convenciones de nomenclatura posibles, algunas útiles, otras no. La convención SemServ está diseñada para ser simple y duradera, requiriendo pocos cambios a lo largo del tiempo, y actúa como base para nombrar muchos otros conceptos, como despliegues, ejecutables y nombres de instancias.
Creemos que el nombre de un servicio debe describir lo que hace el servicio y nada más! Quién es dueño del servicio, qué tecnologías implementa, qué tipo de recurso es, cómo se despliega, y qué versión es, son todas piezas importantes de información, pero no tienen lugar en el nombre del servicio. No tienen lugar en el nombre del servicio porque usualmente se pueden encontrar en otros lugares y es probable que cambien durante la vida del servicio, y renombrar servicios una vez que están desplegados es tan oneroso que a menudo se evita, resultando en confusión y mucho tiempo perdido.
El nombre de un servicio debe reflejar su propósito central ya que es poco probable que esto cambie durante su vida. SemServ está diseñado para evitar muchos problemas y resolver UNO - Proporcionar una forma simple y útil de nombrar servicios que es poco probable que cambie durante la vida del servicio.
Preguntas Frecuentes
¿Por qué no debería poner la cuenta, región o tipo de recurso en el nombre del servicio?
Los proveedores comerciales de IaaS y PaaS identifican cada recurso con una URI. Esta URI está compuesta de información útil que puede extraerse según sea necesario. Esta información NO DEBERÍA incluirse en el nombre del servicio ya que es redundante. Típicamente, los identificadores de recursos contienen la región o ubicación, la cuenta o proyecto, y el tipo de recurso y nombre o id del recurso. No hay necesidad de duplicar esto en el nombre, ya está en el identificador del recurso. Si cualquiera de estos elementos cambia, entonces el identificador del recurso cambiará automáticamente y el nombre o id del servicio puede permanecer igual.
AWS identifica TODOS los recursos con un Nombre de Recurso de Amazon (ARN)
arn:partition:service:region:account-id:resource-type/resource-id
Azure identifica recursos con un ID de Recurso de Azure
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{providerNamespace}/{resourceType}/{resourceName}
GCP identifica todos los recursos con Nombres de Recursos
projects/project_id/locations/location_id/resourceType/resource_id
O, para recursos que son globales o no están vinculados a una ubicación específica, el formato podría ser más simple:
projects/project_id/resourceType/resource_id
En resumen. Es más fácil aprender cómo obtener la URI para un recurso que cambiar su nombre frecuentemente.
¿Qué pasa con los Entornos?
Con los entornos, tienes opciones. Poder distinguir fácilmente entre un servicio en producción o un servicio en un entorno de verificación es importante. Hay varias formas en que esto puede lograrse sin incrustar la información en el nombre del servicio.
- Usar diferentes cuentas o proyectos para cada entorno. Esto tendrá el efecto de codificar el entorno en la URI
- Usar una etiqueta de entorno. Pero asegúrate de que tu proceso de despliegue garantice que cada recurso desplegado obtenga una etiqueta. Esto no es tan fácil como parece cuando los recursos se crean y destruyen elásticamente.
- Agregar el entorno al nombre del servicio si es necesario, pero recuerda renombrar cada servicio cuando despliegues a un nuevo entorno.
¿Qué pasa con los otros datos que actualmente codifico en nombres?
Los elementos semánticos restantes típicamente utilizados por las empresas; Organizaciones, Clientes, Proyectos, Productos, Tecnologías etc. deben asignarse a etiquetas. Las etiquetas de metadatos están disponibles de todos los proveedores populares, AWS, GCP, Azure etc. Hay límites en el número y complejidad de etiquetas que estos proveedores soportarán, así que elige unas pocas y diseña taxonomías facetadas o jerárquicas simples y fáciles de entender que tu organización pueda gestionar efectivamente a medida que cambien lentamente con el tiempo. Reaplicar etiquetas cada vez que despliegues un servicio. También debes desarrollar procesos para actualizar etiquetas incluso cuando el servicio no se está desplegando. Por ejemplo, cuando ocurre una reorganización en tu empresa y los servicios cambian de propiedad organizacional.
¿Qué pasa si es solo un servicio temporal?
Los servicios temporales frecuentemente se vuelven permanentes o duraderos. Si te vas a tomar la molestia de crear un servicio, entonces dale un nombre significativo.
¿Qué pasa si tengo un servicio que hace más de una cosa?
Si un servicio hace más de una cosa, entonces probablemente es un monolito. Debería considerarse dividirlo en servicios más pequeños que hagan una cosa bien. Si no puede dividirse, entonces aún debería tener un nombre que describa la función principal del servicio - debe tener algún propósito general que puedas articular. Si no se puede hacer eso, entonces debería considerarse renombrar el servicio a algo como “ServicioGenérico” o “ServicioMonolito”, pero si esto es lo mejor que puede hacerse entonces probablemente hay problemas más grandes que nombrar los servicios.
Gramática en Forma Backus-Naur
Un nombre de servicio normal en la gramática de la forma Backus-Naur es:
<valid-semserv> ::= <semserv-core> | <namespaced-semserv>
<namespaced-semserv> ::= <namespace> "-" <semserv-core>
<semserv-core> ::= <domain-entity> "-" <role>
<namespace> ::= <word>
<domain-entity> ::= <word>
<role> ::= <word>
<word> ::= <simple-word> | <compound-word>
<simple-word> ::= <letter> <word-char>*
<compound-word> ::= <camel-word> | <underscore-word>
<camel-word> ::= <letter> <word-char>* <capital-part>+
<capital-part> ::= <uppercase> <word-char>*
<underscore-word> ::= <simple-word> <underscore-part>+
<underscore-part> ::= "_" <simple-word>
<word-char> ::= <letter> | <digit>
<letter> ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h"
| "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p"
| "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x"
| "y" | "z" | "A" | "B" | "C" | "D" | "E" | "F"
| "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N"
| "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V"
| "W" | "X" | "Y" | "Z"
<uppercase> ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H"
| "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P"
| "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X"
| "Y" | "Z"
<digit> ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7"
| "8" | "9"
ACERCA DE
La especificación de Nomenclatura Semántica de Servicios fue inspirada por SemVer y fue originalmente escrita por John R. Harris, cofundador de SPAN Digital.
Si quieres dejar comentarios, por favor abre un issue en GitHub