The Commodity Container Story

TL; DR: The focus maybe on AWS EKS, the managed Kubernetes offering. The future is with AWS Fargate and similar services

The rapid commoditization of components is a well understood concept in economic theory. What was complex often becomes simple with abstraction. Substitution between vendors becomes easy, and you see increased transparency in product features across both offerings and pricing. Vendors can continue to innovate on a technology level beneath the abstraction, but the longer-term economics now require you to have a volume business, with its inherent structural advantages, to grow your overall margins.

With the announcement of the Amazon Elastic Container Service for Kubernetes (EKS), Kubernetes has become a commodity across the public cloud ecosystem. Amazon, Google, Microsoft and IBM all now have a managed Kubernetes offering of some form. More significantly, in terms of world-wide growth, Alibaba have quietly certified their offering under the CNCF certification program, and we anticipate that their extensive involvement with the CNCF will only serve to grow their Kubernetes install base.

As the Cloud Native Compute Foundation pointed out, and as AWS were very keen to cite over the entire event, at the time when AWS joined the CNCF 63% of their survey respondents ran containers on AWS. In the CNCFs own data released after re:Invent that number had increased to 69%. Anecdotally we estimate this to be even higher. The breadth of the CNCF membership will automatically skew their surveys away from Amazon.

Over the last two years a number of vendors have focused, almost obsessively, on Kubernetes being a solution for scheduling and cost issues rather than on its potential for developer productivity. However, as we have noted previously, scheduling is only part of the problem – an interesting computer science part without doubt, but not one where any significant amount of differentiation can be derived at a business level.

On the other hand, increased developer productivity, alongside the potential security wins with a cloud native approach, are a win all round. Given a choice between faster responsiveness to customer demands versus saving a small percentage of costs due to retooling an infrastructure layer it is easy to see where a business unit’s preferences will lie. It is into this space that the various managed Kubernetes offerings, EKS included, will play.

All of these services have a common interface with tools such as kubectl, as far as a consumer, versus a pure operator, will be concerned – and this is where the CNCF has a very important part to play. Their recent certification efforts will allow people to develop a significant portion of their software in a manner which is compatible with a multi cloud strategy if they so desire.

AWS Fargate

Here at RedMonk we continuously talk about the value and convenience of packaging. Fargate is convenience on steroids for containers. As I noted during the keynote

AWS Fargate is more interesting than EKS IMHO, "serverless" containers #reinvent

— Fintan Ryan (@fintanr) November 29, 2017

Once you move beyond infrastructure geeks most people do not want to think about the environment they are deploying too, they just want it to work and get on with their next task.

Amazon understand this, as do Microsoft. The most comparable service to the initial AWS Fargate offering is the Azure Container Instances, which have been in preview since July. The interesting aspect here is that both AWS and Microsoft have realised that the setup and configuration of a container infrastructure is repetitive and error prone. Remove the complexity from the equation and adoption will increase.

AWS Fargate is packaging taken to the next level for containers. But the key points to understand here have little to do directly with AWS Fargate, and far more to do with what the tightly coupled integration into other areas of AWS, such as IAM, Cloudwatch and so forth.

MyPOV: Early adopters completely underestimate the importance of IAM to @awscloud success. Consistent identity & coherent policies are vital

— Fintan Ryan (@fintanr) April 3, 2017

Essentially Fargate is delivering on containers being the atomic unit of compute, something which my colleague Stephen O’Grady highlighted back in 2014. There is a lot more work to do, but with roadmap disclosures during re:Invent around managed service discovery (built on route 53) and codepipeline we anticipate most, if not all, of the gaps being completely filled in over the coming year.

More importantly, as we will come back to in a moment, Fargate will become the underlying primitive by which AWS will run EKS and other container based offerings. Microsoft are also adopting this approach.

AWS EKS

There was an obvious air of expectation prior to re:Invent re a Kubernetes announcement, and you could see Andy Jassy was enjoying himself when he announced the Amazon Elastic Container Service for Kubernetes. While anticipated, it was obvious the announcement was not expected at this juncture from other players in the industry.

There are various takes on why AWS want to create such an offering, but we can sum it up as “cluster management is a legacy view”. As we have already noted most people are really not interested in standing up Kubernetes by themselves. Indeed, it was notable in conversations the following week during KubeCon that, other than the very early adopters, most people we spoke with were clear that the managed offerings from the various providers were both welcome and interesting.

The other extremely interesting announcement was the planned AWS Fargate support for EKS. If we move to the point of essentially “serverless” kubernetes infrastructure what does that do in terms of the overall adoption curve?

As we noted in our RedMonk slack chat on re:Invent the “accretive aspects to their [AWS] business become more problematic for competitors over time”. AWS have now established a significant beachhead of customers that are willing to experiment with new offerings. This will have a number of impacts on the Kubernetes space. Firstly, by making Kubernetes simpler to consume AWS will drive significantly more volume in the space. But once their customers get used to the convenience that Fargate provides, and the reduction in operational overhead, will there be any significant interest in switching elsewhere?

Kubernetes, Distros and Long-Term Support

One of the other questions we hear frequently about Kubernetes is long term support. EKS is planning on offering the last three versions of Kubernetes at any given time. Given the current release cycles this is, roughly, a nine-month update window at any given time.

This actually raises one of the thornier questions around using bleeding edge software such as Kubernetes. Enterprises, even the most forward looking, are somewhat conservative – and as such are generally going to be running at least one release behind (in areas such as operating systems we frequently see upgrades, beyond security patches, running out at least 18 months and beyond). There is a reason long term support is a lucrative source of revenue for vendors.

As we move into an era where Kubernetes can be considered in the same manner as we used to talk about Linux distributions, is there a need for a long-term support model for the project as a whole? Clearly AWS sees a need in their customer base. RedHat, Rancher and CoreOS offer variations on long term support already.

One of the examples often cited for maintaining what is essentially their own Kubernetes distribution is Monzo – but again you have to ask how long can you justify investing engineering resources into maintaining such a distribution, particularly in the face of a managed services offering optimized for your primary infrastructure provider. There is, without doubt, a scale point that needs to be considered here – but from a sheer economics standpoint you have to ask how long is it justifiable to tie up your engineering resources on undifferentiated work.

Developer Productivity

All of these new abstractions ultimately lead us back to the true value of containers – that of developer productivity. This is the original message that Docker led with, and still talk about in the majority of their marketing.

If you are positioned as a pure Kubernetes play your room for manoeuvre may be limited. There will be some consolidation in the coming six months.

But if you are operating a layer above, at the point where businesses see some distinct value, then things are about to get far more interesting. It may be from a developer productivity standpoint, where companies such as Weaveworks, and Oracle with the Wercker acquisition, Pivotal with Spring on Kubernetes, or areas such as networking policy with Project Calico from Tigera, or application packaging with Helm from a vendor like Bitnami. Once it is not just about Kubernetes the world is about to open up in interesting ways.

Image: Packaged food at Fred Myer, sourced from Wikipedia, CC-SA-2.0 License.

Disclaimers: Amazon, Microsoft, Google, Bitnami, Docker, Red Hat, CoreOS, IBM, Oracle, Pivotal and The Linux Foundation (CNCF parent) are current RedMonk clients. Amazon paid for my T&E at re:Invent.