Amazon Web Services recently stormed the Gartner Magic Quadrant as the undisputed leader of cloud computing. Given that it has "the richest array of IaaS and PaaS capabilities" and "provides the deepest capabilities for governing a large number of users and resources," with a "multiyear competitive advantage over all its competitors," it's easy to forget the source of AWS strength:
Developers.
If RedMonk analyst James Governor is correct in his argument that "the only sustainable business advantage in an age of unprecedented technical change is unleashing engineering talent," AWS was first to recognize this and enable it. Moreover, it's not the production workloads that mark the true test of AWS strength -- it's the lowly dev-and-test instance.
Datacenter infrastructure vendors comforted themselves for years with the fiction that enterprises only entrusted public cloud services with dev and test workloads, thumping their collective chests that "real" workloads would stay behind the firewall. In so doing, they completely misunderstood the essential importance of dev and test, and they will pay for that mistake all the way to their bankruptcy proceedings.
Crowning the kingmakers
As mentioned, Amazon saw the importance of dev and test workloads from the start, recognizing the potentially disruptive role that developers could own. Traditional IT manacled developers, but cloud hardware resources and open source software liberated developers to move fast and build stuff.
At the AWS Summit in London, Amazon CTO Werner Vogels called it out:
Sometimes people say dev and test are not serious workloads, but you know what? I think dev and test are the most serious workloads there are for your business, because it is where agility lives and determines how fast your company can move.
This isn't merely a matter of giving developers access to awesome resources. It's also about giving testers the ability to use production-grade hardware, as Vogels noted. In the cloud, he said, "you can run your tests at the highest fidelity level possible [and not on whatever leftover hardware you find sitting around] because there is no shortage of the production machines you can be using."
The dev-and-test gateway drug
The other point that should be obvious is that if developers get started on a platform, they're likely going to end up pushing into production on the same cloud.
Sure, early on developers may have used AWS exclusively for dev and test, then pushed that code into private datacenters for production. But this was never going to last. The pull of public cloud is too strong, as Gartner research director Mindy Cancila asserts: "Virtually no one moves from cloud back to on-prem. Anyone saying [the] opposite is selling you hardware."
Not only do they not move back to on-prem, they also tend to aggregate all their workloads on one cloud. AWS chief Andy Jassy nailed this recently, highlighting that "for anyone who's had to maintain multiple stacks, it's a pain in the butt. It's hard, it's resource intensive, it's costly, and development teams hate it."
Think about that for a minute. Assuming your chosen dev-and-test cloud offers the functionality, performance, and security you need, why would you then upend the work invested in supporting that platform to move production workloads to a completely different environment, cloud or otherwise? Enterprises used to put up with this inefficiency because they viewed the public cloud with suspicion. Over time, however, running dev-and-test workloads in the public cloud dissipates that suspicion and replaces it with confidence.
Winning over dev-and-test workloads, in short, is incredibly important. The cloud vendor that wins over developers ultimately wins the entire enterprise. Amazon realized this early. Microsoft Azure has come to the same conclusion more recently, to good effect. It seems clear that all other providers -- Google perhaps excepted -- are going to end up paying for their early and continued ignorance of developers with their own cloudy obsolescence.