How SUSE Is Bringing Open Source Projects and Communities Together

The modern IT infrastructure is diverse by design. People are mixing different open source components that are coming from not only different vendors, but also from different ecosystems. In this article, we talk with Thomas Di Giacomo, CTO of SUSE, about the need for better collaboration between open source projects that are being used across industries as we are move toward a cloud native world.

Linux.com: Does the mix of different open source components create a challenge in terms of a seamless experience for customers? How can these projects work more closely with each other?

Thomas Di Giacomo: Totally, more and more, and it’s unlikely to slow down. It can be because of past investments and decisions, with existing pieces of IT and new ones needed to be added to the mix. Or, it might be because of different teams or different parts of an organization working on their own projects with different timelines etc. Or, again, because companies work with partners coming with their own stacks. But maybe even more importantly, it is also because no single one project can be the only answer on its own to what needs to be done.

An OS needs additional modules and applications on top of it to address use cases. To address use cases, IaaS needs to handle specific networking and storage components that are provided by relevant projects. Infrastructure on its own is pretty useless if it’s not paired with application delivery elements, not only to manage the compute part but to tie in software development and application lifecycle.

Linux.com: Can you point out some industry wide efforts in that direction?

Thomas Di Giacomo: There’s a lot of more or less structured initiatives and approaches to that. On one hand, open source is de facto facilitating cross-project work, not only because the code is visible but with a focus on (open) APIs for instance, but it is also indirectly making it sometimes challenging as more and more open source projects are being started. That’s definitely a great thing for innovation, for people to contribute their ideas, for new ideas to grow, etc., but it requires specific attention and focus on helping users with putting together cross-project solutions they need for achieving their plans. Making sure cross-project solutions are easy to install and maintain, for example, and can co-exist with what’s already there.

What starts to happen is cross-project development, integration, and testing with, for instance, shared CI/CD flows and tools between different project. A good example is what OPNFV has initiated a while ago now, with cross CI/CD between OPNFV, OpenStack, OpenDaylight, and others.

Linux.com: At the same time, certain technologies like Kubernetes cut through many different landscapes — whether it be cloud, IoT, Paas, IaaS, containers, etc. That also means the expectations from traditional OS change. Can you talk about how SUSE Linux Enterprise (SLE) is evolving to handle containerized workloads and transactions/atomic updates?

Thomas Di Giacomo: Yes, indeed. Cutting through many different landscapes is also something Linux did (and still does) — from different CPU architectures, form factors, physical and virtualized, on-prem and public clouds, embedded to mainframes, etc.

But you’re right, although the abstractions are improving — getting to higher levels and better at making the underlying layers become less visible (that’s the whole point of abstracting) — the infrastructure components and even the OS, are still there and foundational for the abstracted layers to work. Hence, they have to evolve to meet today’s needs for portability, agility, stability.

We’ve constantly worked on evolving Linux in the past 26 years now, including some specific directions and optimizations to make SUSE Linux both a great container host OS or container base OS, so that container based technologies and use cases would run as smoothly, securely and infrastructure agnostically as possible. Technically, the snapshotting and transactional upgrade/rollback capabilities coming from btrfs as a filesystem, as well as having different possible container engines, keeping the certification, stability and maintainability of an enterprise-grade OS really makes it uniquely appropriate for running container clusters.

Linux.com: While we are talking about OSes, SUSE has both platforms — traditional SLE and atomic/transactional Kubic/SUSE CaaSP. How do these two projects work together, while making life easier for customers?

Thomas Di Giacomo: There are two angles of “together” here. The first one is our usual community/upstream first philosophy, where Kubic/openSUSE Tumbleweed are the core upstream projects for SUSE CaaS Platform and SUSE Linux Enterprise.

The other “together” is about bringing traditional and container-optimized OS closer together. FIrst, the operating system is required to be super modular, where not just a particular functionality is a module but where everything is a module. Second, the OS needs to be multi-modal. By that we mean it should be designed to take care of requirements for both traditional infrastructure and software-defined/cloud-native container-based infrastructure. This is what the community is putting together with Leap15, and what we’re doing for SUSE Linux Enterprise 15 coming out very soon.

Linux.com: SUSE is known for working with partners, instead of building its own stack. How do you cross-pollinate ideas, talent, and technologies as you (SUSE) work across platforms and projects like SLE, Kubic, Cloud Foundry, and Kubernetes?

Thomas Di Giacomo: We work upstream in the respective open source projects as much as we can. Sometimes some open source components are in different projects or outside upstream, and here again we try to bring them back as much as possible. Let me give just a couple of examples to illustrate that.

We’ve been initiating and contributing to a project called openATTIC, aiming at providing a management tool for storage, software-defined storage solutions, and especially for Ceph. openATTIC is obviously open source like everything we do, but it was sitting outside of Ceph. Working with the Ceph community, we’ve started contributing openATTIC code and features to the upstream ceph dashboard/ceph manager, speeding it up with fueling more existing capabilities rather than re-developing the whole from scratch. And then together with the Ceph partners/community and with other Ceph components, we’re facilitating cross-projects by somehow merging them.

Another example is a SUSE project called Stratos. It is a UI for Cloud Foundry distributions (any one of them, upstream and vendors), which we contributed to Cloud Foundry upstream.

Linux.com: Thanks to Cloud Foundry Container Runtime (CFCR), Cloud Foundry and Kubernetes are working closely, can you tell us about the work SUSE is doing with these two communities?

Thomas Di Giacomo: There are lots of container-related initiatives within the Cloud Foundry Foundation, for instance. Some of them we’re leading, some of them we are involved with, and in any case working together with the community and partner companies on those topics. We, for instance, focus on the containerization of Cloud Foundry itself, so that it is lightweight, portable, easily deployable, upgradable on any type of Kubernetes infrastructure (via Helm), so that containers and services are available to both Kubernetes and Cloud Foundry applications on there, and that actually simply containerized applications and Cloud Foundry developed ones co-exist easily.

So today such a containerized Cloud Foundry is available on top of AKS or EKS, on top of SUSE CaaS Platform obviously as well, as possibly any Kubernetes. This was started a while ago and now part of Cloud Foundry upstream, used by our solutions obviously but also by others to provide the CF developer experience on Kubernetes in the most straightforward and native way as possible. There are other activities focused on providing a pluggable container scheduler for CFCR, as well as improving the cross-interoperable service capabilities.

Now this is currently mostly happening in the CF upstream and CF community, and we’re also working to start a workgroup within CNCF on the same topic (especially the containerization of Cloud Foundry), to bring the projects and their communities closer together.

This article was sponsored by SUSE and written by The Linux Foundation.

Sign up to receive updates on LinuxCon + ContainerCon + CloudOpen China / 注册以接收更新:

SUSE如何将开源项目与社区联结在一起

现代 IT 基础设施因设计而异。人们混合的不仅是来自不同供应商的还包括来自不同生态系统的开源组件。在本文中，我们将与SUSE的首席技术官Thomas Di Giacomo讨论的是：当我们正在迈向云原生世界时，让各行各业使用的开源项目进行更好地协作的必要性。

Linux.com: 不同开源组件的混合是否是向客户提出无缝体验的挑战？如何使这些项目更紧密地彼此合作？ 

Thomas Di Giacomo: 这是当然，挑战会越来越多，而且出现的速度不太可能放缓。这可能是因为过去的投资和决策，需要将现有的 IT已有的部分和新的部分添加到混合。或者，这也可能是因为在同一个企业内的不同团队或不同部门在不同的时间表上进行自己的项目。又或者，是因为公司与有其自己节奏的合作伙伴一起工作。但也许更重要的是因为，当面对一个有需要解决问题的项目，不只有一个唯一的方案或答案。

操作系统需要额外的模块和应用程序来解决用例问题。为了解决用例问题，IaaS 需要处理相关项目提供的特定网络和存储组件。如果基础架构与应用程序交付元素不配合，基础架构本身就毫无用处。它不仅要管理计算部分，还要配合软件开发和应用程序生命周期。

Linux.com: 您能指出一些行业在这方面的努力吗？

Thomas Di Giacomo: 行业中有很多或多或少的结构化举措和方法。一方面，开源事实上促进了跨项目的工作，不仅因为代码是可见的，还因大家重点关注（开放） API，但这也间接地使其有时更具挑战性，因为越来越多的开源项目正在启动。对于创新来说，这绝对是一件好事，人们可以贡献他们的想法，获得新的想法等等，但需要特别关注并专注于帮助用户制定实现计划所需的跨项目解决方案。确保跨项目解决方案易于安装和维护，并且可与现有解决方案共存。

现在开始发生的是跨项目开发、集成和测试，例如，在不同项目之间共享 CI/CD 流程和工具。一个很好的例子就是早些时候发起的 OPNFV，以及在 OPNFV、OpenStack、OpenDaylight 和其他等之间的CI/CD交叉。

Linux.com: 与此同时，Kubernetes 等一些特定技术切入了许多不同的场景——无论是云、IoT、Paas、IaaS，还是容器等。这也意味着改变传统操作系统的预期。您能否谈谈 SUSE Linux Enterprise (SLE) 是如何演进以处理集装箱化工作负载和事务/原子更新的？

Thomas Di Giacomo: 确实如此。切入许多不同的场景也是Linux之前做过（并且现在仍然在做）的——它们来自不同 CPU 架构、外形因素、物理和虚拟化、预制和公共云、嵌入到大型机等。

但你说对了，虽然抽象概念正在演进——进入更高层次并让底层变得不那么明显（这就是抽象的整体）—— 基础架构组件甚至操作系统仍然存在并且是工作抽象图层的基础。因此，它们必须不断发展以满足当今行业对便携性、敏捷性和稳定性的需求。

在过去的 26 年中，我们一直致力于不断发展 Linux，包括一些特定的方向和优化，以使 SUSE Linux 成为一款出色的容器主机操作系统或容器基础操作系统，以便基于容器的技术和用例能够平稳、安全地运行，并使基础设施尽可能地不可知。从技术上讲，快照和事务升级/回滚功能来自作为文件系统的 btrfs，并且具有不同可能的容器引擎，可维持企业级操作系统的认证性、稳定性和可维护性，这使它非常适合运行容器集群。

另一个例子是名为 Stratos 的 SUSE 项目。它是 Cloud Foundry 发行产品（其中的任何一个为上游和供应商）中的一个用户界面，我们将其贡献给了 Cloud Foundry 上游。

Linux.com: 感谢 Cloud Foundry 容器运行时 (CFCR) 以及 Cloud Foundry 和 Kubernetes 的紧密合作，您可以介绍一下 SUSE 在这两个社区中所做的工作吗？

Thomas Di Giacomo: Cloud Foundry 基金会内有许多容器相关的举措。在其中一些举措中，我们是领导者，而在另一些中，我们是参与者，并且我们会在任何情况下与社区及合作伙伴公司就这些主题一起开展工作。举例来说，我们专注于 Cloud Foundry本身的集装箱化，以便它可以在任何类型的 Kubernetes 基础设施（通过 Helm）上应用，并且轻量、便携，易于部署和升级。因此，Kubernetes 和 Cloud Foundry 应用程序都可以在基础架构上使用容器和服务，并且简单化的集装箱化应用程序和 Cloud Foundry 开发的应用程序均容易并存。

因此，今天这样一个集装箱化的 Cloud Foundry 不仅可以在 AKS 或 EKS 上使用，也可以在 SUSE CaaS 平台上使用，还可以在任何 Kubernetes 上使用。这是前一段时间开始的，现在是 Cloud Foundry 上游的一部分，明显被我们的解决方案所使用，并且被其他解决方案用于以尽可能最简单直接的方式在 Kubernetes 上提供 CF 开发人员体验。一些其他活动专注于为 CFCR 提供可插拔的容器调度程序，以及改进交叉互操作服务性能。

目前这主要发生在CF上游和CF社区，我们也正在努力在同一主题（尤其是 Cloud Foundry 的集装箱化）内启动一个 CNCF 内的工作组，以使项目及其社区更加紧密地开展合作。

本文由 SUSE 赞助，由 The Linux Foundation 撰写。