Notación de Plataforma

Los límites de mi lenguaje son los límites de mi mundo.

La arquitectura a menudo se pierde en la traducción. Cuando describimos una plataforma, solemos confiar en una mezcla de diagramas de alto nivel, jerga específica de proveedores y prosa ambigua. Un “clúster” puede significar un conjunto físico de servidores para una persona y un límite lógico de aislamiento para otra. En Azure hablamos de “Suscripciones”; en AWS, de “Cuentas”; en GCP, de “Proyectos”. Estos términos no son solo etiquetas diferentes; conllevan comportamientos sutiles y específicos de cada proveedor que nublan nuestra intención arquitectónica.

Para construir una plataforma profesional, necesitamos un lenguaje compartido que sea preciso, agnóstico de proveedores y legible tanto por humanos como por máquinas. Este libro introduce la Notación de Plataforma: un lenguaje de definición estructural diseñado para expresar ubicaciones de infraestructura, relaciones y tipos con claridad matemática.

¿Por qué una nueva notación?

Podrías preguntarte por qué no usamos simplemente Infraestructura como Código (IaC) estándar como Terraform o manifiestos YAML. Si bien esas herramientas son excelentes para la implementación, son demasiado prolijas y pesadas para el diseño.

Usamos la Notación de Plataforma por tres razones:

1. Neutralidad de Proveedor: Nos permite discutir el “qué” y el “dónde” sin perdernos en el “cómo” de un proveedor de nube específico.
2. Vocabulario Compartido: Crea un puente entre el ingeniero de plataforma que diseña el sistema y los agentes de IA que ayudan a construirlo. Cuando una IA entiende la notación, puede generar código consistente y conforme a las políticas en cualquier proveedor.
3. Precisión Arquitectónica: Nos obliga a ser explícitos sobre los límites. Si no puedes expresar un límite en la notación, probablemente no sea un límite bien definido en tu arquitectura.

La gramática de la plataforma

La notación se construye sobre tres primitivas simples: Tipos, Coordenadas y Colecciones.

Tipos

Un Tipo define qué es un recurso. Utiliza una sintaxis funcional: Nombre(Parámetros).

El nombre del tipo representa un concepto arquitectónico específico o un primitivo de nube. Los parámetros definen su alcance o características.

Tipo(Parámetro1, Parámetro2, ...)

Por ejemplo, un límite de red genérico podría expresarse como Network(Alcance). Un recurso de nube específico podría expresarse como AzureSubscription(Contexto).

Inferencia Posicional

Para mantener la notación concisa, utilizamos la inferencia posicional. Esto significa que si hemos definido un conjunto estándar de parámetros para un tipo, podemos omitir los nombres de los parámetros siempre que los valores estén en el orden correcto.

• Explícito: Group(Tenant = "payments", Tier = "live", Role = "admin")
• Inferido: Group("payments", "live", "admin")

A lo largo de este libro, utilizaremos consistentemente cadenas de texto limpias para los parámetros dentro de las llamadas funcionales, confiando en la definición del tipo para proporcionar el contexto.

Coordenadas

Una Coordenada define dónde vive un recurso. Se expresa como una tupla: una lista de valores separados por comas dentro de paréntesis.

(Dimensión1, Dimensión2, ...)

Las coordenadas actúan como la “dirección” de cada recurso en la plataforma. En los próximos capítulos, definiremos un sistema de coordenadas estándar de cuatro dimensiones que organiza todo nuestro mundo. Si una dimensión específica no es relevante para un recurso, utilizamos un guion bajo (_) para indicar que se ignora.

• ("ecommerce", "live", "eu01", "payments"): Una dirección totalmente resuelta.
• ("platform", "live", _, _): Una dirección que ignora las dimensiones regionales y de tenant.

Colecciones

Cuando necesitamos hacer referencia a un conjunto de recursos en lugar de a una sola instancia, utilizamos Colecciones. Denotamos una colección añadiendo corchetes [] a un tipo y utilizando el símbolo comodín * dentro de los parámetros.

• Tipo[](Dimensión = "*"): Una colección de todas las instancias de ese tipo a través de cada valor de esa dimensión.

Por ejemplo, si queremos referirnos a cada red de producción en todos nuestros sectores de negocio, podríamos escribir: Network[](Sector = "*", Tier = "live").

Asociaciones

La arquitectura no se trata solo de componentes aislados; se trata de cómo se relacionan entre sí. Para expresar estas relaciones, la Notación de Plataforma utiliza Asociaciones.

Aunque puedes utilizar verbos funcionales como Assign(Group, Role), la notación proporciona tres operadores simples y agradables de leer para las relaciones más comunes:

1. Jerarquía (in): Expresa pertenencia o contención.
   • Identity in Group("payments", "live", "reader")
2. Mapeo Estructural (=>): Expresa implementación o realización. Utilízalo para vincular un concepto abstracto a un primitivo de nube concreto.
   • Space("payments", "live", ...) => AzureResourceGroup(...)
3. Conectividad Lógica (<->): Expresa un enlace bidireccional o una ruta de comunicación.
   • Spoke("ecommerce", "live", "eu01") <-> Hub("platform", "live", "eu01")

Al combinar tipos, coordenadas y asociaciones, podemos describir todo el “grafo” de la plataforma con la mínima ambigüedad.

Revelando la plataforma

No introduciremos todos los tipos y dimensiones específicos en este capítulo. En su lugar, iremos revelando el lenguaje a medida que construimos la plataforma:

• En el Capítulo 4 (Segmentación), definiremos las dimensiones que forman nuestro sistema de coordenadas.
• En el Capítulo 5 (Gestión de Identidad y Acceso), introduciremos los tipos para roles y grupos de autorización.
• En el Capítulo 6 (Infraestructura), mapearemos estos tipos abstractos a primitivos de nube concretos como VPCs, Cuentas y Suscripciones.

Al final de este libro, esta notación abreviada te permitirá describir toda una plataforma global y multi-tenant en solo unas pocas líneas de definiciones precisas y matemáticas.