Reference (Simple) Architectures con Traefik, Kubernetes y API Kong Gateway

Reference (Simple) Architectures con Traefik, Kubernetes y API Kong Gateway

Hacerlo todo complicado es algo, por desgracia, muy natural. Pero deberíamos tender a hacerlo a lo fácil y así asegurarnos que nuestros proyectos tienen un % mucho más elevado de éxito y no al contrario. Es por ello que quiero plantear éste post para intentar resolver ciertas dudas que me han llegado frente al diseño de nuestras arquitecturas en AWS. La idea no va más allá de construir una “mínima” arquitectura, pensando en dos tipologías de acceso: programático o humano, y con dos tipos de consumidores: usuarios internos (empleados) o usuarios externos (clientes). Se aceptan sugerencias para mejorarlo, sin duda alguna. Veamos:

AWS Reference Architecture

Content Delivery Layer (Route 53, Load Balancer and Cloud Front)

En el diagrama anterior, podemos ver como nuestros consumidores se conectan a un solo punto de entrada, cierto es que será nuestro Route 53 (servicio de DNS de AWS), seguidamente, tendremos la separación por el tipo de consumidor, sea interno (validando a una VPN client services) o externo. Nuestros ELB (Elastic Load Balancer) se encargarán de realizar los enrutamientos hacia las zonas de disponibilidad correspondientes. Está diseñada la arquitectura para que, como mínimo, tengamos una Alta disponibilidad (HD, High availability) basada en dos zonas de despliegue en AWS.

Nuestros contenidos estáticos, por ejemplo imágenes, ficheros u otros tipos o nuestro static website, pueden tener publicación directa mediante Cloud Front y un repositorio de S3 asociado con su contenido. Cloud Front nos permitirá tener una mayor performance ya se con el consumo de ciertos componentes de tamaños considerables, altos volúmenes de visitas o para servicios en streaming, como podría ser el contenido multimédia.

API and Application Layer (Kubernetes, Traefik and API Kong Gateway)

Siguiendo los modelos de separación por capas o, el simple hecho de tener arquitecturas desacopladas, podremos contruir una segunda capa orientada a dar servicio de aplicación, sea programática, por ejemplo el uso de APIs, o bien el humano con un consumo de servicios web desktop.

En nuestra capa de aplicación, desplegaremos un entorno Docker mediante un sistema como Kubernetes, Docker Swarm, etc… cada uno puede elegir el sistema que más le guste. Aquí desplegaremos tantos contenedores como necesidades tengamos, partiendo de base con el siguiente esquema:

  • Docker controlador, que tendrá la misión de ser el Master de los recursos desplegados en cada availability zone.
  • Traefik, será el proxy inverso HTTP y balanceador de carga para implementar y asociar los microservicios publicados.
  • API Kong Gateway, actuará como Load Balancer de nuestras APIs, sea para dar servicio externo (consumidores de APIs) o entre aplicaciones, ya que podríamos tener un API Kong especializado para comunicar microservicios y tener una auténtica arquitectura desacoplada entre fronted y backend. No entraremos en éste detalle, por ahora.
  • Application Docker, serán los docker desplegados con los microservicios de nuestras aplicaciones.

Persistent layer (Data Bases)

La capa de datos, que en el diagrama está dentro de cada availability zone, tendrá su propia arquitectura ya sea mediante componentes IaaS (VMs) o PaaS. Según nuestras necesidades. Pero la idea será tenerla identificada y crear los conectores necesarios para garantizar su correcto uso, por ejemplo, siguiendo el ejemplo anterior de API Kong podremos crear servicios especializados para garantizar el criterio de acceso a los datos (data criteria access), entregabilidad, cancelación, privacidad, etc…

Si se me permite un último párrafo, la idea de éste post era poder crear una arquitecturalo suficientemente robusta y con un ROI acorde. Siempre podemos complicarlo todo pero, seguramente, tardaremos más en poder ofrecer nuestros productos y/o servicios y aquí está la gracia: el poder crear cosas simples para que cuanto antes tengamos nuestro MVP, seguro, al Mercado. ¡No hay tiempo que perder!.

Autor: Joakim Vivas

comments powered by Disqus