jueves, noviembre 6, 2025

¿Hemos llegado a un punto de inflexión distrolse?

Tecnología¿Hemos llegado a un punto de inflexión distrolse?

Hay un ciclo virtuoso en tecnología que empuja los límites de lo que se está construyendo y cómo se está utilizando. Un nuevo desarrollo tecnológico surge y captura la atención del mundo. Las personas comienzan a experimentar y descubrir aplicaciones novedosas, casos de uso y enfoques para maximizar el potencial de la innovación. Estos casos de uso generan un valor significativo, alimentando la demanda de la próxima iteración de la innovación y, a su vez, una nueva ola de innovadores crean la próxima generación de casos de uso, impulsando nuevos avances.

La contenedorización se ha convertido en la base del desarrollo moderno de software nativo de nube, que admiten nuevos casos de uso y enfoques para construir aplicaciones resistentes, escalables y portátiles. También posee las claves para la próxima innovación de entrega de software, que requiere simultáneamente la evolución para asegurar el software segura por diseño y actualizado continuamente y sirviendo como medios para llegar allí.

A continuación, hablaré sobre algunas de las innovaciones que condujeron a nuestra revolución contenedorizada, así como algunos de los rasgos del desarrollo de software nativo de nube que han llevado a este punto de inflexión, uno que ha preparado al mundo para alejarse de las distribuciones tradicionales de Linux y hacia un nuevo enfoque para la entrega de software de código abierto.

La iteración nos ha acercado a la ubicuidad

Ha habido muchas innovaciones que han allanado el camino para una entrega de código abierto más segura y desempeñada. En aras de su tiempo y mi recuento de palabras, llamaré tres hitos particulares. Cada paso, desde contenedores de Linux (LXC) hasta Docker y, en última instancia, la Iniciativa de Contenedor Open (OCI), basado en su predecesor, abordando las limitaciones y desbloqueando nuevas posibilidades.

LXC sentó las bases al aprovechar las capacidades del kernel de Linux (a saber, los grupos y espacios de nombres), para crear entornos aislados livianos. Por primera vez, los desarrolladores podrían empaquetar aplicaciones con sus dependencias, ofreciendo un grado de consistencia en diferentes sistemas. Sin embargo, la complejidad de LXC para los usuarios y su falta de un catálogo estandarizado de distribución de imágenes obstaculizó la adopción generalizada.

Docker surgió como un cambio de juego, democratizando la tecnología de contenedores. Simplificó el proceso de crear, ejecutar y compartir contenedores, haciéndolos accesibles para una audiencia más amplia. La interfaz fácil de usar de Docker y la creación de Docker Hub, un repositorio central para imágenes de contenedores, fomentó un ecosistema vibrante. Esta facilidad de uso alimentó la adopción rápida, pero también expresó preocupaciones sobre el bloqueo de los proveedores y la necesidad de interoperabilidad.

Reconociendo el potencial de fragmentación, la OCI (iniciativa de contenedores abiertos) intervino para estandarizar los formatos de contenedores y los tiempos de ejecución. Al definir las especificaciones abiertas, el OCI aseguró que los contenedores pudieran construirse y correr a través de diferentes plataformas, fomentando un panorama saludable y competitivo. Proyectos como RUNC y Containerd, nacidos de la OCI, proporcionaron una base común para los tiempos de ejecución de contenedores y habilitaron una mayor portabilidad e interoperabilidad.

Los estándares de OCI también permitieron que Kubernetes (otro estándar neutral en el proveedor) se convierta en una plataforma verdaderamente portátil, capaz de ejecutarse en una amplia gama de infraestructura y permitir a las organizaciones orquestar sus aplicaciones de manera consistente en diferentes proveedores de nubes y entornos locales. Esta estandarización y sus innovaciones asociadas desbloquearon todo el potencial de los contenedores, allanando el camino para su presencia ubicua en el desarrollo moderno de software.

(Contenedorizado) El software está comiendo el mundo

Los avances en Linux, la rápida democratización de los contenedores a través de Docker y la estandarización de OCI se impulsaron por necesidad, con la evolución de los casos de uso de aplicaciones nativos de la nube que impulsan la orquestación y la estandarización hacia adelante. Esas características de la aplicación nativa de la nube también destacan por qué un enfoque de propósito general para las distribuciones de Linux ya no sirve a los desarrolladores de software con las bases más seguras y actualizadas para desarrollar:

Arquitectura orientada al microservicio: las aplicaciones nativas de la nube generalmente se construyen como una colección de servicios pequeños e independientes, con cada microservicio realizando una función específica. Cada uno de estos microservicios se puede construir, desplegar y mantener independientemente, lo que proporciona una tremenda cantidad de flexibilidad y resistencia. Debido a que cada microservicio es independiente, los constructores de software no requieren paquetes de software integrales para ejecutar un microservicio, confiando solo en lo esencial de un contenedor.

Conconse de recursos y eficientes: las aplicaciones nativas de la nube están creadas para ser eficientes y conscientes de los recursos para minimizar las cargas en infraestructura. Este enfoque despojado se alinea naturalmente con los contenedores y una estrategia de implementación efímera, con nuevos contenedores que se implementan constantemente y otras cargas de trabajo se actualizan al último código disponible. Esto reduce los riesgos de seguridad aprovechando los nuevos paquetes de software, en lugar de esperar parches de distribución y backports.

Portabilidad: las aplicaciones nativas de la nube están diseñadas para ser portátiles, con un rendimiento y confiabilidad consistentes, independientemente de dónde se esté ejecutando la aplicación. Como resultado de que los contenedores estandarizan el entorno, los desarrolladores pueden ir más allá de los viejos dolores de cabeza del pasado «funcionó bien en mi máquina».

El ciclo virtuoso de la innovación que impulsa nuevos casos de uso y, en última instancia, nuevas innovaciones es claro cuando se trata de la contenedores y la adopción generalizada de aplicaciones nativas de la nube. Críticamente, este punto de inflexión de las demandas de innovación y caso de uso ha impulsado una increíble tasa de cambio dentro del software de código abierto: hemos alcanzado un punto en el que las distribuciones tradicionales de Linux «congeladas» superan la familiaridad y la estabilidad percibida de la última generación de la entrega de software.

Entonces, ¿cómo debería ser la próxima generación de entrega de software de código abierto?

Entrar: Chainguard OS

Para cumplir con las expectativas modernas de seguridad, rendimiento y productividad, los constructores de software necesitan el último software en la forma más pequeña diseñada para su caso de uso, sin ninguno de los CVE que conducen al riesgo para el negocio (y una lista de «fijadores» de los equipos de seguridad). Hacer el bien en esos parámetros requiere algo más que hacer el pasado. En su lugar, la próxima generación de entrega de software de código abierto debe comenzar desde la fuente de software seguro y actualizado: los mantenedores ascendentes.

Es por eso que Chainguard construyó este nuevo enfoque distrolado, reconstruyendo continuamente los paquetes de software basados ​​no en las distribuciones aguas abajo sino en las fuentes aguas arriba que eliminan las vulnerabilidades y agregan mejoras de rendimiento. Lo llamamos OS de Cartago.

Chainguard OS sirve como base para los resultados de seguridad, eficiencia y productividad amplios que los productos Chainguard entregan hoy, «Chainguarding» un catálogo de rápido crecimiento de más de 1,000 imágenes de contenedores.

Chainguard OS se adhiere a cuatro principios clave para hacer que sea posible:

  • Integración y entrega continua: enfatiza la integración continua, las pruebas y la liberación de paquetes de software ascendente, asegurando una tubería de desarrollo simplificada y eficiente a través de la automatización.
  • Actualizaciones y reconstrucciones nano: favorece las actualizaciones y reconstrucciones incrementales sin parar sobre las principales actualizaciones de lanzamiento, asegurando transiciones más suaves y minimizando los cambios disruptivos.
  • Artifactos mínimos, endurecidos e inmutables: elimina el hinchazón del proveedor innecesario de los artefactos de software, lo que hace que los paquetes de sidecar y los extras opcieran al usuario al tiempo que mejoran la seguridad a través de medidas de endurecimiento.
  • Minimización delta: mantiene las desviaciones de la corriente aguas arriba a un mínimo, incorporando parches adicionales solo cuando es esencial y solo durante el tiempo necesario hasta que se corta una nueva liberación de aguas arriba.

Quizás la mejor manera de resaltar el valor de los principios de Chainguard OS es ver el impacto en las imágenes de Chainguard.

En la siguiente captura de pantalla (y se puede ver aquí), puede ver una comparación de lado a lado entre un externo y Imagen de Chainguard.

Además de la discrepancia muy clara en el recuento de vulnerabilidades, vale la pena examinar la diferencia de tamaño entre las dos imágenes de contenedores. La imagen de Chainguard comprende solo el 6% de la imagen alternativa de código abierto.

Junto con el tamaño de la imagen minimizado, la imagen de Chainguard se actualizó por última vez solo una hora antes de la captura de pantalla, algo que sucede a diario:

Una exploración rápida de los datos de procedencia y SBOM ilustra la integridad y la inmutabilidad de extremo a extremo de los artefactos, una especie de etiqueta nutricional completa que subraya la seguridad y la transparencia que puede proporcionar un enfoque moderno para la entrega de software de código abierto.

Cada imagen de Chainguard es un ejemplo práctico del valor que proporciona Chainguard OS, ofreciendo una alternativa marcada a lo que ha surgido. Quizás el mayor indicador es la retroalimentación que hemos recibido de los clientes, que han compartido cómo las imágenes de contenedores de Chainguard han ayudado a eliminar las CVE, asegurar sus cadenas de suministro, alcanzar y mantener el cumplimiento, y reducir el trabajo de los desarrolladores, permitiéndoles volver a asignar recursos de desarrolladores preciosos.

Creemos que los principios y el enfoque de Chainguard OS se pueden aplicar a una variedad de casos de uso, extendiendo los beneficios de los paquetes de software de la fuente reconstruidos continuamente al ecosistema de código abierto.

Si le resulta útil, asegúrese de consultar nuestro documento técnico sobre este tema o comunicarse con nuestro equipo para hablar con un experto en el enfoque distroloso de Chainguard.

Nota: Este artículo es escrito por expertos y contribuido por Dustin Kirkland – VP de Ingeniería en Chainguard.

Artículos más populares