google cloud

Twelve Factor en Google Cloud ( Parte 1)

Hello Guys! Vuelvo con un post interesante sobre la metodologia de desarrollo y despliegue de aplicaciones basado en micro servicios llamada  «twelve factor» o 12 Factores en Español. Si eres un Sysadmin, SRE, DevOps Engineer seguro habrás esuchado de esta tendencia en el desarrollo de aplicaciones o si nunca has esuchado, te vendria bien conocer  de que trata. No tenemos que ser expertos desarrolladores para poder implementarla o tener el mega proyecto para usarla. 

En este post pretendo dar una explicación clara de los conceptos pero agregando valor al indicarles cuales son los serivcios de Google Cloud Platform que pueden ayudarte a aplicar Twelve Factor en tu proyecto. 

 

1. Code Base

Lo Primero que nos dice la metodología es que el código de la aplicación tiene que ser unico y estar  en un sistema de control de versiones , como GIT por ejemplo.  La aplicación puede estar en un solo repositorio raiz pero contener varios que se despliegan del mismo.

Google Cloud proporcia integración con GIT para deployar tu aplicación desde el repositorio principal. Los servicios que te pueden ayudar son 

En cloud buil lo unico que tienes que hacer es crear un «trigger» o activador para conectar tu repositorio de Git. Ahora bien, tambien puedes usar otros Sistemas de control como Bit Bucket. 

2. Dependencias

Todas las aplicaciones requieren dependencias, como las requeridas para aplicaciones de python o nodeJS,etc. La metodología nos dice que tenemos que declarar estas dependecias en el código y aislarlas. 

¿Que necesitamos para aislarlas? Un contenedor es la forma ideal para aislar depencias y declararlas sin que vayan a entrar en conflicto con otros servicios de nuestra aplicación. Podemos tener nuestro docker file donde declaramos las dependencias para el servicio en particular y subirlas a un registry. 

En Google Cloud contamos un servicio que te permite subir esas imagenes de docker con las dependencias aisladas.

Container Registry

Para que tengan una idea clara es como un Docker hub pero privado y con otras funcionalidades de escaneo de seguridad sobre tus imagenes. 

3. Configuraciones

En una arquitectura de microservicios necesitas desacoplar las configuraciones de la app fuera del codigo. Para tal fin usamos variables de entorno que podrian almacenar datos de conexiones  a servicios de backend o credenciales a otros servicios. La metodologia nos dice que los secrest no deben ir en el codigo asi que viene super bien que usemos el siguiente servicio de Google Cloud: 

 

Secret Manager

4. Servicios Backend

Nuestra aplicación deberia tener servicios a los que conectarse a traves de la red. Dichos servicios pudieran ser Bases de datos, Colas de mensajes, Servicios de cache,etc. 

La idea es tener nuestra app corriendo y que sea independiento de los demas servicios que necesita para correr. En Google Cloud podriamos diseñar esto de varias formas. Por ejemplo,. podriamos tener la base de datos en Cloud SQL y que nuestra app se conecte a ella o implemntar un sistema de  cache con memorystore  que es el seviricio administrado de Google Cloud para memcache y redis. 

5. Construya, lance y ejecute

El proceso de despligue del software debe tener 3 estapas: contruir, lanzar y ejecutar. Cada etapa debe resultar en un artefacto con un identificador único usado por la compilaación para crear un  paquete de implementación. Desde el código fuente cada paquete deberá estar enlazado a un especifico release que es el resultado de la configuracion y el build para si permitir que se puedan hacer rolls back o auditorias sobre las etapas del despliegue. 

Todo este escenario de despliegue lo podemos contruir con: 

Como ya dijimos en el primer paso con Cloud build podemos enlazar el código fuente desde nuustro repo en git y con cloud run podemos hacer esa etapa de despliegue en contenedores. Facilmente podriamos tagear cada release para lograr despues hacer rollback si necesitamos corregir algo del nuevo release. 

6. Procesos

Las aplicaciones deben estar corriendo en un proceso o mas pero deben ser stateless. El termino stateless se refiere a sin estado o en mis propias palabras que la data este desacoplada. Tenemos Stateless por ejemplo cuando nuestra app escrita en python està desplolyada en un contenedor y si esta falla o el contenedor no funciona no perdemos información ya que el «estado» de la app no esta en ella, se encuentra desacoplado en un backend service como Cloud SQL u otro contenedor o servicio StateFull. 

Bueno eso fue lo que tenia preparado para hoy. Esta es una primera parte para no hacer tan largo el post.  Adicional, quiero invitarlos a ver la siguiente presentación en Cloud Next 2018 sobre CI/CD en serverless que explica un poco como funcionan algunos de los conceptos que envuelven el diseño de microservicios usando la metodologia «twelve Factor». Aqui les dejo el video 

Si les gustó este post por favor compartirlo. Es la manera mas sencilla y rapida de apoyar un poco el tiempo que dedico a compartir mis conocimientos con el mundo.

Nos vemos en la segunda parte… 

See you in the Cloud

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Jukajo's Blog

Leave a Comment