Following their introduction on Microsoft Azure last year, native NetApp Cloud Volumes are to be made available through Google Cloud Platform. NetApp now offers Cloud Volumes in some form on the three major (Western) cloud providers, AWS, Azure and GCP. How should we view this, especially in respect of how cloud services are evolving?
A couple of years ago I wrote a blog post comparing AWS Elastic File Service with traditional enterprise file services like those from NetApp. For reasons I won’t go into, the blog post was published then taken down (not from this site) at the request of AWS. At the time, the reason for my comparison was to highlight that some solutions (like NetApp Private Storage and Zadara VPSA) could provide a viable alternative to the native features in the cloud – especially storage.
- NetApp embraces cloud for future business growth
- Is NetApp Becoming a Service Provider?
- Azure Enterprise NFS by NetApp – Initial Thoughts
At the time, EFS didn’t have mature snapshots, integrated security or comprehensive reporting. For enterprises used to mature services, this was likely to be a problem.
NetApp & Cloud
Fast forward a little to October 2017 when NetApp announced Enterprise NFS, now Cloud Volumes for Azure. ONTAP is also available in AWS, although as a marketplace offering, rather than natively. Now we have GCP added to the native list. Why does this matter?
- Integration – the GCP and Azure implementations are native. This means they can be accessed through cloud APIs and will integrate with other native cloud services like security and networking. This isn’t an add-on.
- Maturity – NetApp ONTAP has mature features that enterprises have come to expect. In the public cloud this should be no different. One example here is the ability to access the same data via NFS or SMB. However, we could also include snapshot and replication features.
- Performance – NetApp has demonstrated that Cloud Volumes are much faster than existing file services. In the future, with QoS, this performance should be a selectable feature, allowing any performance level to be selected, not just one or two.
Having a mature file service means that data on a file platform can be used for advanced workloads like analytics or databases. This is much more than simple file sharing.
However, the biggest benefit for me is the mobility feature. At some point, there’s no reason data on-premises can’t be replicated into the public cloud. Native replication is much more efficient than file-based replication. Think of how SnapMirror keeps track of changes and only synchronises block-level differences for changed data. If you’re looking to replicate entire databases or large volumes of unstructured data that has large files, being able to track updates to the 4K block level is a big advantage as it reduces the amount of data being shipped across the network.
So how is Cloud Volumes implemented? In conversation with executives at the recent NetApp Analyst’s Day event, Cloud Infrastructure BU GM Anthony Lye explained that Cloud Volumes runs on a version of ONTAP directly taken from standard builds, with refreshes rolled out monthly. Customers get the benefits of new features almost immediately, with no management of the infrastructure. The Azure interface (both GUI and API) act as middleware to the ONTAP API, so all calls to create storage resources are managed through existing API calls. Note that this isn’t the case with AWS, where the storage is implemented in a cloud instance running ONTAP.
The Architect’s View
Mature storage solutions will be both a big draw to the enterprise and a selling point for cloud providers. Data mobility will be a unique route for customers to natively move data into public cloud. I can envisage scenarios where data replicas are refreshed hourly and use the power of GCP analytics, rather than running this function on-premises. This is classic hybrid computing.
What about other functionality? NetApp will neither confirm or deny that block storage could be an option. It’s certainly technically feasible, but unlikely to work on boot images. But it could conceivably be practical for data volumes, sharing volumes between instances and to connect to containers.
Comments are always welcome; please read our Comments Policy. If you have any related links of interest, please feel free to add them as a comment for consideration.
Copyright (c) 2007-2018 – Post #Fe8A – Chris M Evans, first published on https://blog.architecting.it, do not reproduce without permission.