Categorías
Uncategorized

Infraestructura de grado producción

Construir infraestructura de grado producción es una tarea complicada. Por infraestructura de grado producción, se entiende a los servidores, almacenes de datos, balanceadores de carga, seguridad, herramientas de monitoreo y alertamiento, procesos de integración y despliegue continuo, y todas las demás piezas necesarias para el funcionamiento del negocio. La infraestructura no debe dejar de funcionar al aumentar el tráfico, perder datos en caso de una interrupción o permitir que los datos se vean comprometidos por piratas informáticos, de ser así, el negocio podría quebrar. Eso es lo que se pone en juego al no llevar nuestra infraestructura a un grado producción.

Esto es aproximadamente cuanto tiempo se requiere para llevar nuestro proyecto de infraestructura a un grado producción:

  • Si deseamos implementar un servicio completamente administrado por un tercero, tal como ejecutar MySQL utilizando el servicio de base de datos relacional de AWS (RDS), podemos esperar que nos lleve de una a dos semanas para tener ese servicio listo para producción.
  • Si deseamos ejecutar nuestra propia aplicación distribuida sin estado, como un clúster de aplicaciones Node.js que no almacenan ningún dato localmente (por ejemplo, que almacenen todos sus datos en RDS) ejecutándose sobre un Auto Scaling Group (ASG), tardaremos aproximadamente el doble, alrededor de dos a cuatro semanas para tenerlo listo para producción.
  • Si deseamos ejecutar nuesta propia aplicación distribuida con estado, como un clúster de Amazon ElasticSearch (ES) que se ejecute sobre un Auto Scaling Group (ASG) y almacene datos en discos locales, el tiempo aumentara en un orden de magnitud, es decir alrededor de dos a cuatro meses para tenerlo listo para producción.
  • Si deseamos construir toda nuestra arquitectura, incluidas todas nuestras aplicaciones, almacenes de datos, balanceadores de carga, monitoreo, alertas, seguridad, etc., el tiempo crece en otro orden de magnitud, es decir alrededor de 6 a 36 meses de trabajo, con pequeñas empresas se suele estar cerca de los seis meses y grandes empresas se suele tardar varios años.


Tabla 1. Cuánto tiempo se tarda en construir infraestructura de grado producción de desde cero

Tipo de infraestructuraEjemploTiempo estimado
Servicio gestionadoAmazon RDS1-2 semanas
Sistema Distribuido auto gestionado (sin estado)Un grupo de aplicaciones de Node.js2-4 semanas
Sistema Distribuido auto gestionado (con estado)Amazon ES2-4 meses
Toda la arquitecturaAplicaciones, almacenes de datos, carga de equilibradores, monitorización, etc.6-36 meses

Si no se ha pasado por el proceso de construcción de una infraestructura de grado producción, es posible sorprenderse con estos números. Es normal pensar en cosas como:

  • “¿Cómo es posible que tome tanto tiempo?”
  • “Yo puedo implementar un servidor en la nube en unos minutos. Seguramente no puede tomar meses para hacer el resto.”
  • “Estoy seguro de que esos números se aplican a otras personas, pero soy capaz de hacer esto en unos pocos días.”

Y, sin embargo, cualquiera que haya pasado por una gran migración a la nube o desarrollado una infraestructura desde cero sabe que estos números, en todo caso, son optimistas, en el mejor de los casos, ciertamente hablando. Si no contamos con personas en nuestro equipo con gran experiencia en la construcción de infraestructura de grado producción, o si nuestro equipo está trabajando en docenas de cosas diferentes y no pueden encontrar el tiempo para concentrarte en ello, podría llevarse mucho más tiempo.


Pero, ¿por que lleva tanto tiempo construir una infraestructura de grado producción?

Las estimaciones de tiempo para los proyectos de software son notoriamente inexactas. Tiempo de estimación para proyectos DevOps, doblemente. Ese cambio rápido que tú pensaste que tomaría cinco minutos ocupa todo el día; la mínima nueva función que estimaste en un día de trabajo lleva dos semanas; la aplicación que pensaste que estaría en producción en dos semanas todavía no está del todo lista seis meses después.

Hay tres razones principales para esto.

La primera razón es que DevOps, todavía se encuentra en una edad temprana y la industria recién la está implementando.

Los términos “computación en la nube”, “infraestructura como código” y “DevOps” aparecieron a mediados o finales de la década del 2000 y herramientas como Terraform, Docker, Packer y Kubernetes se lanzaron inicialmente a mediados o finales de la década del 2010. Todas estas herramientas y técnicas son relativamente nuevas y todas ellas están cambiando rápidamente. Muy pocas personas tienen una experiencia profunda en ellas, por lo que no es sorprendente que los proyectos tarden más de lo esperado.

La segunda razón es que DevOps parece ser particularmente susceptible al surgimiento de un sinfín de tareas pequeñas y aparentemente no relacionadas que debes hacer antes de poder hacer la tarea que originalmente querías hacer. Si desarrollas un software, y especialmente si trabajas con DevOps, probablemente hayas visto este tipo de cosas miles de veces.

Vas a desplegar una solución para un pequeño error tipográfico, solo para desencadenar un error en la configuración de tu aplicación. Implementas la solución para la configuración de la aplicación y de repente te encuentras con un problema de certificados TLS. Después de pasar horas en StackOverFlow, tienes el problema de TLS resuelto, intentas la implementación de nuevo, y esta vez falla debido a algún problema con tu sistema de CI/CD (Continuous Integration y Continuous Delivery). Pasas horas investigando ese problema y descubres que es debido a una versión de Linux desactualizada. Lo siguiente que sabes es que estas actualizando el sistema operativo en todo tu cluster, todo para poder implementar una corrección de errores tipográficos “rápida” de un solo carácter.

En parte, esto se debe a que el término “DevOps” cubre un conjunto de temas asombrosamente amplio: todo, desde la construcción hasta la implementación, la seguridad y mucho más. Cada cambio que hacemos es un poco como tratar de sacar un solo cable USB de una caja de cables USB enredados, jalar un solo cable USB tiende a jalar a todos los demás cables USB.

Esto nos lleva a la tercera razón por la que el trabajo de DevOps lleva tanto tiempo. Las dos primeras razones: DevOps se encuentre en una edad temprana y el surgimiento de tareas no planificadas deben clasificarse como complejidad accidental. La complejidad accidental se refiere a los problemas impuestos por las herramientas y procesos particulares que se han elegido, en contraposición a la complejidad esencial, que se refiere a los problemas inherentes a lo que sea que se está trabajando.

Por ejemplo: si está utilizando C++ para escribir algoritmos de trading, tratar con los errores de asignación de memoria es una complejidad accidental: si elegiste un lenguaje de programación diferente con administración automática de memoria, no tendrías esto como un problema en absoluto, mientras que descubrir un algoritmo que pueda vencer al mercado es de complejidad esencial: tendrías que resolver este problema sin importar qué lenguaje de programación elegiste.

El problema de la complejidad esencial es que hay una lista de tareas realmente larga que se deben realizar para preparar la infraestructura para producción y es complejo conocer todos y cada uno de los campos y tecnologías de esta lista, por lo que cuando se estima un proyecto, se olvida de una gran cantidad de detalles críticos que consumen mucho tiempo. 

La lista de validacion de infraestructura de grado de producción

He aquí un experimento divertido: recorre tu empresa y pregunta, “¿cuáles son los requisitos para ir a producción? En la mayoría de las empresas, si tú haces esta pregunta a cinco personas, obtendrías cinco respuestas diferentes. Una persona mencionará la necesidad de métricas y alertas; otro hablará sobre planificación de capacidad y alta disponibilidad; alguien más seguirá una diatriba sobre pruebas automatizadas y revisiones de código; otra persona más hará mención del cifrado, la autenticación y el hardening de los servidores; y si tienes suerte, alguien podría mencionar copias de seguridad de los datos y logging. La mayoría de las empresas no tienen una definición clara de los requisitos para ir a producción, lo que significa que cada pieza de insfraestructura es desplegada de una forma un poco diferente y pueden ser pasadas por alto algunas funcionalidades criticas.

Esta lista cubre la mayoría de los elementos clave que se deben considerar para implementar infraestructura de grado producción.

Tabla 2. Lista de verificación de la infraestructura de grado de producción

TareaDescripciónHerramientas de Ejemplo
InstalarInstalar binarios del software y todas las dependenciasBash, Chef, Ansible, Puppet
ConfigurarConfigurar el software en tiempo de ejecución. Incluye configuración de puertos, certificados TLS, service discover, líderes, followers, replicación, etc.Bash, Chef, Ansible, Puppet
AprovisionarAprovisionar la infraestructura. Incluye
servidores, balanceadores de carga, configuración de red, configuración de firewall, permisos IAM, etc.
Terraform, CloudFormation
DesplegarImplementar los servicios sobre la infraestructura. Implementar actualizaciones sin estar fuera de linea. Implementar blue-green, rolling y canary deployments.Terraform, CloudFormation, Kubernetes, ECS

Alta disponibilidad
Soportar cortes de procesos individuales, servidores, servicios, centros de datos y regiones.Multidatacenter, multiregion, replication, auto scaling, load balancing

Escalabilidad
Escalar hacia arriba y hacia abajo en respuesta a la demand. Escalar horizontalmente (más servidores) y/o verticalmente (servidores más grandes).Auto scaling,
replication, sharding,
caching, divide and
conquer
RendimientoOptimizae la CPU, la memoria, el disco, la red y
uso de GPU. Incluye optimización de consultas,
benchmarking, pruebas de carga y perfilamiento.
Dynatrace, valgrind, VisualVM, ab, Jmeter
RedesConfigurar IP estáticas y dinámicas, puertos,
service discovery, cortafuegos, DNS, accesos SSH y accesos VPN.
VPCs, firewalls, routers, DNS registrars, OpenVPN
SeguridadCifrado en tránsito (TLS) y en disco, autenticación, autorización, administracion de secretos, hardening de servidores.ACM, Let’s Encrypt, KMS, Cognito, Vault, CIS
MétricasMétricas de disponibilidad, métricas comerciales, métricas de aplicaciones, métricas de servidores, eventos, observabilidad, rastreo y alerta.CloudWatch, DataDog, New Relic, Honeycomb
LogsRotacion y centralizacion de registros.CloudWatch Logs, ELK, Sumo Logic, Papertrail
Respaldar
y
restaurar
Copias de seguridad de bases de datos, cachés y otros datos de forma programada. Restauracion de regiónes y cuentas separadas.RDS, ElastiCache, replication
Optimización de costosEleccion de tipos de instancias adecuados, uso spot e instancias reservadas, usa de escalado automático y eliminacion de recursos no utilizados.Auto scaling, spot Instances, reserved Instances
DocumentaciónDocumencion de código, arquitectura y practicas, crear playbooks para responder a incidentesREADMEs, wikis, Slack
PruebasEscribir pruebas automatizadas para código de infraestructura. Ejecucion de pruebas después de cada commit y nightlyTerratest, inspec, serverspec, kitchenterraform

La mayoría de los desarrolladores conocen las primeras tareas: instalar, configurar, aprovisionar y desplegar. Son las que vienen después de estás las que atrapan gente desprevenida. Por ejemplo, ¿Pensaste en la resiliencia de tu servicio y qué sucede si un servidor se cae? ¿O si un load balancer se cae? ¿O todo un centro de datos se apaga? Las tareas de redes también son notoriamente complicadas: configurar la VPC, la VPN, el service discovery y el acceso SSH son tareas esenciales que pueden llevar meses, y, sin embargo, a menudo se quedan completamente fuera de muchos planes de proyecto y tiempo estimados. Tareas de seguridad, como cifrar datos en tránsito mediante TLS, lidiar con la autenticación y descubrir cómo almacenar secretos son también a menudo olvidados hasta el último minuto.