Abstraction matters! There is a big difference between storage that operates on volumes vs VMs. A recent competitor's blog on vRO (using volumes) inspired this explanation of how Tintri's VM-level operations simplifies automation.
The Tintri Enterprise Cloud platform operates directly on VMs, vDisks, and containers, making it much easier to automate value-added storage services and offer them through self-service. Kieran touched on this in his blog post last week. In this post, I want to dig into Tintri’s automation and self-service advantages a little further.
In the cloud, performing tasks at the LUN or volume-level becomes even less relevant; the ability to automate at the right granularity is key. In a traditional IT environment with conventional storage, a storage admin decides where to place VMs based on their requirements as a manual process. That doesn’t work in the cloud since VMs belong to cloud users. VMs, containers, and applications come and go based on self-service requests. The manual process—already far from optimal—is no longer an option when everything must be automated.
Cloud automation is often driven by orchestrators. While these can be very powerful, they rely on the underlying infrastructure's capabilities for their worklfows. An example is vRealize Orchestrator (vRO), which I will use later as an example.
An orchestrator that applies automation on top of a Tintri infrastructure can perform tasks at the VM or vDisk level. As a result, they can be easily mapped to cloud services for use by end users. These value-added tasks cover advanced features for data synchronization, data protection, and Quality of Service (QoS).
If you look at the vRealize automation tasks available from Tintri’s competitors, you’ll see that all the operations are at the volume, datastore, or array level--tasks that are relevant for a storage admin--and require admin expertise to use.
These tasks can’t be easily mapped to services you can offer to end users. Here’s what happens when you try to map orchestrator tasks for volume- or LUN-based storage into an end-to-end automation for protection policies.
The above process flow shows what should be a simple task, adding a snapshot schedule and replication to a VM. In this case, you not only have to make sure that a LUN or volume with the correct schedule exists, but you must make sure it has enough available capacity and performance. If not, a new LUN or volume has to be created. And similar steps must be performed on the DR side. Because this workflow is complex to create and maintain, cloud offerings usually don’t include these types of advanced VM-level features.
For comparison, Tintri includes tasks in its vRO plugin that apply a snapshot schedule and replication to the VM itself, eliminating all unnecessary complexity. Workflows are simple and reliable so you can include value-added storage services as part of your self-service offerings. When creating VMs, for example, you can easily create a workflow to allow users to specify the synchronization, QoS, and replication settings they want. It's fair to assume that's why Tintri has the most and the highest ratings in the VMware Solution Exchange.
If you look at service catalogs from our competitors, you’ll see that the tasks they offer are at the admin level and don’t really belong in a self-service portal accessible to end users.
The ability to deliver storage automation and self-service as part of an enterprise cloud is based on the below three key pillars. Other storage vendors may have one or two of these, but you need all three to truly enable cloud storage services powered by an intelligent infrastructure.
Unique control with VM-level actions for infrastructure functions including snapshots, replication and QoS make protection and performance certain in production, and accelerate test and development cycles.