TL; DR: Momentum is increasing around Cloud Native, but beyond the natives people are finding the plethora of choice confusing.
We had the opportunity to attend Cloud Native Con/KubeCon in Berlin last month. The buzz and momentum around cloud native technologies of all varieties and hues continues to grow.
A growing number of traditional enterprises are experimenting with, and deploying, Cloud Native technologies, particularly for green-field projects. Kubernetes is present in a substantial number of these enterprises, as are other technologies derived from projects hosted with the Cloud Native Compute Foundation. The foundation is establishing itself as the home for many core technologies in the cloud native space. Solid roots are being sown.
The Demographics of Cloud Native
Before we discuss the conference, we do need to address one point head-on. The demographics of the event in Berlin were truly awful. I tweeted at the time
Lots of interesting things about #kubecon, but I'm estimating a 95% male attendance, and that is really, really depressing..
— Fintan Ryan (@fintanr) March 29, 2017
There were varied responses, but if you, in anyway way, think that a conference where well over ninety percent of the attendees are white males is either representative of society or are representative of where the company’s which such conference attendees work for need to get too, you need to take a long look in the mirror.
We do want to highlight that the team running Cloud Native Con are actively trying to improve things – from organising child care, offering free passes, travel support and so forth. Their parent organisation, The Linux Foundation, has also started to put in place specific policies around speaker and panel diversity and other areas. Small steps, but steps in the right direction none the less.
It is not just the foundations that have a responsibility – if your company can only send men to an event, ask yourselves why. What in your culture, your hiring process, your approach to work is creating the monoculture you exist in. What can you do to change this?
Gretchen Hellman has written far more eloquently than I possibly can on the broader subject of moving beyond being outraged about sexism in technology and doing something about it. If you are only prompted to do one thing from this piece, please read her thoughts .
The Cloud Native Landscape
One issue for the cloud native compute foundation is the myriad of projects and companies that are loosely classed as Cloud Native. To say this space is noisy now is somewhat of an understatement. As we noted last year the entire space is still amid a gold rush, although to stretch than analogy a bit further it is starting to become self-evident who is providing the shovels.
Perhaps the most frequent phrase you will hear from all of us at RedMonk is that the best packager wins. While developer choice is a good thing, it can also be overwhelming for users beyond the early adopter cohort. There is a significant risk that the plethora of choices becomes a barrier to adoption, although, as we note later, a number of companies are addressing this.
Core Cloud Native Project
The major news just prior to Cloud Native Con was the announcement that containerd, which originated at Docker, and rkt, which originated at CoreOS are becoming CNCF projects.
As we stated at the time the containerd project was announced, we see the project as a welcome move from Docker which provides reassurance to the broader ecosystem. The CNCF is, in our opinion, the correct home for containerd, and it marks a significant maturation point for the wider ecosystem and allows several players to bring significantly more clarity to their commercial offerings.
Overall the momentum around the current project base remains strong, although, as acknowledged during the keynote, awareness of projects beyond Kubernetes remains limited.
The Next Wave
During the Keynote Dan Kohn highlighted several projects that the CNCF is actively considering, covering areas such as streaming, storage, service management and discovery, networking (we omitted networking from this analysis) and observability.
These projects are all interesting in their own right, but they also raise a question of scope. Is the focus on making core infrastructure easy, or expanding our definition of infrastructure to include multiple higher order components such as messaging systems and databases – there are varying opinions on this and we have yet to reach our own conclusion, although it is fair to say that application developers are in general happy with additional abstractions which make for an easier life.
We continue to see momentum accelerating around Kubernetes. As we will touch on a moment, for most commercial use-cases the choice is coming down to a limited subset of players. As for the Kubernetes project itself, the velocity of the project is maintaining a solid trajectory, with the further development of several essential pieces of enterprise functionality, such as RBAC, in the latest release.
The Dog Pile of Distributions
Currently we are tracking forty odd “distributions” of Kubernetes. We expect to see this expand even further over the coming year before eventually consolidating. Now the phrase “dog pile of distributions” is an extremely harsh one to use, but in certain circumstances it is accurate. James Watters of Pivotal recently used it in an A16Z podcast, and while it was focused on OpenStack, it is relevant here.
The OpenStack conundrum came to the fore in the compatibility challenge at least Autumns OpenStack summit in Barcelona. During that event a variety of OpenStack vendors of different hues stood up on stage and showed a demo with an application being easily migrated from one cloud to another. There is a lot to be positive in standardisation and compatibility efforts, but the real question should always be how did we get to the point where this was even a question in the first place?
There is a danger of the same issue arising, albeit with a different control point, for Kubernetes. From a developer perspective, the abstractions provide should eliminate most concerns, from an operator perspective they are in danger of becoming acute.
In most of our conversations with vendors of some form of Kubernetes offering we see limited differentiation. Let us be blunt here – your integration with several CI and/or CD systems, github, bitbucket or gitlab and so forth is not a differentiator. Nor is your custom yaml file, slightly nicer installation and the extra go utility that goes with it. These are just table stakes. Everyone is offering these productivity gains, unless you are providing something radically different there is no meaningful differentiation.
In the cold hard commercial sense the market is also being very clear on this lack of differentiation between offerings. During our conversations, we come across a much smaller set of Kubernetes offerings being discussed, with OpenShift from RedHat, Tectonic from CoreOS and Rancher from RancherLabs leading the pack by some way in on-premises discussions and GKE from Google leading managed cloud deployments, with offerings such as WeaveCloud from WeaveWorks also in play. Canonicals Ubuntu based offering is beginning to come up in conversations, and with the strength of their Amazon install base we expect this to rise. Microsoft’s announcement of general availability for Kubernetes on Azure in February is also leading to some early stage deployments.
It is important, however, to understand that each of these offerings is considerably more than just vanilla Kubernetes, be it in packaging or easy integration to adjacent services.
The Amazon Question?
For Amazon, much of what is happening around Kubernetes is a win-win.
There is much talk of cloud portability and so forth, but once companies make a choice to go a specific route they tend to stay on it, and you cannot underestimate either the impact of data gravity or the attractiveness of the various database as a service offerings Amazon now have in place.
While the clear majority of in house managed cloud deployments of Kubernetes that we hear of are on AWS we also note that ECS momentum is strong, and the offering is incrementally improving. For now, we see no specific Kubernetes offering from Amazon on the horizon, but as with everything that Amazon does if the data supports providing a Kubernetes based offering they may do so.
As we pointed out after a Cloud Foundry event last year, any technology laying claim to being the only thing required for every enterprise organisations IT future is sorely mistaken. In the currently climate this is a mistake we are seeing from many in the Kubernetes ecosystem. Just as it is not going to be Cloud Foundry everything, it is also not going to be Kubernetes everything to the detriment of all other approaches.
There are some isolated incidents, in truly greenfield scenarios – but in most cases, we find that large enterprises have at least two or three different approaches to cloud native deployments and operations under trial, and in some cases all three are in production, albeit at a relatively limited scale.
Given the relatively early stage that the overall cloud native market is at, this gives us an example of enterprise hedging at its finest. However, the real story is about a change in development practices and approaches, not the underlying technology. As we frequently say digital transformation is, in the main, about culture and people – not a specific piece of technology.
One of the areas that the CNCF was keen to highlight at their event last year in Seattle was the concept of an end user member. Notably there has been no significant uptake by end users yet.
On the vendor side, there has been another increase in membership, bringing the total number of vendors involved to 73 members. The number of board seats has grown to 19 (as a reference point the main Linux Foundation board has 21 members), which is in danger of becoming unwieldly, although the structure of, and separation between, the technical oversight committee and the main board ensures technical decisions are kept separate.
Disclaimers: The CNCF paid for my T&E to Berlin. Docker, RedHat, TreasureData, CoreOS, Google, Amazon, Microsoft, Atlassian, The Linux Foundation, The Cloud Foundry Foundation and Pivotal are current RedMonk clients.