La sorprendente verdad sobre la transformación digital: deseconomía de escala
Este es el cuarto blog de una serie sobre los desafíos que surgen de la transformación digital.
- La sorprendente verdad sobre la transformación digital
- La sorprendente verdad sobre la transformación digital: Caos en las nubes
- La sorprendente verdad sobre la transformación digital: saltarse la seguridad
Deseconomía de escala.
Cuando uno hace crecer un negocio, especialmente a lo largo del tiempo, tiende a acumular equipaje que necesita atención. Es raro que reduzcas el número de aplicações que debes soportar. Generalmente aumenta, y a veces exponencialmente, en el lapso de unos pocos años. En épocas sin incidentes, las aplicações tienden a duplicarse cada cuatro años. Cuando una nueva tecnología se introduce, ese número aumenta.
Cada aplicación requiere más soporte en las operaciones (es decir, red, computación, almacenamiento y seguridad, para los no iniciados). Pero así como sabemos que la escala vertical sólo nos lleva hasta cierto punto (solo se puede aplicar una cantidad determinada de hardware al problema), sabemos que lo mismo es cierto para los recursos humanos. No podemos seguir añadiendo operaciones para igualar el crecimiento de las aplicaciones. Al hacerlo, aumenta la gestión (gastos generales) y ralentiza la comunicación, ya que nos cuesta determinar quién es responsable de qué, y mucho menos tener una conversación real con esa persona.
Esto es lo que nos muestra la Ley de Despliegues Decrecientes. Llega un punto en el que el número de operaciones realmente impide el despliegue y vemos que empiezan a surgir compensaciones. Como Fausto negociando con el diablo, optamos por la velocidad en lugar de la seguridad y por la escala en lugar de la estabilidad. Al final llegamos a un punto de inflexión en el que llegamos al final de nuestra cuerda teórica y los equipos de desarrollo, operaciones y negocio empezaron a buscar soluciones en otros lugares.
En pocas palabras , solo puedes contratar una cierta cantidad de operadores para lidiar con la cantidad cada vez mayor de aplicaciones antes de entrar en conflicto con la Ley de Implementaciones Decrecientes .
Es por esto que la automatización es fundamental para que las operaciones se mantengan al ritmo del aumento de aplicações y la demanda de una implementación más rápida. Porque no importa lo rápido que escribas, el cálculo es más rápido.
Pero tenga en cuenta que la automatización es más que simplemente crear scripts.
Ya hacemos muchos scripts y ciertamente ha sido un factor que nos ha permitido mantenernos al menos en la carrera con las implementaciones. Para que la automatización sea verdaderamente exitosa, no debe ejecutarse por dispositivo o aplicação . Simplemente no debería. Eso no escala. Si estás escribiendo un script por dispositivo o aplicación, no estás haciendo la automatización correctamente.
La automatización debe tener que ver con el proceso (en realidad, es orquestación, pero es un molino de viento al que sigo apuntando y que se niega a caer) y con una ejecución consistente. Esto significa que es necesario adoptar la automatización, no solo cambios de guión. Y eso significa un nuevo enfoque que incorpora principios de DevOps como infraestructura como código.
Infraestructura como código
La infraestructura como código es un símil. Esto significa que la infraestructura real puede ser software o hardware, en la nube o local. La implementación es irrelevante para los propósitos de implementación, porque vamos a utilizar API y artefactos de implementación para lograr el comportamiento de la infraestructura como código. Al disociar la configuración del dispositivo, podemos tratarlo como si fuera una caja negra.
Lo importante son los artefactos de implementación: las plantillas, los scripts y las políticas utilizadas para aprovisionar y configurar el dispositivo para el servicio deseado. Estos se almacenan en un repositorio (ON-PRESS). Estos describen completamente un servicio determinado (ya sea de red, seguridad, almacenamiento o infraestructura de la aplicación) y pueden usarse para recrear el servicio a voluntad. Estos artefactos se pueden usar para automatizar tareas individuales (agregar una regla de firewall, implementar un balanceador de carga, configurar el WAF) y luego combinarse en un proceso orquestado para lograr una implementación continua.
La razón por la que esto es importante para abordar la deseconomía de escala es que la creación de scripts puros sigue siendo una tarea por dispositivo. Tener un guión convierte una tarea de cinco minutos en una tarea de cinco segundos. Pero aún así se invoca manualmente y requiere que haya personas que dirijan el proceso. No aborda la mayor necesidad de automatizar todo el *proceso*, y eso es lo que se necesita para lograr la economía de escala requerida para competir en una economía digital.
Manténgase atento a la última publicación de esta serie, en la que analizaremos en profundidad cómo puede entregar de forma segura la creciente cantidad de aplicaciones implementadas en entornos de contenedores.