Dijo Darwin, cuando teorizó sobre el origen y la evolución de las especies, que los cambios que vemos en la naturaleza siguen un proceso que denominó “selección natural”: la conservación de las diferencias y variaciones individualmente favorables y la destrucción de las que son perjudiciales. Así, según el reconocido naturalista inglés, la supervivencia, el éxito, está reservado a, únicamente, los más adecuados.
Como cualquier otra disciplina humana, las ciencias informáticas también viven su particular proceso de evolución. Como en la naturaleza misma, esta evolución a veces sucede de manera gradual (ejemplos famosos como la Ley de Moore así lo demuestran), mientras que otras veces vive un proceso similar a la saltación biológica: un repentino y gran cambio de una generación a otra. Precisamente, en el ámbito que interrelaciona al desarrollo de aplicaciones y la infraestructura tecnológica estamos viviendo un ejemplo de salto evolutivo.
Todo parecía ir evolucionando de manera gradual durante décadas. En esta particular simbiosis, el código de las aplicaciones era la punta del iceberg, mientras que por debajo tenía que existir una infraestructura capaz de soportar las exigencias del código. Esta interdependencia generaba grandes frenos a la velocidad de evolución. Mientras que el código depende en gran medida de la capacidad de abstracción de una mente humana, la infraestructura necesaria para el desarrollo cambia despacio.
Las aplicaciones cada vez requieren más, los usuarios cada vez necesitan más, pero la infraestructura avanza lentamente, y cuando lo hace genera problemas. Principalmente hay dos posibles estrategias en el crecimiento de infraestructura: crecimiento vertical (mejorar los recursos) o crecimiento horizontal (multiplicar los recursos). Y ambos tipos de crecimiento exigen trabajo, tiempo, dinero, tanto en hardware como en rediseñar las aplicaciones para aprovechar el nuevo modelo de arquitectura e infraestructura.
Por parte de arquitectura, la evolución de este entramado, que ha sido y es la solución preferida a día de hoy, es la virtualización del hardware. Con esta estrategia se consigue independizar los desarrollos de las infraestructuras. Y aunque este es el enfoque predominante a día de hoy en diversos ámbitos del desarrollo de aplicaciones informáticas, no deja de estar exento de problemáticas.
La mutación de los desarrolladores: Containers y Docker
Llegados a este punto es cuando pasamos de una evolución gradual a ese salto imprevisto pero no por ello infrecuente en la evolución. Desde desarrollo se le ha dado la vuelta a ese iceberg del que hablábamos. Ahora, gracias a los contenedores, es desde el propio código desde el que se indica todo lo necesario para funcionar, infraestructura incluída. Dentro de estos contenedores podemos alojar todas las dependencias que el desarrollo necesite para funcionar: empezando por el propio código, las librerías del sistema, el entorno de ejecución o cualquier tipo de configuración. De este modo, obtenemos:
- Independencia del hardware.
- Desarrollo funcional en cualquier ambiente.
- Seguridad de que el código siempre va a funcionar.
Es, como me gusta llamarlo, la venganza de los desarrolladores.
Algunas ventajas de utilizar contenedores respecto a métodos como la virtualización podrían ser la mayor rapidez para pasar de la idea a la puesta en producción (de un entorno de pruebas a un servidor real en cuestión de minutos); la seguridad de que el código siempre va a funcionar, sea donde sea; la libertad que ofrece a los desarrolladores de centrarse únicamente en su código; el ajuste de costes y consumo de recursos de manera eficiente, permitiendo escalar desde cero; o que, como esto es open source, no eres cautivo de este o aquel fabricante. O, al menos, no tan cautivo.
Como la misma página de Docker indica, esta evolución “hace que el desarrollo sea eficiente y predecible, elimina las tareas de configuración repetitivas y mundanas y se utiliza durante todo el ciclo de vida para un desarrollo de aplicaciones rápido, fácil y portátil”.
Kubernetes: organizando todo esto
Pese a que los docker permiten una determinada organización de los contenedores, en cuanto nuestro desarrollo empieza a ser más complejo, su gestión se vuelve difícil ya que necesitamos una coordinación para hacer el despliegue, la supervisión de servicios, el reemplazo, el escalado automático y, en definitiva, la administración de los distintos servicios que componen nuestra arquitectura distribuida.
Es aquí donde aparece la figura de Kubernetes. Pese a no ser una idea completamente original (de hecho, no fueron ni son el único orquestador), si se ha convertido en la solución preferida por los desarrolladores actuales.
Gracias a Kubernetes, los problemas surgidos en el crecimiento de las aplicaciones desarrolladas en Docker se ven resueltos tal y como podemos ver en este interesante vídeo:
En Konecta ya estamos desarrollando aplicaciones usando Kubernetes. A través de esta nueva visión al trabajar orquestando contenedores, obtenemos grandes ventajas en todo el proceso, desde el despliegue, el desarrollo y la monitorización de lo que está sucediendo en cada momento. Así conseguimos que la escalabilidad, la coordinación y la gestión sea mucho más sencilla. En definitiva, el uso de Kubernetes nos está ayudando a que nuestros desarrollos puedan, desde el mismo inicio, estar preparados para escalar cuando sea necesario.
No obstante, el uso de Kubernetes no está exento de retos. Desde las posibles vulnerabilidades y preocupaciones a nivel seguridad, pasando a las grandes cargas de orquestación. Una complejidad creciente implica una organización muy bien descrita, planificada y ejecutada.
Y mientras nos lanzamos a descubrir las ventajas y las posibilidades de abandonar la virtualización para abrazar los contenedores y la orquestación vía Kubernetes, ya hay quienes están yendo un paso más allá. Siguiente parada en nuestra particular evolución de las especies: las aplicaciones Serverless.
