As we drown this week in a cacophony of AWS service releases (“Route53 Resolver now exists!” “IAM users now support tagging!” “Introducing our no-SQL service for digital video, DynamoDV!”), one came out yesterday that caused me to do a spit-take. Specifically, a little-remarked upon change declared that AWS has renamed EC2 Elastic GPUs to Elastic Graphics. At this point you may be wondering what’s odd about that. If so, you’re not tracking how Amazon operates.
Unlike Google, who apparently spins a wheel every Monday to figure out if a service is taken out of beta, renamed, or deprecated (one time the wheel fell off the holder and they were forced to rename the entire company “Alphabet”), AWS very rarely renames something once they’ve lauched it. To wit, despite having over 125 service offerings at last count, I can list on one hand the number of services that were renamed post-launch. To be quite clear, Amazon suffers from something of a naming problem. Notably, one of their only renames took place last year, when they reshuffled / renamed “Amazon EC2 Systems Manager” to “AWS Systems Manager.” This was a great plan; otherwise you’d have to call “AWS Systems Manager Session Manager” “Amazon EC2 Systems Manager Session Manager,” which would just be a ridiculous and terrible name for such a handy service.
Despite the slings and arrows I hurl at them, Amazon clearly takes naming seriously. Renaming “Elastic GPUs” to “Elastic Graphics” implies they’re no longer thinking about the service as a set of distinct GPU components, and more as a service that’s far more broadly applicable than a mere plug-and-play graphics card. Their stated reason for the rename of “to make our service naming more consistent with the graphics acceleration use case” fails to hold water, as…
- Amazon and consistent naming go together about as well as peanut butter and a belt sander; they can’t decide with any consistency whether to start a given service name with “Amazon” or “AWS.
- That statement makes approximately no sense whatsoeover.
To my mind this speaks to coming changes to how graphics acceleration manifests itself to and within AWS services. What might that look like? Supplying graphics acceleration not only to instances, but to containers (Fargate most likely; ECS and EKS run on top of existing instances, which themselves can leverage either native or elastic GPUs) and Lambda functions on-demand feels like something that could arise from this. Sagemaker is already able to leverage GPUs for training purposes. The other things that could benefit from graphics acceleration feel patently ridiculous to my mind (“We now accelerate DNS queries to Route53 via graphics cards” is how I know someone finally broke into my RSS feeds and is toying with me).
This would mean that workloads previously only suited for specific instance types are now eyeing a Serverless future. That has the potential to be transformative; “run an MXnet analysis on this dataset” with zero infrastructure to configure or worry about would lower the bar still further for entry into this space, and restrict the knowledge domain for developers strictly to the AI/ML side of the house; no DevOps required.
For those of us with an operations background it can be hard to admit that the world is turning away from the skillsets that brought us here, but hope has never been a viable strategy for career management. The time when graphics cards were strictly—or even primarily—for gaming has ended. We’ll see what AWS unveils next week in Las Vegas.
