DEV Community: Dave Franco

The State of DevOps 2024 según DORA

Dave Franco — Wed, 06 Nov 2024 19:08:34 +0000

El reporte anual State of DevOps 2024 está aquí y hay algunos puntos que me gustaría comentarles pero también leer su opinión.

✅ La IA fue el tema central donde claramente hay una mayoría 81% que asegura que hay una priorización en las organizaciones. A nivel individual un 75.9% respondió que la utiliza sobre todo para generar código, explicarlo, resumir información.

🤨 ¿Qué motiva la adopción? Según el estudio se debe a la presión de la industria tanto a nivel organizacional como individual de los desarrolladores. Para los primeros por un tema sobre todo de marketing y para los segundos como algo que hay que tener conocimientos o te puedes quedar atrás.

Me quedo en el caso individual porque la IA presenta un dilema donde por un lado tienes la presión de aprenderla a usar para no quedarte atrás pero también te genera el temor de que te va a reemplazar. Además, aunque hay una mayoría 87.9% que tiene confianza en el código, muchos de los participantes (no cuentan cuantos) revelaron que no es una confianza absoluta y que el código casi siempre necesita ajustes para que funcione según se espera.

Otro dato que me pareció curioso es que según el estudio hay un impacto beneficioso en la productividad. La hipótesis es que si la IA automatiza las tareas repetitivas y de mantenimiento entonces nos podríamos enfocar en trabajo más valioso, sin embargo lo que sugiere la data es que mientras mayor adopción se reduce este tiempo en trabajo valioso mientras que el trabajo más tedioso se mantiene.

🌎 Hay un impacto ambiental importante, para el 2030 se estima que la demanda de energía se incremente un 160%. Mi pregunta es, ¿cómo y de dónde vamos a generarla? En mi opinión la innovación tendrá una conversación incómoda con los ambientalistas.

📉 Contrario a lo que se esperaba, según el estudio la IA reduce el desempeño (velocidad y estabilidad) en la entrega de software, 7% de reducción por cada 25% de adopción. Adicionalmente, no se nota un beneficio en el producto a medida que se incremente la adopción de la IA. Mi pregunta es, ¿Por qué entonces tanto empeño en su adopción?

Creo que estamos en etapas muy tempranas en la adopción y seguramente veamos números significativamente diferentes en el futuro pero por ahora las promesas de la IA no se están cumpliendo.

El otro tema que me parece super importante a destacar es Platform Engineering en el que el objetivo principal es acelerar el desarrollo de software mejorando la experiencia del desarrollador y habilitando el autoservicio.

✅ Según DORA la implementación de IDP mejora la productividad individual un 8% mientras que a nivel de equipo un 10%, sin embargo el rendimiento en la entrega de software se ve reducido un 8% mientras que la estabilidad cae un 14%. En una organización donde la estabilidad sea un factor crítico, quizás esta práctica no sea la mejor.

Otro aspecto que me parece super importante es que según este estudio, la caída en la estabilidad también viene asociada con mayores niveles de burnout lo que podría impactar en la cultura y retención de talento en las organizaciones

🎯 Finalmente existe una relación positiva en invertir en la experiencia del desarrollador. Esto permite que aumente la productividad y reduce la propensión al burnout.

En conclusión, el marketing es un factor importante en crear la necesidad de adopción de la IA aunque realmente el desempeño del producto no se beneficie, sin embargo hay indicios de aumento en la productividad.

La ingeniería de plataforma también tiene un impacto positivo cuando se invierte en la experiencia del desarrollador y el autoservicio pero puede venir a costa de la velocidad y estabilidad.

Infraestructura como código con AWS ACK

Dave Franco — Sun, 14 Apr 2024 16:57:30 +0000

Estoy trabajando en un proyecto que tiene como objetivo poder desplegar aplicaciones junto con su infraestructura, bajo demanda y sin que los desarrolladores tengan que aprender alguna herramienta de IaC, más allá de Kubernetes, ¿La solución? Amazon Controller for Kubernetes.

ACK te permite manejar infraestructura desde kubernetes utilizando definiciones escritas en yaml, es decir, podrás desplegar tu aplicación junto con la base de datos o cualquier otro recurso que necesite para funcionar. Si estas familiarizado con el proyecto Crossplane es muy parecido, pero digamos que es nativo para AWS.

En este artículo vamos a dar los primeros pasos. Te mostraré como instalarlo, darle permisos y finalmente crear recursos en aws desde kubernetes. ¿Qué vamos a necesitar?

Una cuenta de AWS con acceso (Obvio ¿no?)
aws-cli (Herramienta de aws en la terminal, descárgalo aquí)
Eksctl (Herramienta para crear clusters EKS usando la línea de comando, puedes descargarlo aquí)

Adicionalmente voy a dejarte un repositorio, con código ejemplo de los que acá vamos a mostrar:
https://github.com/davejfranco/youtube-tutorial-src/tree/master/tutoriales/kubernetes/ack

Lo primero será crear nuestro cluster de eks, para este demo lo haremos con eksctl pero tu puedes utilizar cualquier forma, bien sea la consola o cualquier herramienta de IaC que sea compatible con AWS.

Para crear un cluster usando eksctl basta con ejecutar el siguiente comando

eksctl create cluster --name ack-demo

Pero si deseas crear un cluster usando una VPC existente puedes mirar dentro del repositorio donde hay un archivo cluster.yaml ejemplo para que puedas cambiarlo.

---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: ack-demo
  region: us-east-1
  version: '1.29'

vpc:
  id: "vpc-0de6dcebcb1d1e89e"
  clusterEndpoints:
    publicAccess:  true
  subnets:
    public:
      public-1-us-east-1a:
        id: "subnet-060ff58f504f124dd"
      public-2-us-east-1b:
        id: "subnet-0f178e1e24a05cbba"
      public-3-us-east-1c:
        id: "subnet-0b95cc7f6b3fdc0b7"

managedNodeGroups:
  - name: managed-ng-1
    instanceType: t3.small
    privateNetworking: false
    minSize: 1
    maxSize: 2
    desiredCapacity: 1
    volumeSize: 30
    labels: {node-group-type: managed}
    tags:
      nodegroup-role: worker

Una vez terminado de ejecutar el comando anterior, vamos a añadir los permisos necesarios para que desde nuestro cluster podamos crear infraestructura.

ACK es un conjunto de CRDs que se instalan en tu cluster, tendremos un controlador por cada servicio de AWS que queremos manejar, puedes consultar acá la lista soportada hasta el momento. Cada controlador necesita poder acceder al API de AWS para poder manejar los recursos, lo siguiente que haremos es crear un IAM role que tenga las políticas necesarias para ello.

Primero creamos el proveedor OIDC para que desde EKS podamos interactuar con IAM.

eksctl utils associate-iam-oidc-provider --cluster ack-demo --region us-east-1 --approve

Lo siguiente sera crear una trust policy que confie en nuestro cluster

OIDC_PROVIDER=$(aws eks describe-cluster --name $EKS_CLUSTER_NAME --region $AWS_REGION --query "cluster.identity.oidc.issuer" --output text | sed -e "s/^https:\/\///")
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
ACK_SYSTEM_NAMESPACE="ack-system"
ACK_SERVICE_ACCOUNT_NAME="ack-controller"

TRUST_RELATIONSHIP=$(cat <<EOF  
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::${ACCOUNT_ID}:oidc-provider/${OIDC_PROVIDER}"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "${OIDC_PROVIDER}:sub": "system:serviceaccount:${ACK_SYSTEM_NAMESPACE}:${ACK_SERVICE_ACCOUNT_NAME}"
        }
      }
    }
  ]
}
EOF
  )
  echo "${TRUST_RELATIONSHIP}" > trust.json

aws iam create-role --role-name “ack-ec2-controller”--assume-role-policy-document file://trust.json --description “ack iam role”

Una vez creado el IAM role, necesitamos atachar las políticas necesarias para que pueda ejecutar la creación de recursos. Una cosa muy interesante que añadieron los desarrolladores que mantienen el proyecto es una sección donde esta los arns de las políticas recomendadas o inline policies que necesita tener el role por cada controlador, para descargarlo hacemos lo siguiente.

wget -qO- https://raw.githubusercontent.com/aws-controllers-k8s/ec2-controller/main/config/iam/recommended-policy-arn

Este commando descarga el arn que debe tener el IAM role si queremos usar el controlador de ec2

Además, hay algunos controladores que requieren una política custom, por lo que también dejaron un apartado en estos casos como cuando queremos usar S3

wget -qO- https://raw.githubusercontent.com/aws-controllers-k8s/s3-controller/main/config/iam/recommended-inline-policy > inline.json

Luego Podemos atachar la política, de esta forma:

aws iam attach-role-policy \
        --role-name "${ACK_CONTROLLER_IAM_ROLE}" \
        --policy-arn "${POLICY_ARN}"

Y si tenemos inline policies podemos hacer esto:

aws iam put-role-policy \
        --role-name "${ACK_CONTROLLER_IAM_ROLE}" \
        --policy-name "ack-recommended-policy" \
        --policy-document  inline.json

Ya tenemos el cluster y el IAM role, ahora vamos a instalar el controlador via HELM. En este caso haremos la instalación del controlador de EC2.

Lo primero será obtener el token de acceso del ecr publico de aws y con estas credenciales hacer login al registry de HELM

aws ecr-public get-login-password --region us-east-1 | helm registry login --username AWS --password-stdin public.ecr.aws

Por cada controlador vamos a necesitar obtener su versión actual. Para el servicio de EC2, seria:

RELEASE_VERSION=$(curl -sL https://api.github.com/repos/aws-controllers-k8s/ec2-controller/releases/latest | jq -r '.tag_name | ltrimstr("v")')

Procedemos a instalar el controlador.

helm upgrade --install -n ack-system ack-ec2-controller \
    oci://public.ecr.aws/aws-controllers-k8s/ec2-chart \
    --create-namespace \
    --version=$RELEASE_VERSION \
    --set="serviceAccount.annotations.eks\.amazonaws\.com/role-arn=$ACK_CONTROLLER_IAM_ROLE_ARN" \
    --set=aws.region=$AWS_REGION

Si te has fijado le pasamos el arn del IAM Role que hemos creado en el paso anterior. Puedes buscar el arn en la consola, o si quieres buscarlo via aws-cli es así:

aws iam get-role --role-name ack-ec2-controller --query Role.Arn

Si todo ha salido bien, hacemos kubectl get pods -n ack-system y debemos ver el pod corriendo en el namespace. Ya podemos crear nuestros primeros recursos.

Vamos a crear una instancia EC2. Tendremos que indicar, tipo de instancia, imageID y la subnetID donde queremos crearla; estos son campos obligatorios, luego tenemos campos opcionales como los tags.

---
apiVersion: ec2.services.k8s.aws/v1alpha1
kind: Instance
metadata:
  name: ack-demo-ec2
spec:
  instanceType: t2.nano
  imageID: ami-0c101f26f147fa7fd
  subnetID: subnet-060ff58f504f124dd
  tags:
    - key: Name
      value: ack-demo-ec2

Pegamos este codigo en un archivo

Kubectl apply -f infra.yaml Y listo…

Como pueden ver en la imagen de arriba, tenemos la instancia recién creada y el nodo de nuestro cluster eks. La documentación de ACK la encuentras acá para que puedes profundizar en todos los servicios y funcionalidades.

Con ACK vamos a poder no solo desplegar nuestras aplicaciones a kubernetes sino los recursos de infraestructura que dependen de ella. Si quieres ver el paso a paso de este mismo artículo más algunos tips extras, te invito a ver este video en mi canal de youtube donde voy al paso a paso.

youtube.com

Nos vemos pronto cracks!

[Tutorial] RDS Blue / Green Deployment - Migrar Bases de datos ahora es más fácil

Dave Franco — Fri, 15 Dec 2023 15:47:52 +0000

Si hay algo a lo que le temo más que a una película de terror, es a una migración de Base de Datos y la razón es porque muchas cosas pueden salir mal durante este tipo de eventos. Bien sea porque hay que hacer upgrade de la versión, porque hay un cambio de esquema o porque hay que escalar. La base de datos es el corazón de una aplicación y seguramente el de una organización completa.

Si estas usando RDS, un servicio PaaS que nos permite crear y administrar bases de datos con distintos motores como: MySQL, Aurora, PostgreSQL, Oracle y muchos más hay una forma para hacer de estos eventos de migración se hagan de forma más segura, automatizada mientras reducimos drásticamente el riesgo de que salga algo mal. Se llama RDS Blue/Green Deployments.

En el mundo de aplicaciones tenemos los despliegues Blue/Green en donde se hay dos entornos, Blue con la versión actual y Green con una versión actualizada. Una vez que hemos comprobado que todo va bien podemos hacer el cambio y dirigir todo el trafico a nuestro entorno Green. Esto mismo es RDS Blue/Green Deployment pero en base de datos. A continuación, te muestro como utilizarlo.

El escenario es el siguiente, tenemos una Base de datos MySQL versión 5.7 y nos piden hacer un major upgrade a MySQL 8.0. Si estamos hablando de una base de datos de producción es probable que tengamos habilitado MultiAZ sino es así muy mal porque esto puede cubrirte de un incidente a nivel de AZ, podemos hacer el upgrade simplemente modificando el la DB en la pesteña de “Modify”. Sin embargo, no sabemos como puede afectar la migración con datos reales de clientes.

Seleccionamos la base de datos y en la pestaña de “Actions” y le decimos crear Blue/Green Deployment. Esto nos desplegara un menú donde podemos colocar un identificar al deployment e indicar la nueva versión a la que queremos llegar. Una vez llenado los campos hacemos click en Create Blue/Green Deployment.

Colocaremos un identificador a nuestro deployment y si es una migración de version le colocamos la versión a la cual queremos hacer upgrade; en este caso a MySQL 8.0.35

Nos vamos hasta lo último de la página y le decimos crear deployment y listo! Es cuestion de esperar. Lo que sucederá es que RDS creará una replica de la base de datos (Green) que se sincronizará con la base de datos original (Blue), una vez creada automáticamente hará el upgrade de la versión. Durante el proceso mi base de datos (Blue) seguirá trabajando perfectamente y además si tengo replicas de lecturas estas también estarán incluidas dentro del proceso por tanto no solo estoy haciendo el upgrade a mi base de datos principal sino a todas las replicas que tenga.

Una vez que complete el proceso de creación de la base de datos Green y termine el upgrade. Las bases de datos se pondrán en estado disponible al igual que el propio deployment; es momento de hacer el cambio o Switch Over. En este momento podemos hacer pruebas para asegurarnos que nuestra nueva DB funciona perfectamente, Blue/Green deploy no solo sirve para actualizaciones del motor, también podemos usarla si queremos hacer cambios de esquemas, modificaciones en la data entre otros.

Si las pruebas realizadas salen bien entonces seleccionamos el Blue/Green deployment y en el botón de acción seleccionamos "Switch Over" este desplegará una ventana con el estado actual de nuestra DB (Blue) y la nueva DB (Green).

¡Recuerda!

este tipo de eventos criticos deben ser planificados, es recomendable ejecutarlos en horarios donde los usuarios tendrán el menor impacto posible y siempre con un plan B.

Hacemos click en "Switch Over" y durante este tiempo RDS bloquará nuevas conexiones y escrituras a la DB (Blue) y hará el cambio por la DB (Green), podrás observar que la actual db le cambio el identificador y se le agrega "old" al final para mostrar que ahora es la DB vieja mientras que la DB (Green) pasa a tener el mismo nombre y endpoint que tenia la versión Blue; esto también sucederá con todas las read replicas que tengas.

Si quieres ver este mismo tutorial en formato de video, te invito a mi canal

Como migrar bases de datos en aws rds - YouTube

Una de las tareas mas complicadas que podemos tener son las migraciones de Bases de Datos. En este video voy a mostrarte como migrar mucho más fácil si estas...

youtube.com

Chaos Engineering con AWS Fault Injection Simulator

Dave Franco — Thu, 05 Oct 2023 16:35:39 +0000

Un incidente de producción es un evento que puede provocar la interrupción total o degradar un servicio y tiene dos características muy relevantes: la primera es que es impredecible; puedes tratar con ML predecir la probabilidad de que ocurra un incidente pero nunca tendrá la garantía exacta de cuando va ocurrir y segundo, un incidente no es un evento que solo afecte a un componente de tu infraestructura, normalmente es producto de un fallo en cascada que mientras más compleja es la arquitectura, más complicado es de identificar y remediar. Cuando una organización sufre un evento de producción dependiendo de la gravedad puede tener un impacto económico negativo, verse afectada su imagen o peor aún, la total pérdida de la confianza de sus clientes lo que lo podría llevar a una quiebra.

Como ingenieros ¿qué podemos hacer en estos casos? Hay tres cosas que podemos intentar: la primera es, prevenir, es decir diseñar arquitecturas altamente resilientes, en segundo lugar, también debemos prepararnos para que cuando ocurran poder responder lo más rápido posible y por último aprender de cada incidente para repetir lo primero y lo segundo.

Ahora te pido que te hagas esta pregunta,¿Cómo podemos probar que nuestra infraestructura es resiliente a fallos? o ¿Realmente estamos preparados ante un eventual incidente? La respuesta es Chaos Engineering. Es una práctica que busca a través de inyectar fallas deliberadas a nuestro sistema (no simuladas) la información que nos permita detectar debilidades en nuestras soluciones para corregirlas o mitigar su impacto. Si quieres saber más al respecto puedes ir a este link y leer su origen. https://principlesofchaos.org/

¿Cómo lo implementamos? Lo haremos con AWS Fault Injection Simulator. Es una herramienta manejada, es decir, no tienes que aprovisionar ningún servidor sino diseñar los experimentos y dirigirlos a tu infraestructura objetivo. AWS FIS soporta las soluciones de infraestructura más importantes para el hosting de aplicaciones como EC2, ECS, EBS, EKS e incluso VPC para provocar fallos a nivel de red. Puedes leer más aquí https://aws.amazon.com/es/fis/?nc1=h_ls.

Acá es donde se pone super divertido, vamos a crear nuestro primer. Todo el código de infraestructura e instrucciones puedes obtenerlas en este repositorio: http://github.com:davejfranco/fisdemo

El escenario:

Tenemos una infraestructura compuesta por un cluster de ECS que incluye dos nodos EC2 distribuidos en dos zonas de disponibilidad distinta; a esto llamamos nuestro estado estable. Lo siguiente que hacemos es formular una hipótesis basada en una suposición. Si nuestro cluster tiene alta disponibilidad la pérdida de uno de los nodos no debe ocasionar ningún problema.

Probemos si esto es cierto.

La infraestructura está desplegada con CDK así que lo primero es crearla. Vamos al directorio infra.

cd infra && cdk deploy. Si nunca has desplegado nada seguramente vas a necesitar hacer cdk bootstrap

Esto nos dará el endpoint de nuestro LoadBalancer para que podamos probar haciendo request y poder observar su comportamiento. Un requisito de Chaos Engineering es tener buena visibilidad de nuestro servicio para que podamos entender qué ocurre. En el repositorio tengo un script que ejecuta un GET request de forma constante durante unos segundos e imprime el http code.

../fis/testEndpoint.sh http://FisDem-LB8A1-LuvyHxArqt49-260398987.us-east-1.elb.amazonaws.com

Debería ver esto antes de la prueba.

Vamos a la consola de AWS y en el buscador escribimos FIS

En la parte izquierda tenemos experiment templates que es donde creamos nuestro experimento, debajo podemos ver todos los experimentos que hemos ejecutado hasta ahora y una sección llamada “Spotlight” donde nos publican novedades de la herramienta.

Hacemos click en create experiment template

Necesitamos darle una descripción y opcionalmente un nombre. Luego vamos a la sección de Action donde podemos escoger qué servicio vamos a probar, en este caso vamos terminar una instancia así que seleccionamos EC2, pero podrás ver todos los servicios que soporta, seleccionamos luego en el type ´aws:ec2:terminate-instances´. Le damos “Save”.

Luego bajamos a la sección de Target donde definimos nuestra infraestructura objetivo; dependiendo de qué servicios escojas esto cambia pero acá podemos directamente seleccionar un InstanceID o un tag que le permita a FIS encontrar la infraestructura; es mejor usar tags porque esto hace el experimento reusable para futuras ocasiones. Luego de seleccionar el tag, definimos cuántas instancias vamos a terminar, esto puede ser un número fijo, un porcentaje o todos (Si alguna vez pruebas esto en producción, asegurate que tienes la capacidad de regenerar el servicio automáticamente). En mi caso seleccioné uno solo.

Vamos a necesitar darle permisos a FIS para que ejecute la prueba, cuando crear un experimento te sugiere crear un IAM Role, por suerte con el despliegue CDK que hicimos anteriormente está incluido el rol con los permisos necesarios. Finalmente tenemos una condición de stop que permite detener el experimento si una alarma de cloudwatch se activa; esto es útil si estamos probando en un ambiente productivo y queremos detener la prueba para no afectar aún más la disponibilidad del servicio objetivo, además podemos colectar logs de lo ocurrido de forma que nos sirva de reporte.

Hacemos click en ´Create experiment template´. Veremos una pantalla siguiente para ejecutar la prueba que también te pedirá una confirmación.

Mientras se ejecuta el experimento, vamos a correr el script que nos permitirá observar el comportamiento de nuestro servicio. Veremos por un tiempo unos errores 5xx producto de que el 50% de los request están yendo a una instancia que está siendo terminada y no es sino hasta que el ALB detecte que este server no está saludable que lo sacará de circulación. Esta intermitencia puede o no ser significativa dependiendo de la criticidad del servicio que estamos probando; no es lo mismo un demo a un servicio a un app que lleva la posición en tiempo real de un avión en un vuelo comercial.

¿Qué podemos hacer para remediar esto? Podemos reducir el tiempo que toma al ALB detectar la instancia defectuosa, también podemos incrementar la cantidad de nodos a más de 2, esto hará que el porcentaje de request fallidos se reduzca a medida que tenemos más servidores para balancear.

Esto es una nueva hipótesis que tendríamos que probar.

Conclusión

Chaos Engineering es una práctica que nos permite detectar debilidades en nuestra arquitectura mediante la introducción deliberada de fallos. Los pre-requisitos son: una infraestructura estable y tener un sistema de monitoreo que nos permita visualizar el comportamiento de nuestra infraestructura durante la prueba.

Ya que llegaste aquí, también puedes ver este mismo artículo en mi canal de youtube en donde modifico los valores y ejecutó la prueba nuevamente.

Nos leemos pronto cracks!