Why CEOs should care about ‘cloud native’ – and what it really means for business (Guest blog from OVHcloud)

Author: Emma Dennard, VP Northern Europe, OVHcloud

According to Statista, although only 16% of organisations are using container technologies today, over two-thirds (70%) believe that they will play a strategic role in their organisation within the next 18 months.

If you read that twice, or your first thought was to wonder how Tupperware could possibly influence company strategy, then read on.

Containers, and containerisation technologies such as Kubernetes (or K8s) and Docker are a part of what we call the cloud native approach. A system is ‘cloud native’ when it mirrors the strengths of cloud computing, for example, using its scale, agility and high availability. Cloud native apps tend to use what we call microservices. If you imagine that a ‘conventional’ application is a toy house, an application made of microservices is built using LEGO: each brick can be removed and replaced without interfering with other parts of the structure. With microservices, each part of the application can be upgraded or changed without interrupting the rest of the application’s functionality.

That’s the precis, but to really understand the importance of containers and cloud native, we should first take a step back and look at where cloud came from.

A Brief History of Cloud

Cloud’s earliest roots are in the mainframe industry, back in the 1950s, when room-size computers allowed multiple users to connect and carry out routine operations. It wasn’t feasible or cost-effective for each user to have their own mainframe, and the first ‘real’ personal computer wasn’t invented until the mid-seventies, so the mainframe ruled supreme for almost three decades.

In the meantime, the roots of the internet were born with ARPANET in the US, and later on, the ‘client-server’ model, which allowed users to access resources more efficiently across a network. Curiously, although virtualisation – the technology that allows server resources to be ‘cut up’ into chunks – was technically available from 1964 in IBM’s CP-40 system for mainframes, it wasn’t until the foundation of VMware in 1998 that the technology really took steps forward, and we started to see ‘true’ cloud systems in the early noughties, including the likes of Salesforce and Netflix.

In the 2010s, architects began to re-think systems like virtualisation.

Without getting into too much depth, virtualisation cuts up a server and splits its resources, so that an organisation can make use of ‘parts’ of a server without needing the whole thing. This flexibility also means that if a company requires more of the server (or less), virtualisation technologies can dynamically change the resources allocated to a virtual machine within minutes – and without needing physical access to the actual hardware.

Virtualisation and Containerisation

A key difference between virtualisation and containers is how they handle the operating system (OS). In a traditional virtual machine, each ‘instance’ includes its own OS. This means that organisations can use different OS’s on different VMs for different purposes – some might run better on Windows and others better on open source operating systems like Linux. However, the inclusion of the OS can not only increase cost (because each OS requires its own license) but also slow the virtual machine down, because the resources allocated to the VM have to manage not just the application but also the OS itself.

In a containerised approach, all containers sit on top of an orchestration / virtualisation layer that in turn sits on top of the host operating system, rather than being included ‘inside’ it. Containers are simply small, virtualised bubbles containing application segments, as well as the ‘libraries’ of resources that the app segment is dependent on. This independence from an OS often makes containers faster, and their ‘all-inclusive’-ness means that they can be copied and rolled out to other machines or even other countries very quickly.

Welcome to Cloud Native

There are advantages and disadvantages to each approach, as well as to what we call ‘monolithic’ applications, which is the traditional way of building apps as one single unit of functionality. However, we generally refer to technologies that were developed in the mature cloud era, for the cloud era, as cloud native. Of course, you can run technologies like Kubernetes locally, but they were designed for a ‘cloud first’ approach.

That also brings us back to considerations of why organisations should look at cloud and a cloud-native approach first, rather than buying outright. Again, without getting into the technical details, the main benefits include:

• Financial Flexibility: Cloud provides on-demand computing when you need it, if you need it. It’s like renting rather than buying and uses OpEx rather than CapEx.
• Business Agility. If you’re renting computing power, and need to test a new AI app, you can do so within minutes, test it, pay for what you use, and then stop paying. If you need more capacity because demand has gone through the roof, cloud can provide that at the touch of a button.
• Superior Customer Experience: With cloud, you can release new functionality faster because you have access to superior equipment on-demand, rather than waiting to procure hardware. Using containers also allows you to develop specific ‘units’ of functionality fast, without interfering with the rest of an application
• Reliability: Containerised systems like Kubernetes have been built with ‘self-healing’ capabilities – they have functionality which is a little like the body knowing what it ‘should’ be like, and the ability to restore and heal that functionality when it’s damaged. This makes apps, and by extension, business operations, more resilient.
• Less Downtime: Container and virtualised technologies allow you to chop up applications further into their functionality and host each one in a separate environment. Again, this ease of maintenance means less downtime and ultimately, happier customers.

There are many pros and cons to using containers and virtualisation technologies, and it’s important that leaders are aware of the differences at a high level. At the same time, it’s not necessary to understand all the nuts-and-bolts, but that’s no different to leadership in general – you wouldn’t expect a CEO to understand the ins and outs of the payroll system, but you would expect them to know that people should get paid on time!

Ultimately, cloud native – and cloud by default – approaches are drivers of significant agility in today’s business world, and although the technology world seems to be moving ever-faster, leaders and businesses that have a strategic understanding of how systems like cloud native apps work will be at a considerable advantage to their peers.