Noticias

Infraestructura nativa de la nube: cuando el futuro se encuentra con el presente

Todos hemos oído hablar de las aplicaciones nativas de la nube en los últimos años, pero ¿qué pasa con la infraestructura nativa de la nube? ¿Existe alguna razón por la cual la infraestructura no puede ser nativa de la nube? ¿O tal vez ya es nativo de la nube, pero nunca has tenido la oportunidad de profundizar en la pila para comprobarlo? ¿Qué significa realmente el término «infraestructura nativa de la nube»?

Cuanto más piensas en ello, más confundido te vuelves. Todos sabemos que la forma moderna de construir infraestructura es trasladarla a la nube. Pero, ¿cómo puede la propia nube ser nativa de la nube o… nativa en sí misma? Si esto le parece complicado, no se preocupe: ha venido al lugar correcto. Siga leyendo para ver qué sucede cuando el futuro de la infraestructura se encuentra con el presente.

Bloque de construcción nativo de la nube

Antes de comenzar a explorar la infraestructura nativa de la nube, asegurémonos de tener una comprensión común del concepto de nube nativa en sí.Según la definición mantenida oficialmente. Fundación de Computación Nativa en la Nube (CNCF)La nube nativa es un conjunto de tecnologías que «permiten a las organizaciones crear y ejecutar aplicaciones escalables en entornos modernos y dinámicos».

Muchas palabras de moda pero pocos detalles técnicos. Afortunadamente, la definición del CNCF también destaca algunos ejemplos de componentes básicos para aplicaciones nativas de la nube. Esos son:

  • envase – Empaquetar el código de una aplicación y sus dependencias y ejecutarlos de forma independiente en un entorno de ejecución
  • malla de servicio – Controlar la comunicación entre servicios a través de una red proxy configurada centralmente
  • microservicios – Convertir las aplicaciones en pequeños servicios independientes que se comunican entre sí a través de API bien definidas.
  • Infraestructura inmutable – Transformar el modelo de gestión de servicios de un modelo de cambio de componentes a un modelo de reemplazo de componentes.
  • API declarativa – Habilitar la descripción del estado deseado de la aplicación.
LEER  Una vulnerabilidad crítica que afecta a la mayoría de las distribuciones de Linux permite a Bootkit

Si bien la definición no obliga a los desarrolladores de aplicaciones nativas de la nube a utilizar todos estos componentes, la mayoría de las aplicaciones nativas de la nube generalmente siguen este patrón. ¿Pero podemos aplicar también el mismo enfoque a la infraestructura subyacente?

Todo comienza con la nube nativa

Es más fácil cuando trabajas en el espacio de aplicaciones. La infraestructura ya está ahí y proporciona todas las funciones que necesita, como tiempos de ejecución de contenedores, mecanismos de reversión, etc. Pero, ¿qué sucede si opera en un entorno donde la infraestructura subyacente aún no se ha construido, como un espacio de nube privada?

Debajo de cada nube no hay más que un conjunto de recursos básicos. Un grupo de máquinas físicas equipadas con CPU, RAM y discos. El software de gestión de la nube transforma esta infraestructura en bruto en una nube totalmente funcional. Y no existe una única razón por la que este software no pueda ser nativo de la nube.

Cuando la nube se convierte en la aplicación

La nube en sí es sólo otra aplicación, muy simplificada. Se monta directamente en el metal y proporciona funcionalidad a las aplicaciones de inquilinos que se ejecutan encima. De esta manera, si es nativo de la nube depende de cómo se implemente el software de gestión de la nube subyacente. Portar su arquitectura a los componentes enumerados anteriormente sienta las bases para una infraestructura nativa de la nube.

Primero, podemos descomponer el software de administración de la nube en múltiples microservicios. De hecho, las principales plataformas en la nube, como OpenStack, ya siguen este modelo. Luego podemos ejecutar cada microservicio en un contenedor inmutable. Kubernetes (K8) y Instantánea adecuado para este propósito. Finalmente, las API declarativas admiten abstracciones de nivel superior. En lugar de configurar laboriosamente contenedores individuales, podemos simplemente declarar el estado deseado en la nube.

La infraestructura nativa de la nube es una solución ideal para las organizaciones que buscan una plataforma en la nube preparada para el futuro que se ejecute localmente. Si bien la adopción de una arquitectura híbrida de múltiples nubes con nube privada les permite lograr optimización de costos, soberanía digital y objetivos de rendimiento, el uso de principios nativos de la nube les permite operarla de manera efectiva. De esta manera, el software de gestión de la nube se convierte en una aplicación más en el ecosistema contenedorizado moderno, aplanando la curva de aprendizaje y mejorando la eficiencia de DevOps.

Veamos cómo funciona en la práctica.

Sunbeam: ejemplo de implementación de infraestructura nativa en la nube

Un ejemplo perfecto de implementación de infraestructura nativa de la nube es Luz de sol.

Sunbeam es un proyecto OpenStack que revoluciona la forma en que los usuarios implementan y operan la nube. Su arquitectura se basa íntegramente en componentes que definen el paradigma nativo de la nube. Al contener el plano de control de OpenStack y ejecutarlo sobre K8, Sunbeam convierte efectivamente a OpenStack en una extensión de Kubernetes. De esta manera, los clústeres K8 pueden obtener funcionalidades adicionales, como capacidades tradicionales de infraestructura como servicio (IaaS), que no están disponibles en su ecosistema de forma predeterminada.

La arquitectura de Sunbeam se muestra en la siguiente figura:

A través de Sunbeam, todos los componentes de software de gestión de la nube que requieren acceso al hardware se pueden entregar rápidamente. Esto incluye capacidades de almacenamiento proporcionadas por servicios de gobierno y gestión de la nube, clústeres e hipervisores de Kubernetes y servicios de plano de datos. Este enfoque garantiza un alto nivel de seguridad debido al aislamiento y las estrictas restricciones proporcionadas por snapd. A su vez, todos los servicios que no requieren acceso al hardware se ejecutan en K8 como imágenes OCI. Esto incluye principalmente servicios de plano de control en la nube.

Todas las partes de la pila están envueltas. Operador obsesionado. La API declarativa que tienen delante permite abstracciones de nivel superior.De esta manera, el despliegue inicial de la nube se simplifica significativamente, mientras que sus operaciones posteriores al despliegue, como habilitar enchufarpara lograr una automatización completa.

aprende más

Descargue nuestro libro electrónico para obtener más información sobre Sunbeam y cómo convertir OpenStack y Kubernetes en aplicaciones nativas de la nube.

Lea más blogs sobre la nube nativa y Sunbeam.

Póngase en contacto con un experto en la nube de Canonical.

LEER  Mira el nuevo tráiler de Cyber ​​​​Knights: Flashpoint, un juego de rol con tácticas de escuadrón y atracos.

Publicaciones relacionadas

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Botón volver arriba