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.
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.
Cusimano: Ransomware became a boardroom issue… so ephemeral buy-in needs lockdown controls if it is to fly.
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.