A Company Shaped by Acquisitions

For much of the Linux era, SUSE occupied a prominent position as one of the two dominant forces driving enterprise Linux adoption, sitting alongside Red Hat. What followed, however, was one of the more convoluted ownership histories in enterprise IT.

After relocating its headquarters from Germany to Oakland, California, SUSE was sold to Novell. Novell was subsequently acquired by Attachmate. Three years later, Attachmate was acquired by Micro Focus. Under Micro Focus, SUSE absorbed OpenStack distributions and the Cloud Foundry platform-as-a-service (PaaS) assets from Hewlett Packard Enterprise (HPE).

In 2018, SUSE was spun out of Micro Focus, returning to independent status and relocating its headquarters back to Germany. In 2019, Melissa Di Donato — previously Chief Operating Officer at SAP — was appointed CEO. Shortly after, SUSE announced it would discontinue its OpenStack distribution to concentrate resources on cloud-native technologies, specifically the opportunities emerging from the rapid adoption of Kubernetes.

The Cloud-Native Pivot: Kubernetes at the Core

SUSE’s strategic repositioning centered on Kubernetes deployed on its own Linux operating system. This combination served as the foundation for two key offerings:

• Container-as-a-Service (CaaS): The SUSE CaaS Platform, built directly on Kubernetes and SUSE Linux.
• Platform-as-a-Service (PaaS): A Cloud Foundry deployment running on top of Kubernetes, giving development teams a higher-level application platform.

Brent Schroeder, Global CTO at SUSE, described the strategy as a response to the increasing complexity and heterogeneity of modern IT environments. As more workloads migrate to public cloud infrastructure, organisations need a consistent substrate — one that works equally well on virtual machines, bare-metal servers, and across cloud providers.

“Virtual machines, bare-metal and the cloud will be a huge catalyst.”

Brent Schroeder, Global CTO, SUSE

Schroeder’s point reflects a broader industry reality: Kubernetes has become the de facto orchestration layer for containerised workloads, and vendors that build platforms on top of it inherit the flexibility and portability Kubernetes provides. Whether an organisation deploys on a private data centre or a hyperscaler, a Kubernetes-based foundation allows them to standardise tooling, processes, and automation.

DevOps as a Strategic Driver

Schroeder identified DevOps adoption as a primary catalyst for the transitions SUSE was positioning itself to support. Enterprises are not only asking how to build and ship software faster — they are equally concerned with how to secure and govern those pipelines at scale.

A concrete example of this focus was visible in the SUSE CaaS Platform 4 release, which added support for Cilium, an open-source project that uses eBPF (extended Berkeley Packet Filter) to enforce network security policies between containerised application services. Cilium’s inclusion reflected growing demand from enterprise teams for fine-grained, identity-aware network security within Kubernetes clusters — a requirement that mature DevSecOps practices surface quickly.

Key DevOps capabilities that SUSE’s platform strategy addressed at that time included:

• Faster application delivery: Kubernetes-native CI/CD pipelines enabled by the CaaS platform.
• Hybrid cloud portability: Consistent runtime environments across on-premises and public cloud deployments.
• Container network security: Cilium integration for policy enforcement between microservices.
• Developer self-service: PaaS capabilities via Cloud Foundry on Kubernetes, abstracting infrastructure complexity from application teams.

The Competitive Landscape: Red Hat and the CaaS/PaaS Convergence

SUSE was not alone in this strategic direction. Red Hat had been the first major vendor to build a PaaS environment on top of Kubernetes — OpenShift — and had been actively working to eliminate the distinction between CaaS and PaaS through a unified platform experience. IBM’s 2019 acquisition of Red Hat added significant resources and an enterprise sales infrastructure to the OpenShift effort, anchoring IBM’s hybrid cloud strategy on the platform.

The IBM-Red Hat acquisition, however, created a dynamic that potentially benefited SUSE. Organisations that had evaluated or adopted Red Hat OpenShift now found themselves working with an IBM-owned entity — a shift that some enterprise buyers viewed with uncertainty. For SUSE, an independent vendor with a focused Kubernetes portfolio, this created a natural opening to position itself as an alternative without the enterprise-conglomerate overhead.

What This Means for DevOps Teams

SUSE’s trajectory in 2019 illustrated a pattern that recurs throughout enterprise software: vendor consolidation in the infrastructure layer creates both risk and opportunity for engineering teams. Practically, DevOps practitioners evaluating container platforms should account for:

• Vendor independence and long-term viability: A platform tied to a single corporate parent carries different risks than one backed by an independent or widely distributed ecosystem.
• Upstream Kubernetes alignment: Platforms built closer to upstream Kubernetes reduce lock-in and ease migration between providers.
• Security posture: Built-in network policy enforcement (such as Cilium) should be a baseline expectation, not an afterthought.
• Hybrid and multi-cloud flexibility: The ability to run consistently across bare-metal, VM, and public cloud targets is increasingly a hard requirement for platform selection.

Looking Ahead

As of the time of this reporting (late 2019), SUSE’s ultimate path — whether an IPO, further acquisition, or continued independent operation — remained open. What was clear was the company’s intent to compete seriously in the cloud-native space by anchoring its portfolio on Linux, Kubernetes, and container platforms designed for enterprise DevOps workflows.

For DevOps and platform engineering teams, the broader lesson from SUSE’s journey is that the enterprise infrastructure landscape is rarely static. Evaluating platforms requires not just assessing today’s capabilities, but also understanding the corporate and ecosystem context that will determine whether a platform is maintained, evolved, or eventually discontinued.

What Is LXC?

LXC, short for Linux Containers, is an OS-level virtualization mechanism that lets you run multiple isolated Linux environments on a single host kernel. Each container shares the host kernel but has its own filesystem, process tree, network stack, and user space. LXC achieves this isolation through two core Linux kernel features:

• cgroups (control groups) — introduced in Linux kernel 2.6.24, cgroups allow fine-grained allocation and accounting of CPU, memory, block I/O, and network resources across process groups.
• namespaces — namespaces partition global kernel resources so that each container sees its own isolated view of the system (PID namespace, network namespace, mount namespace, etc.).

An LXC container behaves much like a lightweight virtual machine: it runs a full Linux user space, including an init process, and can host multiple services simultaneously. This makes LXC well-suited for scenarios where you want strong process isolation and a full OS environment without the overhead of hardware emulation.

What Is Docker?

Docker began as an internal project at PaaS company dotCloud and was open-sourced in 2013. In its early versions, Docker’s runtime was built directly on top of LXC. Over time Docker replaced LXC with its own container runtime (libcontainer, now part of runc and the broader OCI ecosystem), but it continues to rely on the same underlying kernel features—cgroups and namespaces.

Docker’s core daemon and CLI tools are written in Go. The key design philosophy that differentiates Docker from raw LXC is the single-process-per-container model: each container is expected to run one primary process (a web server, a database, a worker), making containers highly composable and easy to reason about.

Containers vs. Virtual Machines: A Quick Baseline

Both LXC and Docker are container technologies, so it helps to first distinguish containers from full virtual machines (VMs):

Because containers skip hardware emulation entirely, they start faster and consume fewer resources than VMs. The trade-off is that all containers share the host kernel, so a kernel vulnerability or misconfiguration affects all tenants on that host.

Core Differences Between LXC and Docker

1. Design Philosophy

LXC targets system containers: a container is meant to mimic a complete Linux OS instance. You can SSH into it, run multiple daemons (cron, syslog, your application), and manage it much like a traditional server. This makes LXC a close analogue to a lightweight VM.

Docker targets application containers: a container packages exactly one application process and its dependencies. This constraint encourages microservice-style architectures where each container does one thing well and can be scaled, replaced, or updated independently.

2. Image Layering and Portability

Docker introduced a layered, copy-on-write image format. Each instruction in a Dockerfile produces an immutable layer; layers are cached and reused across builds and deployments. This means:

• Images are content-addressed and reproducible.
• Pushing or pulling an image only transfers changed layers, saving bandwidth.
• Any host with a compliant OCI runtime can run the same image without reconfiguration.

LXC does not have a standardized image format in the same sense. Container templates exist, but moving a running LXC environment between hosts requires more manual effort.

3. Versioning and Rollback

Because Docker images are immutable and layered, versioning is built in. You tag images, push them to a registry, and roll back to a previous tag if a release introduces a regression. LXC containers are more like live systems—they accumulate changes over time, which makes disciplined rollback harder without additional tooling.

4. Ecosystem and Tooling

Docker benefits from a large ecosystem: Docker Hub provides hundreds of thousands of pre-built images; Docker Compose orchestrates multi-container applications locally; Kubernetes (and other orchestrators) natively speak the OCI image and container runtime standards that Docker helped define.

LXC’s ecosystem is smaller and more Linux-distribution-centric. LXD (the daemon layer maintained by Canonical that sits on top of LXC) improves the management story considerably, adding REST APIs, clustering, and a richer image server, but LXC/LXD remains less widely adopted in CI/CD pipelines compared to Docker.

5. Networking and Resource Management

Both LXC and Docker use kernel namespaces for network isolation and cgroups for resource limits. Docker’s higher-level networking model (bridge networks, overlay networks, user-defined networks) abstracts away much of the low-level configuration. LXC gives you more direct control, but that control comes with more configuration responsibility.

6. Access via Libvirt

LXC can optionally be managed through libvirt using its LXC driver (connect string: lxc:///). This lets you manage LXC containers alongside QEMU/KVM VMs through a unified API. Libvirt-managed LXC and native LXC are not fully interchangeable, so choose your management path early and stay consistent.

Side-by-Side Comparison

When to Choose LXC

• You need a full Linux OS environment inside a container (systemd, multiple services, SSH daemon).
• You are migrating traditional server workloads to containers incrementally and want minimal application changes.
• You need fine-grained control over container resources without an additional abstraction layer.
• You are already using libvirt and want a unified management plane for VMs and containers.

When to Choose Docker

• You are building or deploying microservices or twelve-factor applications.
• You need reproducible, versioned, portable application packages that run identically in dev, staging, and production.
• You want to integrate with a Kubernetes-based or CI/CD pipeline ecosystem.
• You want access to the large library of pre-built images on public registries.

Summary

LXC and Docker are complementary rather than strictly competing technologies. LXC excels when you need a container that behaves like a lightweight, full-featured Linux system. Docker excels when you need fast, portable, versioned application packaging with broad ecosystem support. For most modern cloud-native and DevOps workflows, Docker (or the broader OCI runtime ecosystem it spawned) is the pragmatic default. For workloads that demand full OS-level isolation without the overhead of a hypervisor, LXC—especially when managed via LXD—remains a compelling option.

Understanding both tools makes you a more versatile infrastructure engineer, since production environments frequently use VMs, LXC-style system containers, and Docker application containers in combination.

Arduino’s support for Linux IoT devices and single-board computers (SBCs) announced at the Embedded Linux Conference+Open IoT Summit NA in March cemented Arduino’s focus on cloud-connected IoT development, extending its reach into edge computing. This move was likely driven by multiple factors — increased complexity of IoT solutions and, secondarily, by more interest in Arduino boards running Linux.

In a “blending” of development communities for the masses — Arduino, Raspberry Pi, and BeagleBone — Arduino’s support for Linux-based boards lowers the barrier of development for IoT devices by combining Arduino’s sensor and actuator nodes with higher processor-powered boards like Raspberry Pi and BeagleBone. Top this with a user-friendly web wizard to connect the Linux boards via the cloud and it simplifies the entire process.

The expanded support for more architectures by the cloud-connected Arduino Create web platform is an inevitable and natural evolution of Arduino’s mission that was born out of a thought to simplify complex technologies with easy-to-use and open-source software, enabling anybody to innovate by making complex technologies simple to use.

Arduino is now also focusing on IoT software to better support multiple hardware platforms, said Luca Cipriani, Arduino’s chief information officer. “The hardware is our core, but now the software is going to be at the same level of importance.”

With the ubiquitous nature of IoT development — it spreads across all verticals — Arduino turned its focus on delivering a simple-to-use integrated online platform, Arduino Create, which was announced a few years ago. At the time, the Arduino web editor allowed developers/makers to write code and upload sketches or programs to any Arduino or Genuino microcontroller boards, storing the Sketchbook in the cloud.

Since then, Arduino has upgraded its cloud platform to enable the deployment of Arduino programs on Linux-based IoT devices, starting last November with devices based on the Intel x86 architectures. Now, developers can deploy Arduino sketches on Linux systems that support Arm processors such as the Raspberry Pi and BeagleBone.

“The macro trend we’re starting to see is that everyone wants some ability of cloud connectivity,” said Matthew Short, senior director of IoT at IHS Markit. “If you can run an IoT cloud, then potentially, you can start to have more interconnect between the cloud and some of the services cloud providers want to offer and the developer community. That might be a little more compelling to the maker base that Arduino brings.”

“For Linux developers, it gives them more tools in their toolbox,” added Short. “There is going to be more distributed compute so the Linux community is familiar with that and [Arduino support] gives them more access to sensors and peripherals, which translates into access into more interesting data. A lot of IoT is about data and making decisions based on that data so it opens up data-gathering platforms to that community.”

Today, Arduino has enabled thousands of users (in fact, Arduino has 500,000 registered users on the forum/platform) to transform their ideas into products. They are using Arduino to teach technology, fabricate prototypes, and even build products.