AWS just announced its latest version of the Snowball — a hardware appliance used to migrate data from on-prem locations to the device and then on to AWS, where it’s transferred to S3.
Except this version is different — it has computing on board. What? AWS is shipping an on-prem computing device? Predictably, a lot of pundits viewed this as AWS getting into the on-premise computing game. Many of them have long proclaimed that AWS would inevitably have to start offering hybrid computing via on-prem capabilities, because, well, enterprise.
So they greeted Snowball Edge with EC2 as proof that they were right all along, and that AWS was finally getting some sense into its head about the real way computing needs to be done.
That’s the wrong way to view this announcement. Frankly, a Snowball Edge with EC2 is a pretty lousy computing device — heavy, delivered in a proprietary form factor, and much more expensive than alternative solutions.
Instead, I see Snowball Edge with EC2 as an AWS initiative designed to reduce the friction of migrating data into AWS with the ultimate goal of enabling applications to migrate to AWS, not a way to run AWS applications on-prem. In other words, this new Snowball variant isn’t about processing data on-prem, it’s about making Snowball a better on-ramp to AWS.
Why do I say this? Let’s look at the details of Snowball Edge with EC2.
It delivers a Snowball device with EC2 AMIs pre-installed. The AMIs themselves are defined in AWS and then placed on the device by AWS.
Once the Snowball device is installed at the customer location, users can launch EC2 instances that run in the Snowball; those instances offer network access, which means the instance software can be used as an ETL appliance, facilitating the transfer of data onto the Snowball.
The Snowball AMIs can have an IAM role associated with them during creation; this allows the ETL software to interact with Snowball storage via the AWS SDK/CLI.
So why is this new Snowball version important?
Well, one of the biggest factors constraining application migration to the cloud is the data associated with applications. So constraining, in fact, Dave McCrory (@mccrory) coined the term “data gravity” to describe how the sheer difficulty of transferring massive amounts of data from one environment to another retards otherwise-desirable migrations. Anything that makes it easier to transfer data from an on-prem environment to AWS accelerates application migration.
In fact, Snowball (and its way-bigger big brother Snowmobile) are directly aimed toward that end. The original Snowball was a storage appliance allowing data to be loaded in a remote location and then sent to AWS, where the data was automagically transferred into S3. This reduced the friction associated with data transfer and uploading.
However, it did little to reduce the friction of getting the data into the Snowball device in the first place. Snowball devices offer an S3 interface to the onboard storage, so one could write a program to slurp local data and write it to Snowball. But that requires an on-prem server, and that means the grand plan to get apps into AWS is bottlenecked behind the weeks-to-months provisioning timeframes typical in on-prem environments.
AWS added Lambda support in 2016 via Snowball-hosted Greengrass, but that only provides post-onboarding processing, triggered by object upload.
So what more could AWS do to reduce the friction of getting data from its on-prem location onto Snowball?
Well, it could shift the data processing executable from a customer-hosted server to Snowball, thereby avoiding the need for any on-prem processing. This removes that provisioning bottleneck, and thereby reduces the time to a customer deploying applications into AWS — which is AWS’s end goal.
So the resulting value chain of the Snowball Edge with EC2 is:
It’s clear there’s a bunch of different groups within AWS that have to coordinate these six steps in the value chain, all to deliver the device and associated functionality.
The length and complexity of this value chain illustrate how much work AWS is willing to put in to reduce customer adoption friction.
The important insight to take away from this example is not to be satisfied with the glib explanations proffered by tech punditry, but to look deeper to understand the true motive behind the offering. If you understand the importance AWS places on enabling customer adoption — simplifying the tasks the end user must do to deploy applications and reducing the friction of transacting with the company, then you’ll understand the true purpose of Snowball Edge with EC2.