What Is Longhorn?

Longhorn is open-source, cloud-native block storage software originally developed by Rancher Labs. At the time of its general availability announcement, it had been accepted as a sandbox project under the Cloud Native Computing Foundation (CNCF), placing it alongside other foundational Kubernetes ecosystem projects.

Rancher Labs announced general availability of Longhorn to give Kubernetes clusters reliable, production-grade access to persistent block storage — a long-standing pain point for teams running stateful, distributed applications on Kubernetes.

Why Persistent Storage on Kubernetes Is Hard

Kubernetes was originally designed with stateless workloads in mind. Stateful applications — databases, message queues, content management systems — require persistent volumes that survive pod restarts and node failures. Traditional storage solutions were not designed with Kubernetes orchestration in mind, creating operational gaps around provisioning, replication, snapshots, and disaster recovery.

Longhorn addresses these gaps natively within the Kubernetes control plane, rather than bolting on external storage management tooling.

Key Features of Longhorn

• One-click persistent storage: Volumes can be added to a Kubernetes cluster through a single UI action, lowering the barrier for teams unfamiliar with storage administration.
• Snapshots and backup/restore: Built-in snapshot capabilities allow point-in-time recovery. Backup and restore supports recovery time and recovery point objectives (RTO/RPO) across clusters.
• Asynchronous cross-cluster replication: IT teams can schedule asynchronous replication between Longhorn instances running on separate clusters, supporting disaster recovery workflows.
• Thin provisioning: Storage is allocated on demand rather than pre-allocated, improving resource utilization.
• Non-disruptive volume expansion: Volumes can be resized without taking workloads offline.
• Standalone UI and CLI: Longhorn ships with its own web-based dashboard as well as CLI integration with standard Kubernetes tooling (kubectl).
• Live upgrades: Longhorn can be upgraded without downtime to running workloads.

Architecture: Lightweight and Microservices-Based

Longhorn is implemented in approximately 30,000 lines of Go code. Its relatively small footprint compared with legacy storage software comes from building directly on existing Linux storage primitives rather than reimplementing low-level storage logic from scratch.

Each Longhorn volume is managed by its own dedicated micro-controller — a microservices architecture that isolates fault domains. A failure in one volume controller does not cascade to other volumes, improving overall cluster resilience.

This design also enables Longhorn to act as a bridge layer to existing enterprise storage infrastructure. It can be deployed on top of:

• NFS storage arrays
• iSCSI storage arrays
• Fibre Channel storage arrays
• Cloud-provider block storage systems

This means organizations that have invested in enterprise storage hardware can integrate it with Kubernetes workloads through Longhorn without abandoning existing infrastructure.

Commercial Support and Rancher Integration

Alongside the open-source CNCF project, Rancher Labs (now part of SUSE) offered commercial support for Longhorn to customers using its Rancher Kubernetes distribution. This gave enterprise teams a supported path to production use, including SLA-backed assistance for storage issues on Rancher-managed clusters.

The Broader Context: Kubernetes Storage Maturity

The announcement reflected a maturing Kubernetes ecosystem where storage was becoming a first-class concern. At the time, CNCF survey data suggested that while a minority of respondents were running storage projects in production, a significant portion were evaluating them — indicating growing enterprise intent to solve persistent storage at the platform level.

The trajectory points toward storage management converging with Kubernetes cluster operations. Rather than storage administrators managing arrays independently from application teams, persistent volume lifecycle — provisioning, snapshotting, replication, and recovery — is increasingly managed through Kubernetes-native APIs and controllers like Longhorn.

External, dedicated storage arrays will continue to exist for high-volume, specialized workloads. However, for primary workload storage tightly coupled to containerized applications, cloud-native solutions like Longhorn reduce operational overhead and total cost compared with traditional storage platforms.

Getting Started with Longhorn

Longhorn can be installed on any Kubernetes cluster using Helm, kubectl manifests, or directly from the Rancher Apps catalog. The official project documentation is maintained at longhorn.io and the source code is available on GitHub.

# Install Longhorn via Helm
helm repo add longhorn https://charts.longhorn.io
helm repo update
helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace

After installation, the Longhorn UI is accessible via a Kubernetes service, and storage classes are automatically created and available to any workload requesting persistent volume claims.

Why Hardware Acceleration Matters at the Edge

Edge computing shifts application workloads from centralized cloud data centers to systems located physically close to end users. This proximity is essential for workloads that demand either very low latency or very high bandwidth — think real-time video processing, network function virtualization, or industrial control systems. In many of these scenarios, microseconds matter, and round-trips to a distant cloud are simply not acceptable.

To push edge performance further, engineers at CableLabs have been experimenting with hardware accelerators — specifically field-programmable gate arrays (FPGAs) and graphics processing units (GPUs) — as part of an initiative called Project Adrenaline. The goal is to improve edge compute performance while reducing the overall cost and complexity of edge deployments.

FPGAs and GPUs as Hardware Accelerators

Both FPGAs and GPUs can offload specific compute tasks from a general-purpose CPU, delivering gains across three dimensions that are especially critical at the edge:

• Time: Certain operations complete significantly faster on an accelerator than on a CPU.
• Power: Accelerators can perform targeted computations more efficiently, reducing power draw at space-constrained edge sites.
• Space: Fewer physical servers may be needed when accelerators handle high-throughput tasks.

Choosing the right accelerator for a given workload is not always straightforward. CableLabs offers the following general guidelines based on operation type:

• Integer (whole number) operations: Typically fastest on a general-purpose CPU.
• Floating-point (decimal number) operations: Typically fastest on a GPU.
• Bitwise operations (manipulating ones and zeros): Typically fastest on an FPGA.

These are guidelines, not hard rules — real-world workload characteristics, memory bandwidth, and pipeline design all influence the optimal platform choice.

The Pipeline Cost of Switching Platforms

One often-overlooked factor when designing accelerated workloads is the cost of moving data between compute platforms. Every memory copy incurs latency and overhead, even when it occurs within the same physical server. This means that naively routing each task in a pipeline to whichever accelerator is theoretically fastest for that task type may actually produce worse end-to-end performance than keeping consecutive tasks on a single platform.

When designing edge pipelines, engineers should profile the full end-to-end data flow and account for data transfer overhead, not just per-task execution speed.

Programming Challenges for Accelerators

Writing applications for FPGAs and GPUs is generally more complex than writing for general-purpose CPUs. The ecosystem of supported languages and toolchains is narrower, and developers often need hardware-specific expertise.

Frameworks such as OpenCL attempt to provide a unified programming model that targets CPUs, GPUs, and FPGAs from a single codebase. However, this portability comes with a performance penalty that can make OpenCL a poor fit for latency-sensitive edge workloads. On the positive side, major accelerator hardware vendors have been actively targeting the edge market, releasing optimized frameworks and pre-built libraries that are gradually closing the performance gap between portable and hardware-native code.

Integrating Accelerators with Kubernetes: SNAPS-Kubernetes

Kubernetes was not originally designed with hardware accelerators in mind. Managing FPGA and GPU resources in a Kubernetes cluster — from driver installation to device plugin configuration — requires additional tooling and careful lifecycle management.

As part of Project Adrenaline, CableLabs developed and open-sourced tools to ease this process. These tools are available in the SNAPS-Kubernetes GitHub repository and include:

• FPGA accelerator integration: Tooling to expose FPGA devices to Kubernetes workloads.
• GPU accelerator integration: Tooling to expose GPU devices to Kubernetes workloads.

SNAPS-Kubernetes is designed to keep pace with upstream Kubernetes releases as they stabilize, ensuring that edge deployments built on this tooling do not fall behind the Kubernetes release cadence.

Driver Management with SNAPS-Boot

One of the practical headaches of deploying hardware accelerators at scale is managing low-level device drivers across many physical nodes. At thousands — or potentially millions — of edge locations, manual driver installation is not viable.

CableLabs extended SNAPS-Boot, their OS deployment tooling, to include hooks for installing accelerator drivers during the initial server provisioning process. Example configurations for a selection of accelerators are included. The project is open to community contributions to expand support for additional hardware.

Avoiding ASIC Lock-in at the Edge

A recurring theme in Project Adrenaline is the importance of flexibility. Application-specific integrated circuits (ASICs) are highly optimized for a single function but cannot be reprogrammed when requirements change. At edge sites where hardware replacement is expensive and logistically complex, being locked into single-purpose ASICs is a significant operational risk.

FPGAs, by contrast, can be reprogrammed in the field as workload requirements evolve. Deploying flexible, programmable accelerator platforms reduces the time and cost of managing hardware across large-scale edge footprints and future-proofs the infrastructure against changing application demands.

Co-Innovation Partnership

The FPGA and GPU integration features described above were developed through a co-innovation partnership between CableLabs and Altran. The two organizations jointly developed the software and collaborated on proof-of-concept implementations.

Key Takeaways for Edge Architects

• FPGAs, GPUs, and CPUs each have distinct performance profiles; match the accelerator to the dominant operation type in your workload.
• Account for memory-copy overhead when designing multi-stage pipelines across different compute platforms.
• Driver lifecycle management is a first-class operational concern at edge scale — automate it from day one.
• Favor programmable accelerators (FPGAs, GPUs) over single-purpose ASICs to preserve flexibility at remote edge sites.
• Kubernetes can manage hardware accelerators effectively with the right device plugins and supporting tooling; projects like SNAPS-Kubernetes provide a starting point.
• OpenCL and similar cross-platform frameworks offer portability but may not meet the performance bar for the most latency-sensitive workloads.

Further Reading

For more context on the benefits and architecture of edge computing, refer to the CableLabs blog post Moving Beyond Cloud Computing to Edge Computing by Omkar Dharmadhikari (May 2019). For the open-source tooling, see the SNAPS-Kubernetes and SNAPS-Boot repositories on the CableLabs GitHub organization.

As businesses look to rebuild their technology infrastructure, many are adopting Kubernetes platforms, a move that has implications for marketing and marketing operation teams.
Amy Gesenhues on January 29, 2020 at 8:56 am
MORE
Chicory, a data platform that enables shoppable recipes, needed to rebuild its technology infrastructure. Because the company relies heavily on being able to access and utilize data in near real-time — analyzing millions of interactions on a daily basis with recipes, ingredients and food brands — it needed a solution that was fast, easy to deploy and could scale across all of its departments.

“We needed to create a solution that could process billions of data points close to real-time and that was easier to maintain for our team,” said Chicory’s Director of Engineering Asaf Klibansky, “We were dealing with issues that were mostly related to our infrastructure. It was clear that containerization would be a great solution to our problems as it is faster and lighter to deploy, scales easily and generally provides a smoother experience with few issues.”

The company had already implemented a Kubernetes containerization system for other smaller services, and at the time, was in the market for a new data warehouse. Knowing the benefits a Kubernetes platform would offer, Chicory began the process of moving its entire technology infrastructure to a Kubernetes system, migrating various microservices one-by-one.

You may be wondering why Chicory’s decision to adopt a Kubernetes platform is relevant to marketers. As a marketing or marketing operations professional, there’s a good chance the solutions you implement and manage are connected to your company’s broader technology infrastructure. As technology stacks become increasingly more difficult to manage and scale, many IT and engineering teams are turning to Kubernetes platforms. And while your department may not be the primary driver to implement a Kubernetes system, your data and marketing operations teams could potentially benefit from one.

What is Kubernetes?

Let’s begin with the basics. Kubernetes — also known as K8 — is an open-source container system for managing and scaling business applications. The open-source orchestration software allows technology teams to deploy and manage the microservices that make up a business’ technology stack. It allows for portability and scalability when deploying applications across on-premise or cloud environments. It takes less time to manage, decreases downtime, reduces IT costs and improves “time to market” speed.

The Microsoft Azure blog defines its Kubernetes solution as a way to help technology teams, “Orchestrate a cluster of virtual machines and schedule containers to run on those virtual machines based on their available compute resources and the resource requirements of each container.” (If this all sounds Greek to you, there’s a reason: the name Kubernetes has Greek origins, meaning helmsman or pilot.)

Google was the first company to open-source its Kubernetes initiative in 2014, and gave the platform its name.

A number of technology companies provide Kubernetes: Google, Microsoft Azure, SAP, Dell and others. The Linux Foundation, an initiative focused on open source software development, is the organization behind the resource site Kubernetes.io, which includes a list of certified solution providers. There are courses and a Certified Kubernetes Administrator exam for professionals who oversee Kubernetes platforms.

What are the implications for marketers?

A Kubernetes system can benefit marketing departments in a number of ways, from how a company manages its customer data to its ability to access actionable analytics and leverage marketing technology solutions.

“Our services are easier and faster to deploy, as well as scale,” said Chicory’s Klibansky, “Our codebase can be more easily maintained and we can provide more insights to our customers and clients in real-time, which is crucial in the martech sphere.”

Since migrating to the Kubernetes platform, Klibansky says his company has improved several aspects of its analytics stack and data reporting capabilities.

“We now offer our users more robust reports, such as visualizing our user interaction with recipes containing the ingredient ‘Fresh Basil’ across the country,” said Klibansky, “This has a huge effect on the business and the quality of service that we provide to our clients.”

Who implements and manages the Kubernetes platform?

Because Kubernetes applies to a company’s entire technology stack across multiple business units, the primary stakeholders driving such a project are usually outside of marketing. When Chicory moved to a Kubernetes platform, the initiative required cross-departmental coordination.

“Serving as a conduit between our account management and marketing teams, our co-founder Joey Petracca, actually stepped in on the project as the lead product manager,” said Klibansky, “The migration was so impactful to the core of our business that we needed a high-level stakeholder who could synthesize all of the teams’ needs and communicate that back to our engineering team.”

While marketing may not lead the Kubernetes charge, it should be involved. One of the biggest challenges Chicory faced with rebuilding its tech infrastructure on the Kubernetes platform involved a new business intelligence tool it was implementing — a solution that directly impacted the company’s data analytics capabilities.

“The reports had to match the previous reporting, which were slightly different in shape due to the new BI tool requirements,” said Klibansky, “We had to make modifications over and over again. We also had to rewrite our data pipelines using a new framework, Dataflow, which took some getting used to.”

In the end, Chicory’s choice to implement Kubernetes to rearchitect its tech ecosystem delivered stability and flexibility, which Klibansky said was paramount for managing the volume of data contained in Chicory’s systems.

Should my company consider Kubernetes?

This isn’t necessarily a question for the marketing team to answer, but because marketing is often the team managing and analyzing various data sets, marketers may be more likely to notice instances where Kubernetes could benefit the entire organization.

Is your company’s technology stack outdated and difficult to manage? Does it take longer than necessary to update systems? How scalable is your company’s technology? Is there a mix of technology — both on-premise software applications and cloud solutions? These are all questions that point to the benefits of adopting a Kubernetes platform.

“The move to use containerization along with Kubernetes, BigQuery and Dataflow had a major effect on the time that we now spend deploying and debugging our solutions,” said Klibansky, “It also affects the speed at which we can introduce changes and reduce the number of issues that we have to address on a daily basis. The data is available to us almost immediately and we are able to provide more robust solutions that involve real-time data as well as richer reporting for our clients.”

What Is DevOps?

DevOps is a combination of “development” and “operations.” It is built on four core pillars: culture, tools, collaboration, and practices. Rather than having development and operations teams work in isolation, DevOps brings them together in a continuous, shared workflow that spans the entire software development lifecycle (SDLC).

The outcomes of a well-executed DevOps model include faster release cycles, quicker resolution of critical issues, and higher confidence in deployed software. Crucially, quality becomes a shared responsibility across the entire team—not just the QA department.

Why QA Matters More in a DevOps Model

Traditional waterfall development treats QA as a distinct phase that follows development. In a DevOps or Agile model, that separation disappears. Software must be continuously integrated, tested, and deployed—often multiple times per day. This means quality checking must happen continuously, not as a final gate.

Modern applications also need to function across a wide range of platforms: multiple browsers, operating systems, and device types. Without a structured, automated QA strategy embedded in the pipeline, defects surface late, cost more to fix, and erode user trust.

Key QA Strategies for DevOps Implementation

1. Test Automation

Manual testing cannot keep pace with continuous delivery pipelines. Automated testing is the foundation of DevOps QA. By automating regression tests, integration tests, and smoke tests, teams can detect defects early in the SDLC—before they propagate downstream.

Test automation tools can be open-source (such as Selenium, Playwright, or Jest) or commercial. The right choice depends on the team’s existing skills, the technology stack, and the testing scope required.

2. Merging QA Into the Development Team

In a DevOps environment, QA engineers are not a separate silo—they are integrated into cross-functional delivery teams. This structure ensures that identifying and fixing defects is a shared responsibility, not something handed off at the end of a sprint. When QA engineers collaborate with developers from the start, quality is built in rather than tested in.

3. Defining Metrics Early

DevOps QA is driven by measurable outcomes. Key metrics should be defined at the beginning of the project and tracked continuously. Common examples include:

• Defect escape rate – the percentage of bugs that reach production
• Mean time to detect (MTTD) – how quickly defects are identified after introduction
• Test coverage – the proportion of code exercised by automated tests
• Build success rate – the ratio of successful CI builds to total builds triggered

QA engineers play a key role in establishing these metrics and embedding them into team workflows so that quality goals remain visible throughout development.

4. Service Virtualization

Testing software across every target device, browser, and operating system in a physical lab is impractical. Service virtualization allows QA teams to emulate the behavior of dependent systems and environments—making it possible to test under realistic conditions without requiring all real dependencies to be available simultaneously.

Virtualization also helps remove bottlenecks caused by shared test environments and reduces the cost of maintaining complex infrastructure for testing purposes.

5. Choosing the Right Testing Tools

Tool selection is a strategic decision. The ideal test automation tool for a DevOps team should:

• Support the team’s primary programming language(s)
• Integrate with the existing CI/CD pipeline (e.g., Jenkins, GitHub Actions, GitLab CI)
• Enable cross-browser and cross-platform test execution
• Produce clear, actionable test reports
• Be maintainable as the codebase evolves

Forcing a team to adopt a tool they are unfamiliar with creates friction and slows delivery. Team expertise should be weighted heavily in the selection process.

6. Continuous Integration and Continuous Deployment (CI/CD)

CI/CD is both the enabler and the output of a mature DevOps QA strategy. In a CI/CD pipeline:

• Continuous Integration (CI) ensures that every code change is automatically built, tested, and validated against the existing codebase. Regression tests and version control are central to this process.
• Continuous Deployment (CD) automates the release of validated builds to production or staging environments, allowing teams to deliver new features rapidly and respond to user feedback in near real time.

Together, CI and CD reduce the risk of large, infrequent deployments and enable faster recovery from failures when they do occur.

Conclusion

In a DevOps model, QA is not an afterthought—it is a continuous, collaborative discipline embedded across every stage of the SDLC. Getting QA fundamentals right from the outset, automating testing, defining clear metrics, and selecting tools that fit the team’s capabilities are all prerequisites for a DevOps implementation that delivers real business value.

As software quality increasingly determines whether an enterprise succeeds or fails in the market, the alignment between QA and DevOps practices is no longer optional—it is a competitive necessity.

NetApp Brings Kubernetes Automation to Its HCI Platform

NetApp announced the general availability of NetApp Kubernetes Service on NetApp HCI, a service that automates the deployment and lifecycle management of Kubernetes clusters directly within the NetApp hyper-converged infrastructure (HCI) platform. The announcement extended NetApp’s broader Cloud Data Services portfolio to on-premises HCI deployments.

According to Ingo Fuchs, chief technologist for cloud and DevOps at NetApp at the time, the service includes an application orchestration tool and access to a NetApp-curated application marketplace, giving platform teams a streamlined path from bare HCI hardware to running containerized workloads.

What Was Included in the Release

• NetApp Kubernetes Service on NetApp HCI: Automated Kubernetes cluster provisioning and management on-premises.
• Cloud Volumes on NetApp HCI: Persistent, cloud-native storage volumes made available across major public cloud providers, enabling a consistent storage layer for hybrid workloads.
• NetApp-curated application marketplace: Pre-validated application bundles accessible from within the Kubernetes service.

The combination of these services was positioned as the foundation of a NetApp Data Fabric — a unified approach to managing data across on-premises and public cloud environments without treating each environment as a silo.

The Role of CSI and Persistent Storage

A key theme in NetApp’s messaging was the maturation of the Container Storage Interface (CSI), the standardized API that allows Kubernetes to interact with storage providers in a vendor-neutral way. As CSI adoption grew, it became progressively easier to attach enterprise-grade persistent storage to Kubernetes workloads without writing platform-specific integrations.

This matters because the first generation of containerized applications was predominantly stateless — they could be destroyed and rescheduled without needing to persist data. The subsequent wave of containerized workloads, however, increasingly included stateful applications such as databases, message queues, and analytics engines that require reliable, performant persistent storage. HCI platforms, which tightly couple compute and storage resources, are a natural fit for these workloads.

Trident: Open Source Persistent Volume Orchestration

NetApp’s open source project Trident underpins much of this storage integration. Trident is a dynamic storage provisioner for Kubernetes that integrates natively with the Persistent Volume (PV) subsystem. It allows Kubernetes workloads to claim storage from NetApp backends — including ONTAP, SolidFire, and Cloud Volumes — using standard Kubernetes constructs such as PersistentVolumeClaim objects and StorageClass definitions.

By open-sourcing Trident, NetApp positioned itself as a contributor to the Kubernetes ecosystem rather than a closed-stack vendor, making it easier for DevOps and platform engineering teams to adopt NetApp storage without abandoning Kubernetes-native workflows.

HCI, FlexPod, and the On-Premises Angle

While Kubernetes itself is infrastructure-agnostic, the HCI model — where compute, networking, and storage are delivered as a single, software-defined appliance — aligns well with the Kubernetes operational model. Both lean on abstraction and software-defined resource management.

For on-premises deployments that needed validated reference architectures, NetApp offered FlexPod, a jointly engineered platform combining NetApp storage with Cisco’s Unified Compute System (UCS). The HCI-based Cloud Data Services extended this on-premises footprint to public clouds, where HCI architectures are already the dominant infrastructure pattern.

Hybrid Cloud Data Management: Still an Open Question

Even as of this 2019 announcement, the market for unified hybrid cloud data management was still taking shape. Most enterprise organizations were running workloads across multiple clouds, but those environments were largely isolated from one another — independent data planes, separate storage accounts, and minimal cross-cloud data mobility.

The longer-term concern driving NetApp’s strategy was vendor lock-in. As organizations grew more dependent on specific cloud providers’ proprietary storage services, migrating data or running applications across clouds became progressively harder. A common data fabric that abstracts storage across environments — on-premises HCI, AWS, Azure, GCP — was the architectural answer NetApp was proposing.

What remained unclear at the time was who would drive that convergence inside enterprises: traditional storage and infrastructure teams familiar with NetApp’s existing portfolio, or DevOps and platform engineering teams who were architecting container platforms from scratch and had different priorities around automation, self-service, and GitOps-style workflows.

Key Takeaways for DevOps and Platform Engineers

• Persistent storage for Kubernetes is not optional once stateful workloads enter the picture. Plan your StorageClass and CSI driver strategy early.
• Trident provides a Kubernetes-native interface to NetApp storage backends and is worth evaluating if your organization already uses NetApp infrastructure.
• HCI platforms can simplify Day 2 Kubernetes operations by providing tightly integrated compute and storage with unified management planes.
• Data portability across clouds requires a deliberate architecture decision — cloud-native storage services are convenient but can create migration friction at scale.
• CSI standardization is the correct abstraction layer to bet on; avoid storage integrations that bypass CSI in favor of vendor-specific volume plugins (now deprecated in Kubernetes).