El futuro de la infraestructura se alojará en contenedores

Si bien en la actualidad la mayoría de las empresas y startups de tecnología ejecutan sus servicios en la nube, muchas todavía no se dan cuenta de los beneficios que obtienen con esto. Si estás en la nube, pero no en Kubernetes, es posible que estés aprovechando soluciones propias mientras compilas y mantienes tus propias herramientas personalizadas complementarias. Tampoco estás sacando provecho de la eficiencia cuando ejecutas tus propias cargas de trabajo en máquinas virtuales (VMs) sin aprovechar todo su potencial y, posiblemente, te estás limitando.

¿Cuántas herramientas utiliza hoy para administrar y aplicar parches a sus VM? ¿Cómo actualiza sus aplicaciones? ¿Cómo es su utilización de VM? Es posible que sus herramientas actuales no sean tan eficientes. Se producen problemas (de escalabilidad o con interrupciones, etc.) provocados por debilidades en su arquitectura de VM, los costos aumentan sin control o su infraestructura no está preparada para soportar muchas de las actividades que quiere realizar en su empresa, como las siguientes:

• Refactorizar o rediseñar la arquitectura de un MVP para crear una solución escalable
• Expandirse hacia proveedores de servicios en la nube adicionales para cumplir con las expectativas regulatorias o de los clientes
• Expandirse geográficamente para reducir la latencia y entregarle mejores experiencias a la base global de clientes
• Mejorar su postura de seguridad de extremo a extremo
• Mejorar la experiencia del cliente (p. ej., la disponibilidad del servicio)

Los elementos heredados y la deuda técnica pueden ser una demora. Es por eso que estamos presenciando este cambio masivo a Kubernetes. Una arquitectura moderna compuesta por contenedores administrados le brinda acceso a patrones comprobados para ejecutar una infraestructura confiable y segura. Puedes acelerar tu tiempo de salida al mercado y aumentar tu productividad, sin sacrificar la estabilidad y seguridad. Además, tienes la ventaja adicional de que puede ayudarte a convocar a los mejores talentos técnicos para trabajar en la innovación.

Por otra parte, es importante que no se quede fuera de la comunidad de Kubernetes y del ecosistema que la rodea, cuya innovación estable define los estándares y las prácticas recomendadas de la industria en la actualidad. En definitiva, y esto es aún más importante si se tienen en cuenta los desafíos actuales a la hora de contratar personal, debes decidir a qué prefieres que dediquen su tiempo los ingenieros: al mantenimiento de la infraestructura y a la creación y el mantenimiento de herramientas personalizadas, o a cumplir con su lista de prioridades para que tu empresa progrese. Es posible que tu método actual funcione, pero, quizás, tu hoja de ruta incluya tareas que preferirías que no incluyera, como saldar la deuda técnica y llenar los vacíos en la plataforma:

• Encriptación de extremo a extremo
• Observabilidad (registros, métricas, registros automáticos)
• Administración y aplicación de políticas
• Alta disponibilidad y respaldo automático
• Reducción de costos

Kubernetes es de código abierto y no depende de ninguna plataforma, además ofrece desde el primer momento todas las herramientas necesarias para proteger y acelerar cada etapa del ciclo de vida desde la creación hasta la implementación. Es la suma de todas las secuencias de comandos de Bash y las prácticas recomendadas que la mayoría de los administradores de sistemas redactan con el paso del tiempo, presentado como un solo sistema detrás de un conjunto declarativo de API. Todo está automatizado, los detalles están ocultos y está listo para usarlo. Kubernetes puede eliminar la gran mayoría de la infraestructura como código mientras cambias tu plataforma por una infraestructura como datos. No tienes que escribir ni mantener código, solo tienes que decirle a Kubernetes lo que deseas, no lo que tiene que hacer. Esto ahorra muchísimo tiempo en lo que respecta a la sobrecarga de la administración.

Si desea ejecutar cargas de trabajo tradicionales, puede hacerlo en una plataforma moderna con Kubernetes si separa las apps de las VM y distribuyéndolas en contenedores. Adoptar imágenes de contenedores para empaquetar su software facilitará las actualizaciones de sus VM. Actualmente, se puede separar la administración del ciclo de vida de la VM y la administración del ciclo de vida de la aplicación, lo que simplifica la VM tras quitar todo, como Ruby, Python y Java. Y si se traslada a donde debe estar, junto a la aplicación del desarrollador, se puede controlar todo en un solo lugar y mantener las máquinas de equipos físicos.

Las plataformas de computación administradas convierten los servicios en la nube en plataformas como servicio, lo que te ofrece el poder y la flexibilidad de los contenedores con la conveniencia de no requerir servidores. No hay servidor, ni configuración de clústeres, ni mantenimiento, lo que significa que puede disfrutar de un enorme beneficio mientras mantiene el control.

Para las cargas de trabajo que no requieren mucho control de la configuración del clúster, puede optar por dejar que sus servicios aprovisionen y administren la infraestructura subyacente del clúster, incluidos los nodos y los grupos de nodos, mientras usted solo paga por la carga de trabajo, no por el clúster. De este modo, se puede eliminar la administración del clúster al mismo tiempo que se optimiza la seguridad y se ahorra una cantidad de dinero potencialmente importante.

Para las aplicaciones más nativas de la nube, la tecnología sin servidores hace lo mismo con menos trabajo, ya que elimina la infraestructura subyacente y sirve como host de extremo a extremo para sus aplicaciones, datos y hasta análisis. Una plataforma sin servidores le permitirá comenzar a ejecutar contenedores en un entorno completamente administrado con una complejidad mínima y la integración de seguridad, rendimiento, escalabilidad y prácticas recomendadas.

Analicemos las posibles implicaciones para su empresa y cómo puede mantener su organización a la vanguardia en términos de eficiencia.

Algunas empresas consideran necesario operar en múltiples nubes. La gravedad de datos es real, y si tiene una base de clientes global, inevitablemente se encontrará prestando servicios a clientes que quieren minimizar la latencia y las tarifas de red manteniendo su sistema informático cerca de donde se encuentran realmente sus datos.

En tales casos, las múltiples nubes pueden ampliar su mercado objetivo. De cualquier manera, acabará prestando asistencia a servicios administrados y a datos de otros proveedores. Otras empresas consideran las múltiples nubes como una estrategia de mitigación de riesgos. En cualquiera de las dos situaciones, la clave es adoptar correctamente las múltiples nubes, para lo cual pueden ayudar las soluciones estándar de la industria.

Primero: Asegúrate de que puedes reutilizar la mayor cantidad posible de tus flujos de trabajo para cumplir con las tareas.. Por flujos de trabajo, nos referimos a habilitar la automatización de tareas para crear la arquitectura de flujo de datos entre la base de datos y el procesamiento. En este punto es importante el código abierto; si selecciona una base de datos que no sea abierta, tendrá dificultades para implementar la arquitectura de flujo de datos y la automatización. Es recomendable que optes por una opción como el protocolo Postgres (p. ej., Cloud Spanner) o una base de datos administrada de Postgres (p. ej., Cloud SQL) en cualquier proveedor de servicios en la nube.

Segundo: En cuanto al procesamiento, Kubernetes ahorra un tiempo considerable en las implementaciones y la automatización, por lo que cuando elijas un conjunto de tecnologías, asegúrate de que funcionen en los límites establecidos por tu proveedor. Los límites pueden ser diferentes regiones o zonas, proyectos o cuentas distintos, o incluso modalidades locales o en la nube. No pierda tiempo construyendo y manteniendo infraestructuras separadas dirigidas a cada proveedor de servicios en la nube (p. ej., una para AWS, otra para Google y otra para Azure), de esta forma, sus ingenieros terminarán agotados tratando de mantenerlas a la par. Si construye solo una infraestructura y la implementa en múltiples nubes, cuando necesite hacer actualizaciones, podrá realizarlas de forma centralizada y coherente. Las pilas de procesamiento como Kubernetes ofrecen una gran ventaja a los clientes que se toman en serio la creación de múltiples nubes de una manera eficiente y que no requiere volver a inventar la rueda cada vez que se desee incorporar un nuevo proveedor de servicios en la nube.

Tercero: Administración de los riesgos. Tener la capacidad de ejecutar su pila en otro entorno ayudará a mitigar el riesgo de que su proveedor de servicios en la nube falle o comience a competir con su empresa. Para cumplir con los reglamentos, las organizaciones elegirán proveedores que garanticen la continuidad de su negocio. Por ejemplo, si fallan las operaciones en una región, no experimentará ningún tiempo de inactividad con un proveedor de respaldo.

Las migraciones a múltiples nubes que suelen funcionar bien son las que aprovechan los estándares abiertos. Por ejemplo, considere a Kubernetes, que ofrece una API independiente del proveedor tanto para ejecutar aplicaciones como para configurarlas y también implementarlas, además de integrar aspectos como las políticas de seguridad, las redes y mucho más. Considere a Kubernetes como un sistema operativo de múltiples nubes; una vez que se convierte en su capa de abstracción, normalmente puede ocultar las diferencias entre la mayoría de los principales proveedores de servicios en la nube.

Cuando decide utilizar Kubernetes, tiene muchas opciones. Sin duda, puede ejecutarlo usted mismo; Kubernetes es un proyecto de código abierto, por lo que es posible descargarlo y pasar años integrándolo en su proveedor de servicios en la nube o en su entorno preferido.

Pero si considera que este método no supone el mejor uso de su tiempo, puede optar por una oferta de Kubernetes administrado. Si está trabajando con AWS, correspondería el servicio de EKS. Si usa Azure, sería AKS. Y si prefieres Google Cloud, contarías con Google Kubernetes Engine (GKE). Todas esas opciones le proporcionarán una API de Kubernetes común, de modo que cuando su equipo desarrolle sus herramientas y flujos de trabajo podrá volver a utilizarlos en varios proveedores.

Pero no todas las ofertas de servicios administrados son iguales. El provecho que puede sacarle a Kubernetes depende de la infraestructura en la que lo ejecuta. GKE llena los vacíos como servicio de organización de Kubernetes maduro y completamente administrado. Ofrece un IaaS totalmente integrado que va desde el aprovisionamiento de VMs Tau, con una relación precio-rendimiento un 42% mejor que la de otras ofertas comparables de uso general,¹ ajuste de escala automático en múltiples zonas y actualizaciones, hasta la creación y administración de GPU, TPU para aprendizaje automático, volúmenes de almacenamiento y credenciales de seguridad a petición. Todo lo que tiene que hacer es ubicar su aplicación en un contenedor y elegir un sistema en función de sus necesidades.

¿Qué pasa si eligió AWS como su proveedor de servicios en la nube para las VM? ¿Debe seguir con EKS? En general, Kubernetes es igual en todos los proveedores de servicios en la nube, lo que significa que terminará usando la API de Kubernetes. Sin embargo, detrás de esa API hay un clúster, nodos trabajadores, políticas de seguridad y todo lo necesario, y es en este punto donde destaca GKE.

Por ejemplo, si todavía necesitas esos otros clústeres, puedes conectarlos a GKE Connect, lo que te permitirá disponer de un único lugar para administrarlos, verlos, solucionar problemas y depurarlos todos, a la vez que administras de forma centralizada asuntos como las credenciales. GKE es el mejor Kubernetes de su clase por su capacidad de administración integral, no solo por su plano de control o su alta disponibilidad en varias regiones o zonas. GKE también puede beneficiarse de los balanceadores de cargas globales mediante el Ingress de varios clústeres administrado centralmente a través de múltiples clústeres y regiones.

¿Qué pasa si desea usar la API de Kubernetes, pero no quiere lidiar con la responsabilidad de aprovisionar, escalar ni actualizar los clústeres? Para la mayoría de las cargas de trabajo, Autopilot de GKE simplifica la infraestructura subyacente del clúster, incluidos los nodos y los grupos de nodos, y solo debes pagar por la carga de trabajo. Autopilot de GKE le ofrece la API estándar de Kubernetes con todos los valores predeterminados de seguridad, para que pueda enfocarse en sus cargas de trabajo y no en el clúster.

__________________________

¹ Los resultados se basan en la ejecución estimada SPECrate®2017_int_base en VMs de producción de otros dos proveedores líderes en la nube y en VMs Tau de Google Cloud en preproducción con compiladores recomendados por el proveedor. SPECrate es una marca de Standard Performance Evaluation Corporation. Más información disponible en www.spec.org.

Kubernetes trasladó las organizaciones de las VM a un nuevo conjunto de abstracciones que le permiten automatizar las operaciones y enfocarse en las aplicaciones. Sin embargo, si se trata de cargas de trabajo más específicas (p. ej., apps web y para dispositivos móviles, backend de APIs de REST, procesamiento de datos, automatización del flujo de trabajo), puedes simplificar aún más y optimizar tu implementación aprovechando el modelo sin servidores.

Puede ser que esté usando AWS Lambda, una popular plataforma sin servidores que le permite escribir funciones como servicio y conectarlas a todo tipo de eventos. Sin embargo, como se termina conectando a una base de datos y manejando asuntos de seguridad, estas funciones tienden a crecer en complejidad, algunas incluso son más grandes que las aplicaciones normales. Entonces, ¿qué sucede cuando se tiene una aplicación que supera la simplicidad de una función como servicio, o una aplicación existente que se quiere ejecutar sin servidores?

A diferencia de una plataforma tradicional sin servidores que requiere que vuelvas a escribir tus aplicaciones, Cloud Run ofrece un enfoque que ayuda a reutilizar tus inversiones existentes en aplicaciones alojadas en contenedores. Aunque GKE es un servicio administrado, aún deberá tomar algunas decisiones clave, como en qué zonas ejecutarlo, dónde se almacenan los registros, cómo administrar el tráfico entre las diferentes versiones de las aplicaciones, los nombres de dominio registrados o la administración de los certificados SSL.

Cloud Run evita todas esas decisiones, ya que permite ejecutar cargas de trabajo más tradicionales y prevenir los inicios en frío inhabilitando por completo la reducción de escala a cero. Si sus aplicaciones deben ejecutarse siempre, Cloud Run también es compatible con eso, junto con otros requisitos tradicionales como NFS, integraciones de VPC y WebSockets. Pero al igual que la mayoría de las plataformas tradicionales sin servidores, Cloud Run está bien definido y ofrece características como la administración de tráfico integrada y el ajuste de escala automático.

Supongamos que no utiliza contenedores en absoluto y se pregunta cómo empezar. Este es el enfoque pragmático para adoptar la creación de contenedores.

La primera razón para adoptar contenedores es resolver el problema del empaquetado. En la actualidad, se está trabajando bastante en la producción de artefactos reproducibles y en la comprensión de lo que hay realmente dentro de nuestro software, o, como lo llama la industria, la “cadena de suministro de software seguro”. Creemos que una forma ideal de hacerlo es aprovechar las imágenes de contenedor que contienen el código y los entornos de ejecución de tus aplicaciones y sus dependencias. Uno de los beneficios de los contenedores es que pueden implementarse en las VM, lo que reduce la complejidad de la implementación y el mantenimiento del software en las máquinas.

El segundo motivo para adoptar contenedores es la organización. La administración de las VM conlleva toneladas de gastos de administración y mantenimiento. Si su empresa es como la mayoría, su equipo realiza decenas o cientos de pasos para administrar la infraestructura, incluso si esos pasos están automatizados, las herramientas de automatización seguirán requiriendo un mantenimiento continuo. Todo ello, en el supuesto de que se utilicen herramientas de automatización estándar de la industria, como Terraform, Puppet, Chef y Ansible. La sobrecarga de mantenimiento es aún peor para las herramientas de fabricación propia o personalizadas.

El tercer motivo para adoptar contenedores es la eficiencia. Además de la carga de mantenimiento, la mayoría de las organizaciones solo alcanzan entre un 5% y un 10% del uso de CPU, sin mencionar la memoria y el almacenamiento, lo que representa una gran pérdida de recursos. Muchos equipos están creando herramientas incluso más personalizadas para cerrar esta brecha implementando procesos como el ajuste de escala automático y la compresión eficaz, lo cual hace que se desperdicie más tiempo operativo. Esto provoca que se gaste más de lo que se debería y que la factura por los servicios en la nube sea sorprendentemente alta.

Muy pocas organizaciones son capaces de construir con éxito su propia plataforma de organización, por lo que aprovechar una plataforma de código abierto como Kubernetes, Mesos o Nomad es una opción habitual. Ahora bien, si desea una plataforma con la que obtenga beneficios, como la reducción del mantenimiento, la aplicación de las prácticas recomendadas estándar de la industria y una sólida integración en el resto de su proveedor de servicios en la nube, le conviene optar por un servicio administrado, como GKE, para maximizar el valor potencial de sus contenedores.

En este punto, es posible que te preguntes lo siguiente: ¿la migración a contenedores supone realmente mucho tiempo de inactividad sin ningún valor? Lo último que desea hacer es detener el desarrollo futuro, ¿verdad?

Para responder a esto, vamos a revisar cómo hacerlo correctamente, de forma que aproveche su experiencia en la nube obtenida hasta la fecha.

Puede parecer difícil migrar las aplicaciones de las VM a los contenedores, sobre todo si implica trasladar las operaciones de procesamiento a un nuevo proveedor de servicios en la nube. Pero la realidad es que no tiene que hacerlo todo de una vez; puede empezar con una aplicación a la vez, comenzando con las VM y moviendo una o dos aplicaciones a Kubernetes, donde pueden coexistir en la misma red y comunicarse con las VM. No tiene que embarcarse en una transición de principio a fin; puede ir moviéndose poco a poco de una plataforma a otra.

Continuar con las VM puede ser útil para algunas apps, como las bases de datos grandes y pesadas que se benefician poco de Kubernetes. Y eso está bien, no hay problema en mezclar y combinar. No obstante, lo que observamos es que la mayoría de los clientes se benefician mucho con el traslado de sus aplicaciones y proyectos de código abierto al entorno de Kubernetes. Priorice las aplicaciones con las que obtendrá un mayor rendimiento cuando las pase a GKE, no tiene que trasladar todo a la vez.

Kubernetes continúa ejecutándose sobre las mismas VM de Linux que probablemente está utilizando hoy en día. Lo que realmente se logra es un flujo de trabajo más racionalizado y coherente, el cual incorpora muchos elementos que deberían incluirse en la hoja de ruta de la infraestructura, en lugar de lo que podría ser una colección de secuencias de comandos y automatizaciones de producción propia. La integración de nuevos miembros al equipo también resulta mucho más fácil cuando se utiliza una herramienta estándar de la industria como Kubernetes, en lugar de tener que enseñarles todos los métodos personalizados que utiliza su empresa.

A partir de aquí, dispone de una ruta para adoptar contenedores de forma pausada, pero pragmática, lo que permite ahorrar tiempo a su equipo en términos de sobrecarga administrativa, a la vez que ahorra dinero a su empresa en costos de procesamiento.

Hablamos bastante sobre los contenedores y las migraciones a la nube, ya sea que estés totalmente enfocado en Kubernetes y busques una mejor oferta, o que necesites un enfoque diferente que se adapte a tus aplicaciones existentes y a tu hoja de ruta.

Cualquiera que sea su ruta de desarrollo de apps, la opción de contenedores administrados minimiza sus costos de infraestructura al mismo tiempo que maximiza la capacidad de su equipo para enfocarse en desarrollar grandes productos. El futuro de la infraestructura es la creación de contenedores. Es el momento de asegurarte de que tus ingenieros y tu empresa están preparados para alcanzar el mayor éxito posible. 

Kubernetes to Cloud Native: Jumpstart your journey developing on GKE

Contenedores en la nube - Una mejor manera de desarrollar e implementar aplicaciones

The past, present, and future of Kubernetes with Eric Brewer

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