Todos conocemos el ejercicio a estas alturas: la infraestructura informática moderna debe ser determinista, desechable, estandarizada y repetible. Todos somos agricultores ahora, y las operaciones de nuestros servidores deben tratarse como ganado, listas para el sacrificio en un abrir y cerrar de ojos.
Sin embargo, debemos tener en cuenta que el impulsor del nuevo principio de diseño es principalmente la naturaleza poco confiable de la infraestructura moderna de computación en la nube y los débiles acuerdos de nivel de servicio (SLA) que la acompañan. Demos un paso atrás del mantra de ganado sobre mascota por un momento y veamos si este es realmente siempre el camino a seguir.
Computadora del templo
En el pasado, los ingenieros de campo planificaron y ensayaron cuidadosamente sus postraciones frente al altar de lanzamiento de software, y una vez colocados con tanta suavidad, se retiraron lentamente del nuevo servicio en curso mientras conservaban sus bendiciones.
Todo el proceso solía ser un proceso manual, posiblemente documentado hasta cierto punto en un runbook, pero a menudo requería conocimiento secreto y sabiduría transmitida en susurros de maestro a aprendiz. El conocimiento y la sabiduría se encuentran ahora en soluciones de automatización como Juju, Terraform y otros habilitadores automatizados de Infraestructura como código (IAC), y los procesos de lanzamiento ya no se planifican y ensayan manualmente, sino que consisten en lanzamientos de software y procesos de aprovisionamiento totalmente automatizados.
Como resultado, se ha invertido mucho recientemente para mejorar la vida de los equipos de operaciones y operaciones. La Ingeniería de confiabilidad del sitio (SRE), a veces conocida como Equipo de soporte L2, se ha beneficiado de manera similar de las herramientas mejoradas en torno a la observabilidad, es decir, Detección de anomalías en la red, etc.
Pero a pesar de todas estas inversiones masivas en la transformación de la gestión de sistemas de un mundo de amadas mascotas a un mundo de rebaños de ganado no amados, esta dura realidad permanece: para muchas aplicaciones comerciales, los sistemas duraderos con muy alta disponibilidad son mucho más fáciles de implementar y operar, y tener otros enormemente más baratos El costo total de propiedad y simplemente se adaptan mejor que las nuevas arquitecturas de sistemas heroicamente desechables.
La tecnología web se está generalizando
Si bien una solución de redes sociales basada en la web puede tolerar días de tiempo de inactividad prolongado de algunos componentes de back-end si la región de la nube de la que dependen se cae (y con un uso inteligente del almacenamiento en caché es posible que ni siquiera lo note); Una aplicación crítica para la seguridad, por ejemplo, un sistema de control de tráfico aéreo altamente transaccional o una aplicación de administración de red de energía de alto voltaje, no puede tolerar el tiempo de inactividad; incluso unos pocos minutos de indisponibilidad pueden tener graves consecuencias.
Para estas aplicaciones, construir una infraestructura multinube multirregional altamente resistente que garantice una disponibilidad extremadamente alta, incluso si la infraestructura virtual subyacente se ofrece con un SLA muy bajo, rápidamente se vuelve mucho, mucho más costoso que simplemente construir una infraestructura decente. primero. Es como construir una casa sobre arena o construir una casa sobre rocas, no del todo estúpido, pero no obstante.
Entonces, ¿cómo podemos reconciliar esta situación? Obviamente, la automatización de los runbooks de los equipos de operaciones tiene muchos beneficios. La Respuesta Automatizada de Operaciones de Seguridad (SOAR) es un ejemplo muy específico: la automatización de los procedimientos establecidos para reaccionar ante un incidente de seguridad permite que todo el evento se procese de manera extremadamente rápida. En muchos casos, el tiempo que se tarda en cerrar un incidente de seguridad detectado tiene un impacto directo en la gravedad del negocio.
Ciertamente, los sistemas fallan todo el tiempo, especialmente a escala. Por otro lado, sobre-diseñar una solución, en este caso, diseñar y construir para una infraestructura desechable, cambiante y poco confiable, puede terminar siendo más costoso que simplemente comprar equipos de clase empresarial. A menos que tenga que pasar a Hiperescala, la arquitectura de su solución de infraestructura en la nube puede no ser el enfoque más rentable.
Por supuesto, las mascotas necesitan cuidados, lo que significa que deben comprometerse a largo plazo e invertir en mantenimiento, para garantizar que las implementaciones se mantengan razonablemente actualizadas y se defiendan contra las vulnerabilidades y amenazas críticas (CVE). En realidad, sin embargo, la mayoría de estas soluciones requieren una inversión significativa en mantenimiento de software, independientemente del enfoque de la gestión medioambiental. Aquí hay un matiz más: la mayoría de las implementaciones con estado de larga duración, independientemente de cómo se traten los sistemas individuales que las componen, a menudo pueden verse como una especie de «mascota» que requiere un cuidado y atención considerables.
Y ciertamente hay algunos casos de uso en los que el paradigma del ganado realmente brilla, como iniciar un clúster Apache Spark con 10,000 nodos durante 10 minutos, procesar grandes cantidades de datos y luego salir y caminar. Este enfoque termina costando unos pocos cientos de dólares en comparación con los cientos de miles de dólares que se necesitarían para invertir en la propiedad de este tipo de plataforma.
Sin embargo, no todos los casos de uso empresarial se benefician de la infraestructura en la nube a hiperescala y, si bien todas las empresas se beneficiarán inevitablemente en gran medida de una automatización mejorada, la infraestructura subyacente adecuada puede hacer que el retorno de la inversión en automatización sea mucho menor. Y en ese punto, el mantra sobrio de criar ganado puede comenzar a desaparecer y podemos volver a nuestro amor por nuestras mascotas.
Más información: Beat Disruption: cómo adaptar su estrategia de TI a los mercados cambiantes
