Cómo los contenedores cambian la escalabilidad
El término "escala de nubes" se utiliza a menudo con ligereza. Se utiliza mucho en marketing para dar a entender una escala REALMENTE GRANDE en contraposición, supongo, a la escala tradicional, no tan grande pero aún así significativa.
Pero, así como hay núcleos de verdad ocultos en los mitos y leyendas, también hay algo de verdad en la forma en que se utiliza el término "escala de nubes".
La verdad es que la nube —y ahora los contenedores— han cambiado la base subyacente de la escalabilidad. Este cambio tiene su raíz en las diferencias fundamentales entre las estrategias de escalamiento vertical y horizontal. Durante la primera década del siglo, operamos casi exclusivamente con la idea de que la escala vertical era la mejor forma de lograr las velocidades y los avances que necesitábamos. Eso significaba más ancho de banda, más capacidad de procesamiento y más memoria. Más puertos. Mayor densidad. Procesamiento más rápido.
Pero con la llegada de la era de la nube, el foco pasó a la escala horizontal. Todavía necesitamos más ancho de banda y capacidad de procesamiento y computación, pero hemos aprendido a distribuir esa necesidad. Todavía necesitamos más hardware, sólo lo ensamblamos a partir de múltiples fuentes en lugar de una entidad única y monolítica.
Es la forma en que se reúnen los recursos lo que cambia el juego. Y no nos equivoquemos: el juego ha cambiado gracias a los contenedores.
La escala hoy depende del plano de control. La velocidad de la API utilizada para lanzar y desmantelar recursos es quizás más importante que la velocidad del servicio de equilibrio de carga en sí. La velocidad de descubrimiento de servicios en un entorno donde los recursos se lanzan y se retiran en cuestión de minutos se vuelve fundamental para entregar solicitudes a una instancia disponible.
Más de la mitad (52%) de los contenedores tienen una vida útil de menos de cinco minutos según el Informe de uso de contenedores de Sysdig 2019 :
- 22% <= 10 segundos
- 17% <= 1 minuto
- 15% <= 5 minutos
Casi la mitad (42%) opera entre 201 y 500 instancias de contenedores. Para mantener la precisión, el plano de control actualiza los componentes con frecuencia. Mucho más frecuentemente que la nube, y ciertamente mucho más frecuentemente que cualquier otra observada con aplicações monolíticas.
La velocidad con la que se actualiza el controlador de ingreso (el mecanismo de equilibrio de carga) para reflejar el conjunto actual de recursos disponibles se convierte entonces en una capacidad crítica. Porque si es incorrecto, una solicitud de consumidor podría dirigirse a un recurso que ya no existe o que aloja un servicio completamente diferente. De cualquier manera, el resultado es una respuesta más larga ya que la solicitud se redirige a un recurso que está disponible. El consumidor debe esperar más tiempo para obtener una respuesta y puede optar por retirarse.
Todo esto apunta a la velocidad del plano de control como un factor de bloqueo en la escalabilidad de las aplicações implementadas en un entorno contenerizado.
En última instancia, esto significa que la escala del plano de control es un problema. El diseño de la API es un problema. Los mecanismos mediante los cuales se autentican y autorizan las solicitudes y actualizaciones de la API son un problema.
Hoy en día, el plano de control ocupa el centro del escenario cuando se trata de escalabilidad. Un plano de control robusto y escalable no es algo lujoso. Hoy en día es una RFC IMPRESCINDIBLE.