EDGEROUTING / TLS
DEFINE01.2ARCHITECTURE & DEPLOYMENT
Diseñe antesde poner en producción.
Diseñamos y desplegamos infraestructura alrededor de las necesidades reales del sistema, considerando operación, seguridad, observabilidad y recuperación desde el inicio.
01.2.1ARQUITECTURA
La infraestructuratambién necesita diseño.
Una aplicación no existe de forma aislada. Depende de servidores, redes, almacenamiento, acceso, certificados, respaldos y procesos operativos.
Diseñar infraestructura significa decidir cómo se conectan esas piezas y qué responsabilidades tendrá cada una durante la operación.
Buscamos arquitecturas suficientemente simples para entenderse y suficientemente estructuradas para crecer cuando la necesidad lo requiera.
01.2.2QUÉ DISEÑAMOS
La arquitectura depende del problema, no de una plantilla fija que obligue a todos los sistemas a operar igual.
01⌁
COMPUTE
Entorno de ejecución
Definimos dónde y cómo operará la aplicación, considerando recursos, aislamiento y mantenimiento.
02◎
NETWORK
Red y exposición
Revisamos qué componentes necesitan comunicarse, cuáles deben ser públicos y cuáles deben permanecer restringidos.
03▰
APPLICATION
Componentes de aplicación
Organizamos servicios, dependencias y límites operativos alrededor del sistema.
04⌖
OBSERVABILITY
Visibilidad operativa
Definimos qué señales serán necesarias para saber si el sistema está funcionando como se espera.
05↺
RECOVERY
Respaldo y recuperación
Consideramos desde el diseño qué debe respaldarse y cómo podría restaurarse el servicio.
06+
ACCESS
Acceso administrativo
Definimos quién necesita acceso, con qué privilegios y bajo qué responsabilidades.
01.2.3DESIGN PRINCIPLE
COMPLEXITY MUST BE JUSTIFIEDComplejidadsólo cuando resuelve algo.
Una arquitectura con más componentes no es necesariamente una arquitectura mejor.
Cada servicio, dependencia y capa adicional aumenta la cantidad de elementos que deben mantenerse, observarse y recuperarse.
Por eso preferimos comenzar con la arquitectura más simple que pueda cumplir correctamente los requisitos conocidos.
ARCHITECTURE REVIEWCOMPARING
REQUIREMENTAPPLICATION DELIVERY
REQUIREDCOMPONENTEDGE ROUTING
JUSTIFIEDCOMPONENTEXTRA SERVICE
QUESTIONDECISIONREMOVE COMPLEXITY
SIMPLIFY01.2.4PROCESO
Del requisitoa un entorno operable.
Diseñar y desplegar son partes del mismo problema: la arquitectura necesita poder implementarse, mantenerse y explicarse.
UNDERSTAND
Entender
Revisamos aplicación, usuarios, dependencias, criticidad y restricciones.
DESIGN
Diseñar
Definimos componentes, comunicación, accesos y responsabilidades.
PREPARE
Preparar
Configuramos infraestructura y requisitos necesarios para recibir la aplicación.
DEPLOY
Desplegar
Llevamos el sistema al entorno acordado mediante un proceso controlado.
VERIFY
Validar
Confirmamos funcionamiento, accesibilidad y señales operativas relevantes.
01.2.5 / DEPLOYMENTFROM BUILD TO PRODUCTION
Producción no deberíaser una improvisación.
El despliegue necesita una secuencia conocida, controles mínimos y una forma clara de verificar que el resultado es el esperado.
ENVIRONMENT
Preparar entorno
Configurar infraestructura, accesos y dependencias necesarias.
APPLICATION
Desplegar sistema
Llevar aplicación y configuración al entorno acordado.
VALIDATION
Verificar
Confirmar rutas, servicio, dependencias y comportamiento esperado.
OBSERVABILITY
Observar
Activar señales necesarias para saber cómo se comporta producción.
01.2.6ACCESS MODEL
Diseñar también significadecidir quién puede cambiar qué.
Los accesos administrativos forman parte de la arquitectura operativa.
Buscamos separar responsabilidades, evitar credenciales compartidas cuando sea razonable y limitar privilegios a lo necesario.
ACCESS MODELROLE SEPARATION
APPLICATIONDEPLOYMENT ACCESS
DEFINEDINFRASTRUCTUREADMIN ACCESS
RESTRICTEDOBSERVABILITYREAD ACCESS
SCOPEDRECOVERYCONTROLLED ACCESS
DEFINED01.2.7 / DOCUMENTATION
La arquitectura debepoder explicarse después.
Un entorno que sólo entiende quien lo construyó genera dependencia innecesaria.
Por eso buscamos documentar componentes, relaciones y decisiones relevantes para facilitar operación, mantenimiento y transición.
ARCHITECTURE RECORDREFERENCE DOCUMENT
01.2.8CUÁNDO TIENE SENTIDO
Antes de que infraestructurase convierta en deuda operativa.
Nuevas aplicaciones
Preparar arquitectura y entorno antes del primer despliegue productivo.
Migraciones
Rediseñar un entorno antes de mover aplicaciones o servicios existentes.
Infraestructura improvisada
Sistemas que crecieron sin una arquitectura claramente definida.
Nuevos responsables
Equipos que reciben un sistema y necesitan recuperar claridad operativa.
Preparación para MWS
Entornos que posteriormente serán administrados por EVOFCS.
01.2.9 / MANAGED OPERATIONS
Después del despliegueempieza la operación.
Si el cliente necesita que EVOFCS continúe operando el entorno después de llevarlo a producción, esa responsabilidad puede trasladarse a MWS.
Así arquitectura, despliegue, monitoreo, mantenimiento y recuperación pueden formar parte de un mismo modelo operativo.
CONOCER MWS↗SYSTEM LIFECYCLEBUILD → OPERATE
↓
↓
↓
01.2.10PRINCIPIOS
Arquitectura paraser operada.
Simplicidad
Evitamos componentes que no aportan una capacidad necesaria al sistema.
Separación
Delimitamos funciones, accesos y responsabilidades cuando tiene sentido.
Observabilidad
Un sistema productivo debe ofrecer señales suficientes para entender su estado.
Recuperabilidad
Diseñamos considerando cómo responder cuando algo deja de funcionar.
Documentación
Las decisiones importantes deben poder entenderse después del despliegue.
EVOFCS / ARCHITECTURE & DEPLOYMENTDESIGN BEFORE PRODUCTION
Diseñe un entornoque pueda seguir operando después del lanzamiento.
Podemos revisar su aplicación, requisitos y operación esperada para definir una arquitectura y un proceso de despliegue adecuados.
HABLAR CON EVOFCS↗