MicroOS is SUSE’s modern and slightly different take on cluster computing for containers and microservices. This is what you ought to know about it.

Containers have changed the way IT shops operate. The technology has made it far simpler to deploy applications in nearly any data center or cloud environment, and it’s become popular because it promises to reduce complexity.

At the openSUSE Conference in Nurnberg, Germany, the SUSE Container as a Service (CaaS) Platform team described Kubic, its open-source project being built for the SUSE Linux Enterprise MicroOS. I talked with the team’s leaders to understand the project goals, the problems it’s trying to solve for enterprise customers, Kubic’s relationship with CaaS Platform, and its community engagement plans.

First let’s step back for a moment, to give Kubic its context.

There are specialized Linux-based operating systems for containers and microservices, starting with Core OS’s Container Linux. These are bare-bone OSes, designed for large-scale, multi-machine deployments, and they don’t need a package manager as they run containers. Container Linux introduced transitional updates to enterprise distributions and moved away from traditional methods of updating the base OS and applications.

Core OS scratched an itch in the DevOps community. Red Hat responded with Project Atomic, wjhile Canonical released Ubuntu Core. That left SUSE, the oldest Linux company.

Last year, SUSE told me about a new distribution called SUSE Linux Enterprise (SLE) MicroOS, its answer to Container Linux—with some unique touches. SLE MicroOS is the core component of the SUSE CaaS Platform, which uses Kubernetes-based container orchestration for cluster management. The first release of SLE MicroOS, based on the latest SUSE Linux Enterprise Server (SLES) 12 SP2, was announced at LinuxCon Beijing this year. The beta of SUSE CaaS Platform is available, with the first stable release expected in the first week of August.

Everything looks great, except for one little problem: SUSE created an enterprise product without any open source project or community behind it. Oops.

Fortunately, the company realized its mistake in time. “Ideally, we should have started with community first. We are adjusting,” says Simona Arsene, SUSE product manager.

The adjustment? That’s where Kubic comes in.

Unsure how to get started with containers? Here’s a guide for that: Containers-for-Dummies

In 2015, the openSUSE community and SUSE decided to bring closer the two distant relatives, SLES and openSUSE. In response, the openSUSE community announced two new distributions: Tumbleweed and Leap. Tumbleweed is a full distribution, including all the packages needed to run a full OS. In contrast, the OS part of Kubic is designed as a container solution, with only a subset of packages.

Tumbleweed is a rolling release distribution that’s kind of upstream for SLES, the same way Fedora is upstream for Red Hat Enterprise Linux. The Leap distribution is based on the latest release of SLES. All the development work goes into Tumbleweed; then it goes through OpenQA (an automated OS test tool) before the code goes into SLES and then into Leap.

SUSE now is using Tumbleweed for Kubic development, which is upstream for SLE MicroOS and SUSE CaaS. “Going forward, all innovation and new trends will go into Kubic, which is based on Tumbleweed. We will then pick the components for SUSE CaaS Platform from Kubic,” says Andreas Jaeger, SUSE product manager.

The product managers expect SUSE CaaS Platform and Kubic to follow the same symbiotic relationship that has existed between openSUSE Tumbleweed and SLES. Kubic will essentially become the community-driven version of SUSE CaaS Platform, Jaeger says.

“The final goal is two different streams that go hand in hand, so that we don’t have two completely different platforms,” explains Federica Teodori, SUSE technical project manager. In addition to code contribution from the community, the real value Teodori sees is in gaining perspective on how the community will consume a container platform, which may be different from how traditional enterprise customers use it. With Kubic, SUSE is essentially looking at the possibility of new consumption and usage models.

The Kubic Development Process – Kubic is comprised of the same components that form the SUSE CaaS Platform, which include the container host OS, Kubic deployment dashboard, Kubernetes, and Salt. The operating system development happens in Tumbleweed, and the rest of the components are taken from the respective upstream projects, such as Kubernetes and the Moby project.

“Tumbleweed and Kubic share a common code base, meaning that the core packages are shared between the two projects,” explains Jaeger. Using standard tools such as Open Build Service, images are built based on predefined criteria.

Since the development takes place within the Tumbleweed code base, this also means that both SUSE CaaS Platform and Kubic are rolling releases. Kubic will be updated very frequently, its product managers promise, while maintaining the strict policies of Tumbleweed to keep it stable. SUSE CaaS Platform will have a much tighter release cycle. “It will be updated only after very strict testing for enterprise customers, just the way SLES gets updates,” says Thorsten Kukuk, a SUSE distinguished engineer and senior architect.

There may be a Leap version of Kubic, too, but only if the community shows enough interest to warrant that decision.

Kubic is about collaboration, not competition – Kubic is not about competing with other platforms; it’s about encouraging collaboration on new trends and innovation that’s coming out of the container space. For example, “one feature of Kubic that attracted the most attention was the way we implemented transactional updates,” says Arsene.

It does so by using the core functionalities of the Btrfs file system instead of introducing additional tooling or additional processes. Fewer tools and fewer processes translates into a lean and tight container platform.

SUSE also sees Kubic as a platform to enable better communication with its enterprise customers. It lets customers offer feedback and feature requests, just by submitting a patch. Previously, enterprise customers had to contact product management teams if they wanted a new feature. “We don’t want a situation where someone wants to implement a new feature or contribute something but had to wait a year and a half for those things to come up,” says Teodori.

Ease of use is a factor, too. Teodori believes that traditional sysadmins who are already managing their data center infrastructure with SLES should be able to manage their clusters with Kubic. “They don’t need to learn anything new or to hire an expert in Kubernetes,” she adds.

“Many users are still worried about the complexity of containers and setting up a cluster of machines. We tried to address this by making it easy to start with,” says Arsene.

Open source nirvana – Kubic chose some core technologies for the platform, but Teodori’s dream is to make Kubic as technology-agnostic as possible, enabling partners to choose whatever technologies they deem fit for their customers. Some partners want to see how this can help develop their strategy and then price containers within their organization, says Arsene.

Teodori emphasizes that SUSE is not building Kubic as a free-of-cost CaaS platform. It’s not competing with SUSE’s existing products. It’s an incubator for ideas and innovation and a learning experience.

Kubic is available on GitHub; anyone can start experimenting with it. “I would like to see people challenging our decisions and choices. It’s important to know how other people would have done it different and if we can improve on what we have today,” says Teodori. “What’s even more important is that people bring their use cases. They can show us and our partners how they are consuming it. It’s open source. Everyone’s a winner.”

RELATED LINKS Top 7 Persistent Storage Capabilities for Running Docker Containers

Swapnil Bhartiya
Contributing Writer, Independent

Swapnil Bhartiya is a journalist and writer who has been covering Linux & Open Source for 10 years. He brags about having met in person and interviewed almost all the leading personalities of the GNU/Linux world – ranging from Richard M. Stallman to Linus Torvalds.