El futuro de la infraestructura se añadirá en contenedores

Aunque la mayoría de las startups y empresas tecnológicas trabajan actualmente en la nube, muchas aún no aprovechan todas las ventajas que supone. Si estás en la nube, pero no en Kubernetes, es probable que estés aprovechando soluciones propias mientras creas y mantienes tus propias herramientas personalizadas adicionales. Además, estás sacrificando eficiencia, ejecutando tus propias cargas de trabajo en máquinas virtuales infrautilizadas y posiblemente comprometiéndote con algún proveedor. 

¿Cuántas herramientas utilizas actualmente para gestionar y parchear tus máquinas virtuales? ¿Cómo se pueden actualizar las aplicaciones? ¿Cuánto utilizas tus máquinas virtuales? Puede que lo que tienes ahora mismo no sea tan eficiente. Las cosas dejan de funcionar (cortes, problemas de escalabilidad, etc.) debido a debilidades en la arquitectura de tus máquinas virtuales, los gastos se van de las manos o la infraestructura no está configurada para soportar muchas acciones empresariales necesarias:

• Refactorizar o reestructurar un MVP para convertirlo en una solución escalable
• Llegar a más proveedores de servicios en la nube para cumplir las expectativas normativas y de los clientes
• Ampliar la cobertura geográfica para reducir la latencia y proporcionar mejores experiencias a una base de clientes generalizada
• Mejora de tu posición de seguridad integral
• Mejorar la experiencia del cliente (por ejemplo, en cuanto a disponibilidad)

Las deudas técnicas y antiguas pueden ralentizar el proceso. Por eso, estamos experimentando un gran cambio en Kubernetes. Una arquitectura moderna compuesta por contenedores gestionados te da acceso a patrones de eficacia demostrada para ejecutar una infraestructura fiable y segura. Puedes agilizar tu tiempo de lanzamiento y aumentar tu productividad sin sacrificar la estabilidad ni la seguridad, con la ventaja añadida de que te ayudará a atraer al mejor talento técnico para trabajar en la innovación.

También es importante que no te quedes al margen de la comunidad de Kubernetes y de su ecosistema circundante, cuya innovación estable define los estándares y prácticas recomendadas del sector actuales. En última instancia, y esto es aún más importante de cara a los desafíos de contratación actuales, debes decidir a qué quieres que dediquen tus ingenieros su tiempo: a mantener la infraestructura y crear y mantener herramientas personalizadas, o hacer las tareas más prioritarias para que tu empresa avance. Es posible que tu estrategia actual funcione, pero es probable que tu hoja de ruta incluya algunos elementos que no te interesan, como pagar las deudas técnicas y compensar las carencias de plataformas como:

• Cifrado de extremo a extremo
• Observabilidad (registros, métricas, registro automático)
• Gestión y cumplimiento de políticas
• Alta disponibilidad y conmutación por error automático
• Reducción de costes

Kubernetes es una herramienta de código abierto y que no depende de una única plataforma. Ofrece todas las herramientas habituales desde el primer momento para proteger y agilizar cada fase del ciclo de desarrollo y despliegue. Es la suma de todas las secuencias de comandos de Bash y prácticas recomendadas que la mayoría de los administradores de sistemas acaban juntando, y que se presenta como un sistema detrás de un conjunto declarativo de APIs. Todo está automatizado, los detalles están ocultos y está listo para usarse. Además, Kubernetes puede eliminar la gran mayoría de la infraestructura como código y migrar tu plataforma a una infraestructura como datos. No tienes que escribir ni mantener código: le dices a Kubernetes lo que quieres, no lo que tiene que hacer. Esto supone un gran ahorro de tiempo en lo que respecta a la sobrecarga de gestión. 

Si quieres ejecutar cargas de trabajo tradicionales, puedes hacerlo en una plataforma moderna con Kubernetes separando las aplicaciones de las máquinas virtuales y colocándolas en contenedores. Contar con imágenes de contenedor para empaquetar el software hará que sea más fácil actualizar las máquinas virtuales. Ahora puedes desvincular la gestión del ciclo de vida de la máquina virtual y la del ciclo de vida de la aplicación, lo que simplifica las máquinas virtuales al eliminar aspectos como Ruby, Python y Java. Si lo trasladas adonde pertenece, junto a la aplicación del desarrollador, podrás controlarlo todo desde un mismo lugar y mantener la sencillez de tus máquinas.

Las plataformas de computación gestionadas convierten los servicios en la nube en plataformas como servicio, lo que te ofrece la potencia y la flexibilidad de los contenedores, además de la comodidad de trabajar sin servidor. Como no hay servidor, no hay que configurar el clúster y no necesita mantenimiento, disfrutas de grandes ventajas sin perder el control.

En el caso de las cargas de trabajo que no requieren mucho control sobre la configuración del clúster, puedes dejar que los servicios aprovisionen y gestionen la infraestructura subyacente, incluidos los nodos y grupos de nodos, pagando únicamente por la carga de trabajo, no el clúster. De esta forma, puedes eliminar la administración de los clústeres a la vez que optimizas la seguridad y ahorras una cantidad de dinero que puede resultar considerable.

En el caso de las aplicaciones nativas de la nube, esto funciona de forma similar, con menos trabajo, ya que se elimina la infraestructura subyacente y actúa como host de extremo a extremo de las aplicaciones, los datos e incluso los análisis. Al tener una plataforma sin servidor, podrás empezar a ejecutar contenedores en un entorno totalmente gestionado con una mínima complejidad sin sacrificar la seguridad, el rendimiento, la escalabilidad ni las prácticas recomendadas integradas.

Veamos qué implicaciones puede tener para tu negocio y cómo puedes mantener a tu organización un paso por delante.

Algunas empresas consideran que es necesario trabajar en varias nubes. La gravedad de los datos es real y, si dispones de una base de clientes internacional, te verás sirviendo a los clientes que quieren minimizar la latencia y las tarifas de red al mantener sus operaciones de computación cerca de donde se encuentran los datos.

En estos casos, la multinube puede expandir el mercado al que te puedes dirigir, aunque terminarás admitiendo servicios y datos gestionados de otros proveedores igualmente. Otras empresas valoran la multinube como estrategia de mitigación de riesgos. En ambos casos, la clave es adoptar correctamente los entornos multinube, y las soluciones estándar del sector pueden ayudarte.

En primer lugar, comprueba que puedes aprovechar tantos flujos de trabajo como puedas. Cuando hablamos de flujos de trabajo, nos referimos a habilitar la automatización de tareas para crear la arquitectura del flujo de datos entre la base de datos y la computación. Es aquí donde entra en juego el software libre. Si seleccionas una base de datos que no está abierta, tendrás problemas para implementar la arquitectura y la automatización del flujo de datos. Te recomendamos que utilices soluciones como el protocolo Postgres (por ejemplo, Cloud Spanner) o una base de datos gestionada de Postgres (por ejemplo,Cloud SQL) en cualquier proveedor de servicios en la nube. 

En segundo lugar, desde el punto de vista de la computación, Kubernetes ahorra mucho tiempo en despliegues y automatización. Por eso, cuando elijas un conjunto de tecnologías, asegúrate de que funcionen fuera de los límites establecidos por tu proveedor. Los límites pueden ser diferentes regiones o zonas, diferentes proyectos o cuentas, e incluso on‐premise o en la nube. Por el bien de tus ingenieros, no pierdas el tiempo creando y manteniendo infraestructuras independientes para cada proveedor de servicios en la nube (por ejemplo, una en AWS, otra en Google y otra en Azure). Si creas una infraestructura y la despliegas en varias nubes, cuando necesites hacer actualizaciones, podrás hacerlas de forma centralizada y coherente. Las pilas de computación, como Kubernetes, suponen una gran ventaja para los clientes que adoptan la multinube y la utilizan de una forma eficiente y sin necesidad de reinventar la rueda cada vez que quieren incorporar un nuevo proveedor en la nube.

Tercero: gestión de riesgos. Tener la capacidad de ejecutar tu pila en otro entorno ayudará a mitigar el riesgo de que tu proveedor de servicios en la nube vaya a pique o empiece a competir con tu empresa. Para cumplir las normativas, las organizaciones deberán elegir a los proveedores para asegurar la continuidad de su negocio. Por ejemplo, si pierdes operaciones en una región, no experimentarás ningún periodo de inactividad con un proveedor de repuesto.

Las migraciones multinube que suelen funcionar son las que aprovechan los estándares abiertos. Por ejemplo, Kubernetes ofrece una API compatible con cualquier proveedor, tanto para ejecutar aplicaciones como para configurarlas y desplegarlas, así como para integrar elementos como políticas de seguridad, redes, etc. Piensa en Kubernetes como un sistema operativo multinube; normalmente, cuando se convierte en tu capa de abstracción, puedes obviar las diferencias entre la mayoría de los proveedores en la nube más importantes.

A la hora de decidirte por Kubernetes, tienes varias opciones. Puedes tomar las riendas, ya que Kubernetes es un proyecto de código abierto, por lo que puedes descargarlo y dedicar años a integrarlo en tu proveedor de servicios en la nube o en tu entorno preferido.

No obstante, si crees que no es la mejor forma de usar tu tiempo, puedes usar una solución gestionada de Kubernetes. Si utilizas AWS, esa solución sería EKS. Si estás en Azure, tienes AKS. Y, si utilizas Google Cloud, sería Google Kubernetes Engine (GKE). Todas esas opciones te ofrecen la misma API de Kubernetes para que, cuando tu equipo cree sus herramientas y flujos de trabajo, puedas reutilizarlas en soluciones de varios proveedores.

No obstante, no todas las ofertas de servicios gestionados son iguales. Kubernetes está al mismo nivel de la infraestructura en la que se ejecuta, mientras que GKE elimina las diferencias como un servicio de orquestación de Kubernetes totalmente gestionado y orquestado. Además, cuenta con una IaaS totalmente integrada, desde el aprovisionamiento de VM Tau, con una relación rendimiento/precio un 42 % superior con respecto a soluciones similares de uso general,¹ autoescalado en varias zonas y licencias, hasta la creación y gestión de GPUs, TPUs para el aprendizaje automático, volúmenes de almacenamiento y credenciales de seguridad bajo demanda. Basta con colocar tu aplicación en un contenedor y seleccionar un sistema en función de tus necesidades.

¿Qué pasa si has elegido AWS como tu proveedor de servicios en la nube para máquinas virtuales? ¿Hay que seguir con EKS? En general, Kubernetes ofrece lo mismo con independencia del proveedor de servicios en la nube que utilices; es decir, tendrás la API de Kubernetes. Sin embargo, tras esa API hay un clúster, nodos de trabajador, políticas de seguridad, etc., y ahí es donde destaca GKE.

Por ejemplo, si todavía necesitas esos otros clústeres, puedes conectarlos a GKE Connect, que te proporcionará un único lugar para gestionar, ver y solucionar problemas, así como depurarlos, al tiempo que gestionas de forma centralizada otros elementos, como las credenciales. GKE se considera una de las mejores soluciones de Kubernetes gracias a su capacidad de gestión integral, además de su plano de control y alta disponibilidad en varias regiones o zonas. GKE también puede aprovechar los balanceadores de carga internacionales con la entrada multi-clúster gestionada de forma centralizada en varios clústeres y regiones.

¿Y si quieres la API de Kubernetes, pero no la responsabilidad de aprovisionar, escalar y actualizar los clústeres? Para la mayoría de las cargas de trabajo, GKE Autopilot abstrae la infraestructura subyacente del clúster, incluidos los nodos y grupos de nodos, de modo que solo pagas por la carga de trabajo. El objetivo de GKE Autopilot es proporcionar la API estándar de Kubernetes con todos los valores de seguridad predeterminados para que puedas centrarte en tus cargas de trabajo, no en los clústeres.

__________________________

¹ Los resultados se basan en una estimación de la ejecución de SPECrate®2017_int_base en las máquinas virtuales de producción de otros dos proveedores de servicios en la nube punteros, así como en VM Tau de preproducción de Google Cloud que usan compiladores recomendados de proveedores. SPECrate es una marca de Standard Performance Evaluation Corporation. Para obtener más información, consulta la página www.spec.org.

Kubernetes ha ayudado a las organizaciones a pasar de máquinas virtuales a un nuevo conjunto de abstracciones que te permiten automatizar operaciones y centrarte en tus aplicaciones. Sin embargo, para cargas de trabajo más específicas (por ejemplo, aplicaciones web y móviles, backends de APIs REST, tratamiento de datos, automatización de flujos de trabajo, etc.), puedes simplificar aún más las tareas y optimizar el despliegue aprovechando el modelo sin servidor.

Es posible que uses AWS Lambda, una popular plataforma sin servidor que permite escribir funciones como servicio y vincularlas a todo tipo de eventos. No obstante, puesto que te conectas a una base de datos y gestionas las cuestiones de seguridad, estas funciones tienden volverse más complejas, algunas de ellas son más grandes que las aplicaciones comunes. Entonces, ¿qué ocurre cuando una aplicación se vuelve más compleja de lo que se esperaría de una función como servicio o de una aplicación que quieres ejecutar sin servidor?

A diferencia de las plataformas sin servidor tradicionales que requieren reescribir tus aplicaciones, Cloud Run ofrece una estrategia que te permite reutilizar tus inversiones en aplicaciones en contenedores. Aunque GKE es un servicio gestionado, sigues teniendo que tomar algunas decisiones clave: las zonas en las que se ejecuta, dónde se almacenan los registros, cómo se gestiona el tráfico entre las distintas versiones de las aplicaciones, los nombres de dominio registrados y la gestión de certificados SSL.

Cloud Run elimina todas esas decisiones para que puedas ejecutar cargas de trabajo más tradicionales y evitar los arranques en frío al inhabilitar el escalado a cero. Si tus aplicaciones tienen que ejecutarse constantemente, podrás hacerlo en Cloud Run, que también es compatible con otros requisitos tradicionales, como NFS, WebSockets y la integración con VPC. No obstante, al igual que la mayoría de las plataformas sin servidor tradicionales, Cloud Run ofrece patrones dogmáticos y ofrece funciones integradas como la gestión del tráfico y el autoescalado.

Imagina que no utilizas contenedores y te preguntas por dónde empezar. En este artículo se describe una estrategia pragmática para adoptar la creación en contenedores.

La primera razón de adoptar los contenedores es solucionar el problema de embalaje. Actualmente, se trabaja mucho en la producción de artefactos reproducibles y para comprender lo que contiene nuestro software (lo que se conoce en el sector como la "cadena de suministro de software segura"). Creemos que una forma ideal de hacerlo es usar imágenes de contenedor que incluyan el código y los tiempos de ejecución de tus aplicaciones y sus dependencias. Una de las ventajas de los contenedores es que pueden desplegarse en máquinas virtuales, lo que reduce la complejidad del despliegue y el mantenimiento del software en todos tus equipos.

El segundo motivo para adoptar contenedores es la orquestación. La gestión de máquinas virtuales conlleva una gran cantidad de gastos de gestión y mantenimiento. Si tu empresa es como la mayoría, tu equipo ejecuta docenas o cientos de pasos para gestionar la infraestructura y, aunque estos sean automatizados, las herramientas de automatización también requerirán un mantenimiento continuo. Y eso es suponiendo que utilizas herramientas de automatización estándar del sector, como Terraform, Puppet, Chef o Ansible. La sobrecarga de mantenimiento es aún peor cuando se trata de herramientas propias o personalizadas.

El tercer motivo para adoptar contenedores es la eficacia. Además de la carga de mantenimiento, la mayoría de las organizaciones solo llegan a utilizar entre un 5 y un 10 % de uso de CPU, por no mencionar la memoria ni el almacenamiento. Es decir, se malgastan muchos recursos. Muchos equipos están creando más herramientas personalizadas para cerrar esta brecha implementando aspectos como el autoescalado y el empaquetado de contenedores, lo que reduce el tiempo de funcionamiento. Esto conlleva un sobregasto y una factura relativa la nube sorprendentemente alta.

Muy pocas organizaciones pueden crear su propia plataforma de orquestación, por lo que usar una plataforma de código abierto como Kubernetes, Mesos o Nomad es una opción habitual. No obstante, si quieres una plataforma que te ayude a disfrutar de ventajas como un mantenimiento reducido, prácticas recomendadas estándar del sector y una integración profunda con el resto de tu proveedor de servicios en la nube, quizá debas decantarte por un servicio gestionado (como GKE) para maximizar el valor potencial de tus contenedores.

Llegados a este punto, puede que te preguntes: ¿la migración a contenedores realmente supone un periodo de inactividad sin valor? Lo último que quieres hacer es pulsar el botón de pausa en el desarrollo futuro, ¿verdad?

Para responder a esta pregunta, veamos cómo puedes aprovecharla para aprovechar la experiencia en la nube hasta la fecha.

Migrar las aplicaciones de las máquinas virtuales a los contenedores puede parecer una labor abrumadora, sobre todo si se trata de transferir toda tu computación a un nuevo proveedor de servicios en la nube. La realidad es que no tienes que ir al por mayor; puedes hacerlo de una en una, empezando por las máquinas virtuales, y moviendo una o dos aplicaciones a Kubernetes, donde pueden vivir juntas en la misma red y hablar con las máquinas virtuales No tienes por qué hacer la transición de golpe: puedes migrar lentamente de una plataforma a otra.

Mantener las máquinas virtuales puede ser útil para algunas aplicaciones, como bases de datos grandes y pesadas que no se benefician mucho de Kubernetes. No pasa nada: puedes combinar distintas soluciones. Sin embargo, hemos observado que la mayoría de los clientes sacan mucho partido de migrar sus aplicaciones y proyectos de código abierto a Kubernetes. Da prioridad a las aplicaciones que generarán la mayor rentabilidad al cambiar a GKE: no tienes por qué migrar todo a la vez.

Kubernetes se sigue ejecutando en las mismas máquinas virtuales de Linux que probablemente estés utilizando en la actualidad. En realidad, lo que obtienes es un flujo de trabajo simplificado y coherente que incluye muchos elementos que debes incluir en la hoja de ruta de tu infraestructura, en lugar de una colección de secuencias de comandos y automatización locales. Incorporar nuevos miembros al equipo también es mucho más fácil cuando usas una herramienta estándar del sector, como Kubernetes, en lugar de enseñarles todos los procesos particulares de tu empresa.

En estos momentos, tienes una opción para adoptar contenedores lentamente, pero de forma pragmática, lo que permite ahorrar tiempo a tu equipo en términos de sobrecarga administrativa, así como dinero a la empresa debido a los costes de computación.

Hemos hablado mucho sobre los contenedores y las migraciones a la nube, tanto si utilizas Kubernetes y buscas una solución mejor o si buscas una estrategia diferente que se ajuste a tus aplicaciones y hoja de ruta.

Sea cual sea el proceso de desarrollo de aplicaciones, la opción de contenedores gestionados reduce los costes de infraestructura, a la vez que permite que tu equipo pueda centrarse todo lo posible en crear productos de calidad. El futuro de la infraestructura es la creación en contenedores. Por eso, es el momento de asegurarse de que tanto los ingenieros como la empresa están preparados para dar lo mejor de sí. 

Kubernetes to Cloud Native: respalda tu desarrollo en GKE

Contenedores en la nube: una forma mejor de desarrollar y desplegar aplicaciones

El pasado, presente y futuro de Kubernetes con Eric Brewer

Re-architecting to cloud native: an evolutionary approach to increasing developer productivity at scale