The composable stack - Veritas: Building an ephemeral-persistent balance

This is a guest post by Anthony Cusimano in his role as solutions evangelist at Veritas Technologies — a company known for its work in cloud storage, backup & recovery services, data management and information governance technologies.

Download this free guide

A Computer Weekly Buyers Guide to IoT

In these uncertain times, making solid predictions for the year ahead looks like a definition of a mug's game. While this has been the fuel for the fire for the boom in applications such as video conferencing as used to support remote working, the same really can be said for the internet of things (IoT). Download this E-Guide to find out what enterprises need to know about IoT.

• Corporate Email Address:
• • I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.
• • I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Cusimano argues that the ‘easiest’ technology projects to pitch for board approval are typically refresh initiatives where a trusted supplier with an existing relationship has agreed to provide ten percent more stuff for ten percent less money.  

So, therefore, (given the focus, content and context of our current composable ephemeral IT stack series) winning board approval to migrate anything to a completely new architecture, like the composable stack, is always going to be a challenge. 

He suggests that when the IT team pushing for this move communicate these notions to the board (typically via the CIO) and explain that the company’s computing instances will be ephemeral, the less tech-savvy board members may baulk at the idea completely.

Cusimano writes as follows…

Before pitching a shift to containerisation and composable IT, it’s good to lay out clearly what will be ephemeral and what will be persistent.  

To the tech ingenues and innocents on the board, this will be far from obvious. It should then be a case of highlighting the business benefits of the ephemeral composable stack, on one side of the argument, whilst reassuring people of the dependability of the persistent elements.

An ephemeral-persistent balance

In many senses, the ephemeral benefits section is easy: scalability, portability, ease of development and so on.  But, as ever, it’s critical to translate these into business terms: lower up-front costs, ability to migrate to more cost-effective environments, earlier ROI, et cetera. The team needs to anticipate concerns and pre-empt them with a good story about persistency and protection.

Making the reach of the project understandable can be the first step on the road to buy-in.

Ephemeral composable architectures are ideal for processes that have defined and limited durations. For example, in the banking sector, making a transactional payment. On the other hand, using ephemeral services to support static datasets, such as databases, is conventionally inadvisable since they are not engineered to continuously live, oftentimes shutting down prematurely or ending without warning, which can lead to faults and failures in more traditional static data application types. In our banking example, that might be the customer account records. The board will need to understand that these kinds of workloads will either remain in traditional architectures or in volumes with persistent storage.

What is key is making sure that everyone understands that, whilst the stack is ephemeral and composable, the data is not.  The data will remain stored in a reliable compliant fashion.

Part of that reliability and compliance is also going to involve protection. To a layperson, protecting data in an ephemeral container sounds hard. Since ransomware became a boardroom issue, leaders have had it rammed home to them that every workload and data set in their business needs to be located and linked to a protection copy. The concept of spinning up containers to process data first here, then there, then somewhere else will probably sound risky. 

How are they to be mapped and protected? How do you restore things if you need to?

Spinning up a sidecar

Of course, data protection for containers has become a lot more sophisticated in recent years and the days of spinning up a sidecar to each container in order to protect it are thankfully long gone. Being able to highlight to the board that proven data protection solutions can extend their reach from traditional on-premises applications to containerised workloads in the cloud, should help to overcome the concerns that leaders might raise.

This idea of ‘protection everywhere’ can help to give those board members confidence not only to green light early projects involving the ephemeral composable stack but, ultimately, to allow its use more pervasively across IT.  In most cases, the board cares more about what the IT enables rather than how it does it – so long as it doesn’t create more risk. 

If we can convince leaders that we’ve minimised that risk, buy-in to the ephemeral composable stack should be close at hand.