DEV Community

Cover image for C4 Model en la Nube: Implementación Práctica con AWS y Terraform
Antonio Jesús Castillo Cotán
Antonio Jesús Castillo Cotán

Posted on

1

C4 Model en la Nube: Implementación Práctica con AWS y Terraform

1. Introducción: Extensión del C4 Model hacia la Nube

En el artículo anterior exploramos cómo el C4 Model facilita la documentación y comprensión de arquitecturas de software a través de cuatro niveles de abstracción: Contexto, Contenedor, Componente y Código. Ahora daremos un paso más, llevándolo a un entorno de despliegue real en la nube, por ejemplo a AWS.

La transición hacia la nube presenta retos adicionales: los arquitectos deben gestionar componentes distribuidos, optimizar costos y asegurar la escalabilidad. Este artículo detallaremos cómo aplicar el C4 Model a arquitecturas en la nube, utilizando AWS, Terraform y herramientas de CI/CD, enfocándonos en la parte práctica para que puedas implementar y documentar tus soluciones de manera efectiva.


2. Traducción del Modelo C4 a AWS

En esta sección desglosamos cómo los componentes de AWS encajan en cada capa del C4 Model. Detallamos su propósito y explicamos en qué nivel del modelo deben documentarse cada una.


Nivel 1: Contexto

El nivel de Contexto en AWS representa la integración del sistema con su entorno global, incluyendo usuarios externos, otros sistemas y servicios. Aquí documentamos los elementos principales que definen la conectividad y los puntos de relación con nuestro sistema.

Componentes de AWS relevantes:

  1. VPC (Virtual Private Cloud): Define la red virtual que encapsula la infraestructura, asegurando aislamiento y conectividad interna.
  2. CloudFront: Distribuye contenido estático con baja latencia para usuarios globales.
  3. API Gateway: Actúa como el punto de entrada principal para solicitudes HTTP hacia el backend.
  4. Route 53: Gestiona el dominio y el enrutamiento DNS hacia los servicios de frontend y backend.
  5. WAF (Web Application Firewall): Protege las aplicaciones web de ataques comunes como inyección SQL y cross-site scripting.

Ejemplo aplicado en HealthChain:

  • Usuarios acceden a la aplicación a través de un dominio gestionado por Route 53.
  • El contenido estático (frontend) se distribuye por CloudFront, configurado con reglas de seguridad mediante WAF.
  • Las solicitudes hacia los microservicios en EKS pasan por API Gateway.

Consejo: Documenta las conexiones entre sistemas externos y tu arquitectura en este nivel. Por ejemplo, incluye anotaciones sobre las configuraciones de Route 53 y las políticas de seguridad asociadas a WAF.


Nivel 2: Contenedor

El nivel de Contenedor desglosa los servicios principales que componen el sistema. En AWS, estos servicios suelen estar organizados como aplicaciones, bases de datos y sistemas de almacenamiento.

Componentes de AWS relevantes:

  1. EKS (Elastic Kubernetes Service): Gestiona microservicios dentro de contenedores Docker.
  2. Lambda: Ejecuta funciones serverless para tareas específicas, como validación de datos o generación de reportes.
  3. S3: Almacena contenido estático como archivos, imágenes y documentos.
  4. RDS (Relational Database Service): Gestiona bases de datos relacionales para almacenar datos transaccionales.
  5. Secrets Manager: Almacena credenciales y secretos de forma segura.
  6. ElastiCache: Proporciona un almacenamiento en caché rápido, útil para acelerar consultas repetitivas.
  7. SNS (Simple Notification Service): Envía notificaciones a los usuarios o integra servicios mediante colas de mensajes.
  8. IAM (Identity and Access Management): Gestiona permisos y políticas de acceso a recursos de AWS.

Networking en este nivel:

  • Subnets públicas y privadas:
    • Públicas: Para servicios expuestos, como API Gateway o ALB.
    • Privadas: Para servicios internos, como RDS o EKS.
  • NAT Gateway: Permite a servicios privados acceder a internet sin exponerse directamente.

Ejemplo aplicado en HealthChain:

  • Los microservicios principales, como el de gestión de reservas, corren en un clúster de EKS dentro de subnets privadas.
  • El frontend se almacena en S3 y se distribuye a través de CloudFront.
  • Las credenciales de RDS y API Gateway se gestionan mediante Secrets Manager.
  • IAM asegura que cada componente tenga permisos mínimos necesarios para operar.

Consejo: En este nivel, documenta las interacciones entre contenedores. Por ejemplo, describe cómo EKS se comunica con RDS usando subnets privadas y cómo las credenciales están protegidas con Secrets Manager.


Nivel 3: Componente

En este nivel, desglosamos los elementos internos de cada contenedor para detallar cómo interactúan entre sí.

Componentes de AWS relevantes:

  1. Microservicios en EKS: Cada servicio implementa una parte específica de la lógica de negocio, como autenticación, gestión de reservas y notificaciones.
  2. Función Lambda: Cada función puede realizar tareas específicas, como enviar notificaciones mediante SNS o procesar eventos desde S3.
  3. Bucket S3: Los datos se organizan en carpetas por tipo (p. ej., logs, activos estáticos, backups).
  4. VPC Security Groups: Controlan el tráfico permitido hacia y desde cada recurso dentro de la VPC.
  5. Load Balancer (ALB/NLB): Distribuye el tráfico entre los microservicios o puntos finales de EKS.

Ejemplo aplicado en HealthChain:

  • El servicio de reservas, alojado en EKS, interactúa con:
    • RDS para almacenar datos.
    • SNS para enviar recordatorios.
    • Secrets Manager para acceder a las credenciales de RDS.
  • Los logs de cada componente se almacenan en un bucket S3 dedicado y se visualizan en CloudWatch.

Consejo: Usa nombres descriptivos y etiquetas (tags) para identificar fácilmente los componentes en AWS. Por ejemplo, etiqueta el Security Group del backend como SG-backend-reservas.


Nivel 4: Código

En este nivel, documentamos configuraciones específicas de los recursos. Aquí es donde el código Terraform y las configuraciones YAML para EKS toman protagonismo.

Ejemplo práctico con Terraform:

resource "aws_security_group" "eks_backend" {   
    name           = "eks-backend-sg"
    description  = "Allow traffic to EKS backend services"
    vpc_id          = aws_vpc.main.id
    ingress {
        from_port   = 80
        to_port        = 80
        protocol      = "tcp"
        cidr_blocks = ["10.0.0.0/16"]
    }
    tags = {
        Name = "SG-backend"
    }
}
Enter fullscreen mode Exit fullscreen mode

Consejo: Divide el código Terraform en módulos por nivel del C4 Model (e.g., vpc.tf para contexto, eks.tf para contenedor).


3. Uso de Terraform y CI/CD en el Modelo C4

Terraform para Automatizar la Infraestructura

Terraform es una herramienta ideal para crear y mantener arquitecturas documentadas. Al estructurar tus archivos Terraform según el modelo C4, puedes documentar cada nivel como sigue:

  • Nivel de Contexto: Configuración de VPC, CloudFront y Route 53.
  • Nivel de Contenedor: Clúster EKS, buckets S3, base de datos RDS.
  • Nivel de Componente: Servicios dentro de EKS, funciones Lambda.

Ejemplo práctico: Desplegar un clúster EKS con Terraform

module "eks" {
    source          = "terraform-aws-modules/eks/aws"
    cluster_name    = "healthchain-eks"
     subnets         = ["subnet-abc", "subnet-def"]
     vpc_id          = "vpc-123"
     node_groups = {
         workers = {
             desired_capacity = 2
             max_capacity     = 5
             instance_type    = "t3.medium"
        }
    }
}
Enter fullscreen mode Exit fullscreen mode

CI/CD para Automatizar Despliegues

AWS CodePipeline o Jenkins pueden usarse para automatizar despliegues y mantener consistencia en entornos productivos. Por ejemplo:

  • Integrar Terraform con CodeBuild para validar configuraciones antes del despliegue.
  • Desplegar nuevas versiones de funciones Lambda o servicios EKS automáticamente tras realizar cambios.

4. Buenas Prácticas y Trucos por Capa

  • Contexto: Documenta las dependencias externas de forma explícita en el diagrama, como conexiones entre VPC y sistemas externos.
  • Contenedor: Usa herramientas como Tag Editor de AWS para mantener tus recursos organizados por rol o entorno.
  • Componente: Implementa monitoreo granular con CloudWatch para rastrear errores en funciones Lambda o métricas de EKS.
  • Código: Prueba los cambios de Terraform localmente usando terraform plan antes de aplicarlos en producción.

5. Monitorización y Gestión en AWS

CloudWatch:

  • Configura alarmas para supervisar métricas críticas como latencia en API Gateway o fallos en Lambda.

X-Ray:

  • Rastrea peticiones en arquitecturas distribuidas para identificar cuellos de botella.

CloudTrail:

  • Mantén un registro de cambios en tu infraestructura para auditar accesos o modificaciones.

6. Conclusión

Llevar el C4 Model a la nube no solo facilita la comprensión de las arquitecturas complejas, sino que también alinea la documentación con la infraestructura real. Con Terraform y herramientas de CI/CD, puedes automatizar tanto el despliegue como la documentación, garantizando consistencia y escalabilidad.

AWS Security LIVE!

Tune in for AWS Security LIVE!

Join AWS Security LIVE! for expert insights and actionable tips to protect your organization and keep security teams prepared.

Learn More

Top comments (0)

AWS Security LIVE!

Tune in for AWS Security LIVE!

Join AWS Security LIVE! for expert insights and actionable tips to protect your organization and keep security teams prepared.

Learn More

👋 Kindness is contagious

Discover a treasure trove of wisdom within this insightful piece, highly respected in the nurturing DEV Community enviroment. Developers, whether novice or expert, are encouraged to participate and add to our shared knowledge basin.

A simple "thank you" can illuminate someone's day. Express your appreciation in the comments section!

On DEV, sharing ideas smoothens our journey and strengthens our community ties. Learn something useful? Offering a quick thanks to the author is deeply appreciated.

Okay