What’s the difference between Cloud Adjacency and Native Cloud services? What considerations surface based on each approach? It’s critical to understand which method is best for your workload. For this blog post, we’ll focus on AWS FSx for ONTAP, a Network File System (NFS) service AWS announced in 2021 and discussed in some detail during Cloud Field Day 13.
Check out the CTO Advisor Interviews with AWS Cloud about FSx for ONTAP.
The History of NFS in the Enterprise
NFS as a protocol and service dates back to SUN Solaris and 1984. The protocol became the backbone for network-based enterprise applications for decades. Everything from analytics applications to ERP leverages NFS’ ability to share data across nodes. To say it’s ubiquitous is an understatement.
As network-attached storage adoption expanded, competing solutions appeared from Netware File System to Microsoft’s Server Message Block (SMB) protocol. NetApp became a network-attached storage (NAS) leader with the NetApp Filer. The NetApp storage array used an operating system branded ONTAP. ONTAP enabled a multitude of value adds on top of NFS. ONTAP enabled RAID data protection, replication, data de-duplication, compression, snapshot technology, and a long list of services without application developers ever needing to know anything about the storage system. Instead, developers developed applications using the NFS protocol and received the benefits of ONTAP.
Modern Cloud and NFS
AWS’ oldest service is Simple Storage Service (S3). Unlike NFS, S3 is an Object storage technology. NFS uses a multi-level directory-based file system to organize and store data in files logically. S3 uses a flat directly to store data in an object. S3 offers many data services from replication and API-centric access.
To take advantage of S3 object storage, the developer must re-write applications for the S3 API. If you are developing in a greenfield environment, there is little to no friction in adopting S3. However, like most customers I talk to, you may have everything from Oracle Databases to petabytes of unstructured data sitting on an NFS share. The question is, how do you transition those applications to the public cloud? In many cases, you don’t.
Yes, you can build an NFS server based on Elastic Block Storage (EBS) on AWS Elastic Compute (EC2) instances. However, it’s not very appealing for technical, operational, and financial reasons. Remember how ONTAP specifically saved development trouble by enabling replication without changes to the application? Well, there are thousands of customers relying on ONTAP to replicate data to their disaster recovery (DR) environment. Unfortunately, recreating the capability with a home-grown storage solution on EC2 isn’t the way.
FSx for ONTAP
Enter FSx for ONTAP. AWS has listened to its customers. AWS has created a first-party NFS service based on NetApp ONTAP. As I understand the relationship, AWS OEM’s the ONTAP software. Any time a customer wants NFS with the extensibility of ONTAP, AWS deploys a software-based ONTAP system in a customer’s virtual private cloud (VPC).
According to the NetApp presentation, a customer can deploy an entire ONTAP storage array within ½ hour. For comparison, we ordered a competing system for our data center in the CTO Advisor Hybrid Infrastructure (CTOAHI). Procurement took 4-weeks from the time we issued a purchase order (PO) to when the system arrived on our dock. Our team spent the weekend racking, stacking, and cabling the physical storage array. We are anticipating another week for configuration and troubleshooting.
If you want to move your SAP landscapes to the public cloud, I can see the appeal of FSx for ONTAP.
Native Cloud vs. Cloud Adjacent
You may ask, what’s so special about FSx for Ontap vs. one of many NFS services we can find in the AWS Marketplace. For example, Pure Storage, also presented at Cloud Field Day 13, offers a storage array appliance in the AWS marketplace. It’s the concept that FSx for ONTAP is a first-class service within the AWS control plane. That means FSx for ONTAP is on the same plane as an S3 or EBS.
We called out the importance of this fact when we compared VMware cloud solutions. VMware Cloud for AWS is an example of a cloud adjacent service. The service runs on AWS infrastructure akin to bare metal EC2. However, If I wanted to sign up for the service, I must go to https://cloud.vmware.com. From a vendor relationship perspective, I must manage two separate vendors.
Another example, EC2 is fully integrated into AWS’ Identity and Access Management (IAM) service. An EC2 instance is a unique object within the AWS control plane. A customer in one VPC can assign a role to another VPC without setting up any federation between AWS accounts. Or, more likely, a developer can configure an EC2 with a role that allows the EC2 instance to create and execute Lambda functions.
While a developer could achieve similar outcomes within a VMware Cloud on AWS VM instance, they must perform many more steps as a VMware Cloud on AWS VM is not an object type within IAM. VMware Cloud on AWS is cloud adjacent vs. Cloud Native.
Which is better?
The obvious question is, which is the better design? I believe AWS’s Adrian De Luca said it best; it depends on the workload. We can extend the concept to FSx for ONTAP. According to De Luca, FSx for ONTAP integrates with services such as Cloudwatch. Therefore, a developer could execute LAMBDA functions off Cloudwatch events as they would with any other service that combines with Cloudwatch.
Let’s get back to the VMware Cloud on AWS as an alternative workload example. If I’m managing a hybrid VMware environment, vCenter, or more specifically, the SDDC Manager is my control plane. I’m more concerned about creating and controlling objects across data center control planes. Take the ability to vMotion a VM from VMware Cloud on AWS back to my data center infrastructure. One, AWS doesn’t have the concept of vMotion for EC2 instances. Secondly, without the AWS control plane (AWS Outpost), there’s little value in having an EC2 instance in my data center.
Customers can leverage cloud adjacent services with native cloud services to fill the design shortcomings of each product type. For example, AWS released a reference architecture for leveraging FSx for ONTAP with VMware Cloud for AWS. Storage expansion is one of the pain points of VMware Cloud for AWS. VMware’s service leverages VSAN as the storage underlay. As a result, it becomes cost-prohibitive to create VM storage that reaches hundreds of terabytes. FSx for ONTAP allows an administrator to present Storage to VMs hosted in VMware Cloud on AWS via iSCSI, SMB, and of course NFS.
The inverse is true for EC2 and VMware Cloud on AWS VMs. If you have an operating model that leverages the oversubscription of the underlay, EC2 can become cost-prohibitive. Therefore, VMware Cloud on AWS enables potential cost savings for an extensive enough infrastructure while keeping a familiar operating model across public cloud providers.
So, if you are all in on your favorite cloud provider and don’t expect to move, native cloud services increase speed to value. However, if you want to avoid lock-in or need a control plane that spans multiple infrastructures, cloud adjacent services are better.