Information technology is in the midst of a tectonic shift. Almost everything about how organisations deliver and build applications is changing in what has become known as digital transformation.
That digital transformation can be characterised as having three main elements. Firstly, it sees the digital enablement of processes within organisations and outwards to customers and partners. Secondly, it is heavily cloud-influenced by the literal use of cloud resources or cloud-like operating models. Thirdly, how application development takes place is changing too, to a continuous integration and deployment model allowing for frequent iterative changes.
At the pinnacle of these three elements is containerisation, which brings together the ability to build applications on a continuous development model that are supremely self-contained, highly scalable, and portable while being granular in terms of the services components they encapsulate.
It’s no exaggeration to say that containerised applications — deployed and managed via an orchestration platform like Kubernetes — will play a pivotal role in the next decade’s IT evolution. According to Gartner, 85 per cent of organisations will run containers in production by 2025, up from 35 per cent in 2019.
Containers can be running at a much higher density than traditional virtual workloads, meaning fewer servers are required. This knock-on effect of reducing licensing costs and, importantly, power requirements. For these reasons, we’re seeing containerisation underpin cost reduction initiatives and wider business cases, with organisations targeting 25 per cent to 40 per cent of apps as a common starting point.
But what about storage, data protection, backups, snapshots, replication, HA, and disaster recovery? These are vital to an organisation’s application infrastructure but can challenge containerised operations. Before we look at ways to resolve that, let’s examine why containers are so important and how they work.
The agility of containerised application deployment
An organisation’s core business is centred on frequent launches of many new products with rapid peaks in demand and accompanying analytics requirements. It might be a ticketing operation, for example, with sudden and massive spikes in sales. Traditionally-built applications on a three-tier (client-server-database) architecture would be slow to deploy, not scale well and creak under high demand levels. Containers are conceived to deal with exactly such a situation.
That’s because containers encapsulate the various components of an application — meaning many such microservices are reusable as new applications are developed — and can rapidly multiply to meet the demands of scaling. In addition, containers hold all the API connectivity to those they depend upon and can be ported to numerous operating environments. So, for example, that sudden rapid spike in event ticket demand could be accommodated by rapid reproduction of interconnected containerised service instances and bursting multiple data centres in the public cloud.
The technical underpinnings of containers — much simplified — are that it is a form of virtualisation. Unlike virtual servers, they run directly on the host operating system without an intervening hypervisor. That means containers are a much more granular, lightweight virtual machine that usually provides discrete components of the application, connected by code (i.e., APIs).
While there’s no hypervisor and no consequent overhead, containers benefit from an orchestration layer provided by tools like Kubernetes, which organises one or more running containers — each with their code, runtime, dependencies, and resource calls — into pods. The intelligence to run pods sits above them in one or more Kubernetes clusters.
The Kubernetes storage and backup challenge
One of the biggest challenges to overcome with Kubernetes is storage and data protection. The issue’s roots go back to the origin of containers originally intended to run on a developers’ laptop as a temporary instance and for which data storage only persisted as long as the container executed.
Since containers became a mainstream enterprise approach to application development, however, that wouldn’t do. Most enterprise organisations’ applications are stateful, creating, interacting with, and storing data.
Orchestration above the orchestrator
So, customers that want to deploy containers with enterprise-class storage and data protection need to be looking at a newly-emerging set of products.
This is the container storage management platform from which they can run Kubernetes and provision and manage its storage and data protection needs.
What should customers look for in this product category?
A key consideration is that any Kubernetes storage product should be container-native. That means an application’s storage requirements are deployed as containerised microservices in which provisioning, connectivity, and performance requirements are written as code, with all the dynamism and agility that implies. That’s in contrast to other methods – such as Container Storage Interface (CSI), which relies on hard-coded drivers for storage allocated to containers.
Meanwhile, a software-defined container-native Kubernetes storage platform should provide access to block, file, and object storage and be able to use cloud storage too. In doing so, it should emulate the core characteristics and benefits of containerisation and Kubernetes. That means the data should be as portable as the containerised app, be managed via a common control plane, and scale and heal autonomously.
Regarding data protection, such a product should provide all the key methods of securing data, including backups and snapshots, synchronous and asynchronous replication, and migration functionality. Again, this should allow for the cloud as a source or target in these operations.
To handle the scalability of Kubernetes environments, the product should be able to manage clusters, nodes, and containers that run to hundreds, thousands, and hundreds of thousands, respectively, with manageable storage capacity in the tens of petabytes.
Lastly, it should be intelligent, with rules-based automated management that, for example, creates, replicates, and deletes containers as determined by pre-set monitoring triggers and provisions and resizes storage as required.
Once you find and implement a solution that ticks all of these boxes, you’ll soon see why 85 per cent of organisations will be relying on containers by 2025 and wonder why you didn’t take the leap sooner.
If you liked reading this, you might like our other stories
Five SD-WAN Trends In The Post COVID Era
Full Stack Observability: Subtle Yet Effective
