LinuxParty

La moderna infraestructura de TI es diversa por diseño. Las personas están mezclando diferentes componentes de código abierto que provienen no solo de diferentes proveedores, sino también de diferentes ecosistemas. En este artículo, hablamos con Thomas Di Giacomo, CTO de SUSE, sobre la necesidad de una mejor colaboración entre los proyectos de código abierto que se utilizan en todas las industrias a medida que avanzamos hacia un mundo nativo de la nube.

Linux.com: ¿La combinación de diferentes componentes de código abierto crea un desafío en términos de una experiencia perfecta para los clientes? ¿Cómo pueden estos proyectos trabajar más estrechamente el uno con el otro?

Thomas Di Giacomo: Totalmente, cada vez más, y es poco probable que disminuya la velocidad. Puede deberse a inversiones y decisiones pasadas, con piezas de TI existentes y nuevas que se deben agregar a la mezcla. O bien, podría ser debido a diferentes equipos o diferentes partes de una organización que trabajan en sus propios proyectos con diferentes líneas de tiempo, etc. O, una vez más, porque las empresas trabajan con socios que vienen con sus propios stacks. Pero quizás aún más importante, es también porque ningún proyecto en particular puede ser la única respuesta por sí solo a lo que se necesita hacer.

Un SO necesita módulos y aplicaciones adicionales además de los casos de uso. Para abordar casos de uso, IaaS necesita manejar componentes específicos de redes y almacenamiento que son proporcionados por proyectos relevantes. La infraestructura en sí misma es bastante inútil si no se combina con elementos de entrega de aplicaciones, no solo para administrar la parte de cómputo, sino también para vincular el desarrollo del software y el ciclo de vida de la aplicación.

Linux.com: ¿Puedes señalar algunos esfuerzos de toda la industria en esa dirección?

Thomas Di Giacomo: Hay muchas iniciativas y enfoques más o menos estructurados para eso. Por un lado, el código abierto facilita de facto el trabajo entre proyectos, no solo porque el código es visible, sino que se enfoca en API (abiertas) por ejemplo, pero también indirectamente lo hace a veces desafiante a medida que más y más proyectos de código abierto se están comenzando. Eso es definitivamente algo grandioso para la innovación, para que la gente contribuya con sus ideas, para que crezcan nuevas ideas, etc., pero requiere atención y enfoque específicos para ayudar a los usuarios a armar las soluciones entre proyectos que necesitan para lograr sus planes. Asegurándose de que las soluciones de proyectos cruzados sean fáciles de instalar y mantener, por ejemplo, y puedan coexistir con lo que ya existe.

Lo que comienza a suceder es el desarrollo, la integración y la prueba de proyectos cruzados con, por ejemplo, flujos de CI / CD compartidos y herramientas entre diferentes proyectos. Un buen ejemplo es lo que OPNFV ha iniciado hace un tiempo, con IC / CD cruzados entre OPNFV, OpenStack, OpenDaylight y otros.

Linux.com: al mismo tiempo, ciertas tecnologías como Kubernetes recortan muchos paisajes diferentes, ya sea en la nube, IoT, Paas, IaaS, contenedores, etc. Eso también significa que las expectativas del cambio de SO tradicional cambian. ¿Puede hablar sobre cómo evoluciona SUSE Linux Enterprise (SLE) para manejar cargas de trabajo en contenedores y transacciones / actualizaciones atómicas?

Thomas Di Giacomo: Sí, de hecho. El corte a través de muchos paisajes diferentes también es algo que hizo Linux (y aún lo hace): desde diferentes arquitecturas de CPU, factores de forma, nubes físicas y virtualizadas, on-prem y públicas, integradas en mainframes, etc.

Pero tiene razón, aunque las abstracciones están mejorando: llegar a niveles más altos y hacer que las capas subyacentes se vuelvan menos visibles (ese es el objetivo de la abstracción): los componentes de la infraestructura e incluso el sistema operativo aún están allí y son fundamentales para que las capas abstractas funcionen Por lo tanto, deben evolucionar para satisfacer las necesidades actuales de portabilidad, agilidad y estabilidad.

Trabajamos constantemente en la evolución de Linux en los últimos 26 años, incluidas algunas direcciones y optimizaciones específicas para hacer que SUSE Linux sea un sistema operativo host contenedor o un sistema operativo basado en contenedor, de modo que las tecnologías basadas en contenedores y los casos de uso se ejecuten de forma fluida y segura e infraestructura de manera agnóstica como sea posible. Técnicamente, las capacidades de snapshotting y actualización / reversión transaccional provenientes de btrfs como sistema de archivos, además de tener diferentes motores de contenedores posibles, manteniendo la certificación, estabilidad y capacidad de mantenimiento de un SO de nivel empresarial, lo hacen especialmente apropiado para ejecutar clusters de contenedores.

Linux.com: mientras hablamos de sistemas operativos, SUSE tiene ambas plataformas: tradicional SLE y atómico / transaccional Kubic / SUSE CaaSP. ¿Cómo trabajan juntos estos dos proyectos, al tiempo que hacen la vida más fácil para los clientes?

Thomas Di Giacomo: Hay dos ángulos de "juntos" aquí. La primera es nuestra primera filosofía habitual de comunidad / aguas arriba, donde Kubic / openSUSE Tumbleweed son los principales proyectos de upstream para SUSE CaaS Platform y SUSE Linux Enterprise.

El otro "conjunto" se trata de acercar el sistema operativo tradicional y optimizado para contenedores. En primer lugar, se requiere que el sistema operativo sea súper modular, donde no solo una funcionalidad particular es un módulo sino que todo es un módulo. En segundo lugar, el sistema operativo debe ser multimodal. Con esto queremos decir que debe diseñarse para satisfacer los requisitos tanto de la infraestructura tradicional como de la infraestructura basada en contenedores definida por software / nativa de la nube. Esto es lo que la comunidad está armando con Leap15, y lo que estamos haciendo para SUSE Linux Enterprise 15 sale muy pronto.

Linux.com: SUSE es conocido por trabajar con socios, en lugar de crear su propia pila. ¿Cómo se polinizan las ideas, el talento y las tecnologías a medida que usted (SUSE) trabaja en plataformas y proyectos como SLE, Kubic, Cloud Foundry y Kubernetes?

Thomas Di Giacomo: trabajamos en los proyectos de código abierto respectivos en la medida de lo posible. A veces, algunos componentes de código abierto se encuentran en proyectos diferentes o fuera de la cadena, y una vez más tratamos de devolverlos lo más posible. Déjame darte solo un par de ejemplos para ilustrar eso.

Hemos estado iniciando y contribuyendo a un proyecto llamado openATTIC, con el objetivo de proporcionar una herramienta de gestión para el almacenamiento, soluciones de almacenamiento definidas por software, y especialmente para Ceph. openATTIC es obviamente de código abierto como todo lo que hacemos, pero estaba sentado fuera de Ceph. Al trabajar con la comunidad Ceph, hemos comenzado a contribuir con el código y las características de openATTIC al administrador ceph / ceph upstream, acelerándolo con el aumento de las capacidades existentes en lugar de volver a desarrollar el conjunto desde cero. Y luego, junto con los socios / comunidad de Ceph y con otros componentes de Ceph, estamos facilitando proyectos cruzados al fusionarlos de algún modo.

Otro ejemplo es un proyecto de SUSE llamado Stratos. Es una interfaz de usuario para las distribuciones de Cloud Foundry (cualquiera de ellas, upstream y proveedores), que contribuimos a Cloud Foundry upstream.

Linux.com: Gracias a Cloud Foundry Container Runtime (CFCR), Cloud Foundry y Kubernetes están trabajando en estrecha colaboración, ¿puede hablarnos sobre el trabajo que SUSE está haciendo con estas dos comunidades?

Thomas Di Giacomo: hay muchas iniciativas relacionadas con contenedores dentro de Cloud Foundry Foundation, por ejemplo. Algunos de ellos somos líderes, algunos de ellos estamos involucrados y, en cualquier caso, trabajamos juntos con la comunidad y las empresas asociadas en esos temas. Nosotros, por ejemplo, nos enfocamos en la contenedorización de Cloud Foundry, para que sea liviana, portátil, de fácil implementación y actualizable en cualquier tipo de infraestructura de Kubernetes (a través de Helm), de modo que los contenedores y servicios estén disponibles para Kubernetes y Cloud Foundry aplicaciones allí, y que en realidad las aplicaciones en contenedores y Cloud Foundry desarrolladas coexisten fácilmente.

Por eso, hoy en día, una Cloud Foundry en contenedor está disponible encima de AKS o EKS, además de la plataforma Caas de SUSE, obviamente, como posiblemente cualquier Kubernetes. Esto comenzó hace un tiempo y ahora forma parte de Cloud Foundry upstream, utilizado obviamente por nuestras soluciones pero también por otros para proporcionar la experiencia del desarrollador de CF en Kubernetes de la forma más directa y nativa posible. Hay otras actividades centradas en proporcionar un planificador de contenedores conectable para CFCR, así como mejorar las capacidades de servicio interoperable cruzado.

Ahora esto está sucediendo principalmente en la comunidad de CF upstream y CF, y también estamos trabajando para iniciar un grupo de trabajo dentro de CNCF sobre el mismo tema (especialmente la contenedorización de Cloud Foundry), para acercar los proyectos y sus comunidades.

Este artículo fue patrocinado por SUSE y escrito por The Linux Foundation.