This article is more than 1 year old
AWS's Kubernetes dilemma: It's a burden and a pleasure
Keep the devs happy, or Microsoft and Google will catch you
Amazon Web Services became the 800-pound cloud gorilla by catering to developers. It expects to own the container crown with the exact same strategy, touting convenience and productivity gains to users of its EC2 Container Service (ECS). There are signs, however, that this fight won’t be as simple, and that a cross-cloud container option like Kubernetes could be the spoiler to Amazon’s steady march.
The AWS focus on developers is now established wisdom, but back when the company kicked off its baseline storage and compute cloud services, few took developers seriously. Call it prescience, call it dumb luck, but it was the absolute right strategy. For years competitors pooh-poohed AWS as being a toy for start-ups, insisting that no one would run mission-critical apps in a public cloud like AWS.
Developers drove adoption to the point that AWS now pulls in over $10bn a year, and keeps growing. On this missed opportunity from would-be cloud competitors, AWS chief Andy Jassy muses: “I don’t think in our wildest dreams we ever thought we’d have a six- to seven-year head start.”
According to Deepak Singh, general manager of AWS Container Services, AWS is taking much the same developer route now, though without the benefit this time around of comatose competitors seemingly incapable of building for and speaking to developers.
By his reckoning, AWS didn’t really have a choice but get into containers in a big way. Once industry noise around Docker started to swell, he related, AWS customers started asking when AWS would offer a container service. This was early enough in the container revolution that customers were having to figure out containers on their own.
One thing became clear, though: the need to build container support into the AWS platform. Given the broad array of existing services, this was no small feat. As Singh tells it, sometimes his team would have to build out container support for AWS services, and sometimes they had to push different AWS teams to engineer support for containers into their services. The goal in either case, however, was to give AWS customers the same API call no matter how many containers they were running.
What about Kubernetes?
Kubernetes wasn’t around as an open-source project when Amazon started developing ECS, or consideration would likely have been given to building on it, rather than rolling a proprietary service. Maybe. Given the need for tight integration with other AWS services, however, AWS rolling its own container service was always going to be attractive.
And yet… Kubernetes. By any metric, Kubernetes is the community standard. AWS (like Microsoft’s Azure) supports Kubernetes, but neither company is likely to default to Kubernetes. Singh said: “Our customers have a lot of choice. We have customers that run Kubernetes or Mesos, so we work with CoreOS and others with Kubernetes ‘distributions’. We make sure they work well on AWS.”
The rub, though, is that developer convenience and productivity angle mentioned above.
As Singh went on to say: “We have a number of customers who have specific needs with availability. They need native integration to AWS capabilities.” As such: “It made more sense to build directly on AWS primitives,” thereby yielding benefits that AWS customers demand, like end-to-end encryption and deep integration.
Such tight integration, of course, leads to the question of lock-in.
As I’ve argued, the more enterprises turn to AWS to increase developer productivity, the more services they embrace and, by extension, the more services they can’t easily abandon. This isn’t some nefarious AWS strategy. It’s just a byproduct of serving customer needs. All of them.
When pressed on lock-in, Singh demurred, suggesting: “Because the runtime is open source Docker, it will run anywhere.” Amazon, he further stressed, “always pushes needed changes to the Docker upstream,” thereby alleviating the lock-in complaint.
Except customers don’t seem to be complaining. “Most requests are for more integration, not less,” he told me. “Most customers want want more convenience, not less.” After all, at scale two things become critically important: no management overhead (i.e., no need to worry about running ECS containers across multiple availability zones - it just happens naturally) and close integration with other AWS services.
Unlocking the container key
Ultimately, this could be the thing that holds Amazon’s container competitors at bay, including Kubernetes. It’s fair to say that ECS will hold sway with AWS customers, but that Microsoft’s Azure and Google’s container services will win out for their respective customers. AWS is winning over more enterprise customers, so perhaps this is a drag race they expect to win.
For those enterprises viewing containers as a hybrid cloud deployment architecture, and there are many, the ECS value is less clear. At the front end of development projects, teams favor productivity and thus AWS wins almost every time.
But as a project progresses, teams start to favor operational needs like cost and security. When you reach that point, AWS looks less attractive, except where an enterprise is so deeply invested in a variety of AWS services as to make a hybrid approach less appealing.
In short, Amazon’s ECS is probably doomed the minute it stops innovating and integrating such innovative services together. But then, this has never been how it operates. ®