Todo en una cuenta
Es el punto de partida más habitual: una sola cuenta (o suscripción, o proyecto) donde conviven desarrollo, pruebas y producción, de varias aplicaciones y varios equipos. Funciona mientras es pequeño. Después, cada permiso que se da es demasiado amplio, cada error puede alcanzar a producción y nadie sabe qué parte de la factura es de quién.
Una jerarquía con intención
Los tres grandes proveedores permiten organizar sus cuentas en una jerarquía (con nombres distintos en cada uno: organizaciones y unidades, grupos de administración y suscripciones, organización y carpetas). La estructura que mejor funciona suele tener estos niveles:
- La organización, con las reglas que valen para todo.
- Unidades por propósito: plataforma compartida (red, identidad, registros), cargas de trabajo de negocio, espacios aislados para experimentar.
- Entornos dentro de cada unidad: desarrollo, aceptación, producción, separados de verdad.
- Cuentas por aplicación o equipo, con su dueño.
Lo que se gana sin escribir una sola regla
Aislamiento. Un error o un ataque en la cuenta de desarrollo de una aplicación no alcanza a producción de otra.
Permisos acotados. Dar acceso a "la cuenta de aceptación de pedidos" es mucho más preciso que dar acceso a una cuenta compartida.
Costo asignado por construcción. Todo lo que ocurre en una cuenta ya tiene dueño (la forma más robusta de asignar el costo).
Políticas por nivel. Lo que se aplica a una unidad lo heredan todas sus cuentas, como veremos dos artículos más adelante.
Diseñarla al principio
Mover recursos entre cuentas después es costoso y a veces imposible sin recrearlos. Por eso la estructura se diseña al principio, se escribe en la norma y se crea con infraestructura como código, para que cada cuenta nueva nazca en su sitio y con sus reglas.
Una estructura de cuentas bien hecha multiplica el número de cuentas. Y eso trae la siguiente pregunta: cómo saber quién es quién en todas ellas.
Cómo lo aplicamos: Gobierno Multicloud.