6 razones para cambiarse a Kubernetes gestionado

0
4
Custom Text

Traspasar sus clústeres de Kubernetes a un proveedor de servicios gestionados puede parecer como enviar a sus hijos a la universidad -al principio da miedo, pero con el tiempo hay mucho menos trabajo que hacer en la casa.

Las opciones gestionadas de Kubernetes -o Kubernetes como servicio (KaaS, por sus siglas en inglés), de los tres grandes proveedores de nube pública, Amazon Web Services (AWS), Google Cloud y Microsoft Azure han logrado grandes avances en los últimos años, ayudando a los clientes a ejecutar y organizar sus cargas de trabajo en contenedores, sin tener que conocer los embrollos de los archivos de configuración YAML o preocuparse por el ajuste automático de escala, las actualizaciones y la administración de los clústeres.

«Cuando las empresas consideran que algo es estratégico, la inclinación inicial es ejecutarlo ellas mismas. Con el tiempo, a medida que se aclimatan, se dan cuenta que no solo no les da ninguna ventaja competitiva, sino que es más probable que los proveedores puedan ejecutarlo mejor que ellos”, afirma Stephen O’Grady, cofundador de RedMonk, una firma de analistas centrada en el desarrollador. «¿Todas las empresas van por este camino? Todavía no, pero el apetito y el rumbo del viaje parece claro”, agrega.

A continuación, seis razones para considerar un servicio de Kubernetes gestionado.

Menores gastos generales de gestión
Comencemos primero con la razón obvia. «Es menos trabajo, seamos claros”, afirma Sylvain Roy, vicepresidente senior de plataformas tecnológicas e ingeniería de Amadeus, firma de tecnología para viajes. «Es operado por nosotros y eso es lo importante, porque tenemos el desafío de tener todas las personas que necesitamos para ejecutar [Kubernetes]”.

Del mismo modo, un pequeño grupo de ingenieros de la empresa de construcción, Strabag, ha estado ejecutando contenedores desde el 2006. Durante los últimos cuatro años, ha pasado a una configuración de Docker y Kubernetes de código abierto autogestionado. Ahora, el grupo busca automatizar la mayor parte posible de la gestión de los clústeres, ya sea modernizando las aplicaciones existentes y transfiriendo la gestión de los clústeres de Kubernetes subyacentes a Google Cloud, o capacitando a los desarrolladores para ejecutar nuevas aplicaciones en la nube o en una configuración híbrida, utilizando el servicio Anthos específicamente, cuando se requiere alguna transferencia on premises de datos.

«El viaje consiste en entregar las tareas que están en condiciones de ser transferidas”, señala Mario Kleinasser, líder del equipo de servicios en la nube en Strabag.

De manera similar, según Bloomberg, el gigante de los datos financieros, «tiene sentido aprovechar a un proveedor cuando no hay equipos de SRE (ingeniería de confiabilidad del software) o equipos que administran el ciclo de lanzamiento de Kubernetes, para aquellos que se enfocan en ejecutar sus aplicaciones y no quieren administrar Kubernetes”, sostiene Andrey Rybka, jefe de infraestructura informática de Bloomberg.

En la actualidad, Bloomberg todavía ejecuta la mayoría de sus cargas de trabajo de Kubernetes on premises, pero también está comenzando a utilizar los tres principales proveedores de nube para cargas de trabajo gestionadas cuando corresponde.

Necesitará menos expertos
Las habilidades de gestión de Kubernetes son difíciles y costosas de conseguir, especialmente cuando está escribiendo sus propios archivos de configuración YAML. Si tiene personas que pueden ajustar manualmente un clúster de Kubernetes, probablemente querrá liberarlas para administrar su plataforma interna o cualquier carga de trabajo particularmente importante o complicada, transfiriendo la gestión de los clústeres para cargas de trabajo más básicas.

«No es fácil conseguir y conservar personas para estas tecnologías, y eso es claramente un desafío”, afirma Roy de Amadeus.

Mejor confiabilidad
En pocas palabras, los proveedores de meganubes suelen estar en mejores condiciones para gestionar sus clústeres de Kubernetes que usted, debido al tamaño de sus equipos de ingeniería, su amplia perspectiva de implementaciones de clientes, y su acceso a la telemetría de esas implementaciones.

«Es más probable que los proveedores puedan ejecutarlo mejor”, anota O’Grady de RedMonk. «Los proveedores tienen la telemetría y la ventaja de ver que todos sus clientes ejecutan esto, en lugar de que una sola empresa solo tenga su propio modelo”.

Tomemos como ejemplo a Bloomberg, que recurrió a Kubernetes en los embriagadores días del 2015, cuando todavía era solo una versión alfa, antes de pasar a producción en el 2017, una vez que se demostraron las pruebas, la supervisión y la integración continuas necesarias. Si bien los ingenieros de Bloomberg todavía autogestionan en gran medida los clústeres de Kubernetes para aplicaciones on premises, cada vez tiene más sentido usar opciones gestionadas, especialmente «desde la perspectiva de la confiabilidad”, cuando las cargas de trabajo se ejecutan en la nube pública, señala Rybka.

No se preocupe por las actualizaciones

Las actualizaciones son los trabajos menos envidiables para cualquiera que administre su propio Kubernetes, razón por la cual los proveedores gestionados dan prioridad a eliminar estas tareas de su plato.

«Parchar, actualizar y gestionar Kubernetes usted mismo es complejo y complicado y es un trabajo pesado completamente indiferenciado”, afirmó Deepak Singh, vicepresidente de servicios informáticos de AWS.

Mantener el impulso de la nube
Para las organizaciones que avanzan con estrategias que priorizan a la nube pública, la adopción de más servicios administrados puede ayudar a estimular el impulso.

Amadeus firmó recientemente un acuerdo con Microsoft para hacer precisamente esto. «Se mueven rápido y queremos beneficiarnos de eso, por lo que usar más servicios gestionados es algo que consideraremos siempre”, señala Roy. «A mi modo de ver, esa es la forma de aprovechar este impulso”.

Ahora, en versiones más sesgadas de los servicios de Kubernetes, los proveedores están convirtiendo su conocimiento y experiencia en torno a las mejores prácticas de Kubernetes mediante rutas de adopción simplificadas, como GKE Autopilot.

«Algunos lo verán como las llantas de repuesto, pero yo veo al piloto automático como el cinturón de seguridad”, anota Kelsey Hightower, ingeniera principal de Google. «El auto puede circular a la misma velocidad, pero hay más seguridad de manera predeterminada; es una configuración a prueba de balas. La gente siempre nos pregunta por las mejores prácticas y las decisiones que deben tomar; el piloto automático les da eso”.

De manera similar, Singh de AWS afirma que la compañía está mejorando en tomar lo que ha aprendido sobre la ejecución de Kubernetes a escala, y construyendo esa «posición operativa en EKS… que nos permite, como proveedores de servicios, incorporar eso en estos servicios gestionados de forma inmediata. Esa es otra razón por la que verá cómo acelera esta tendencia”.

Sin embargo, este tipo de servicios tiende a despertar, naturalmente, el temor a la dependencia del proveedor. «El piloto automático es más difícil porque recuerdo que me preguntaron por qué la gente se centra en Kubernetes como una capa de middleware si nadie cambia de proveedor. La respuesta es tener la opción de decir que puedo irme”, señala O’Grady de RedMonk. «Cuanto más confía en las opciones específicas del proveedor, esa capacidad de irse desaparece, por lo que es una elección más difícil para las empresas”.

Sigue siendo de código abierto y portátil
Los proveedores gestionados han tenido que ganarse la confianza de la comunidad de código abierto y de los clientes que quieren estar seguros de que están consumiendo una distribución de Kubernetes lo más cercana posible a la versión estándar de código abierto, para permitir una mayor portabilidad y evitar encerrarse.

«Cuando salió Kubernetes, existía el temor de que fuera una especie de carnada para hacer el cambio, una apropiación de tierras por parte de los proveedores contra las comunidades abiertas y que se transformaría en un núcleo abierto. Ha sido necesario cinco, casi seis años para refutar eso”, sostiene Hightower de Google.

De manera similar, Singh de AWS afirma que es importante para algunos clientes que EKS se mantenga cerca de la distribución de código abierto de Kubernetes, «sin que ocurra un vudú extraño que pueda crear diferencias”. AWS abrió recientemente su EKS Distro en GitHub como una forma de demostrarlo.

Joe Beda, cofundador de Kubernetes e ingeniero principal de VMware Tanzu, admite que «es difícil tener esta conversación sin hablar de quedarse atado a un proveedor”. Insta a cualquier persona que tome estas decisiones de compra, a evaluar los riesgos de manera adecuada.

«¿Qué posibilidades hay de que se mude? Si lo hace, ¿cuál será el costo de hacerlo? ¿Cuánta reescritura de código necesitará hacer y cuánto reentrenamiento? Cualquiera que haga estas inversiones debe comprender los requisitos, los riesgos y las compensaciones”, afirma Beda.

Por su parte, la CNCF ejecuta un Certified Kubernetes Conformance Program que garantiza la interoperabilidad de una instalación a la siguiente, independientemente de quién sea el proveedor certificado.

Entonces, ¿por qué no todos hacen esto?
Para organizaciones grandes y complejas, como Amadeus y Bloomberg, es probable que siempre haya algunas cargas de trabajo con las que no se sienta cómodo entregándolas a un proveedor de servicios gestionados, ya sea por las preocupaciones en cuanto a la seguridad de los datos confidenciales, las dependencias on premises complicadas, o una plataforma de equipos sobreprotectores que quieran ajustar a mano sus propios grupos.

«Aquellos que quieran autogestionar partes estarán preocupados por el plano de datos; necesitan personalizar o especializarse en determinadas áreas. No les importa un plano de control administrado”, afirma Hightower de Google.

Sin embargo, la realidad es que todas las razones para operar Kubernetes por su cuenta son cada vez menos convincentes.

«Quizás lo ve como una inversión existente que todavía nadie quiere descartar como un costo hundido, o existen preocupaciones organizacionales conservadoras sobre un conjunto de cargas de trabajo o el negocio”, señala O’Grady de RedMonk. «O existe el temor de que una parte de su infraestructura, que se percibe como estratégica, deje su control. Pero cuando ve que sus compañeros lo hacen, esa aprensión desaparece y verá que más personas se dan cuenta de los beneficios”.

Scott Carey InfoWorld.com – CIOPeru.pe

Artículo anteriorAzure deja de ser la plataforma ‘cloud’ preferida por SAP
Artículo siguienteMicrosoft Teams obtiene componentes Fluid