I'd like to talk about what I'll call “The Cloud Native Tsunami”, which is the emerging software architecture for cloud, but also for enterprise, and eventually for edge and even embedded software as well.
It has been my thesis for a couple of years that when Marc Andreessen (the co-founder of Netscape) said, "Software is eating the world," the software that's really going to eat the world has been cloud software, and this is especially true for software development. My thesis is that the methods and technologies people use to develop and deploy cloud software will eventually swallow and take over the enterprise space in our corporate data centers, will take over the edge computing space, and will even threaten the embedded software space. Today each of these domains has different development tools in use, but my thesis is that cloud software tools will eventually take over, and the same common development tools and technologies will end up being used across all of these domains.
KubeCon and CNCF
In mid-November, I attended the KubeCon America event in San Diego, California. KubeCon is an event sponsored by the Cloud Native Computing Foundation (CNCF), which is an umbrella organization under the Linux Foundation. CNCF manages a number of open source software projects critical to cloud computing. The growth of this conference has been phenomenal, and its name “KubeCon” stems from Kubernetes, which is the flagship software project managed by this organization.
Kubernetes is an open source software project that orchestrates large deployments of containerized software applications in a distributed system. These can be deployed across a cloud provider, or across a cloud provider and an enterprise, or basically anywhere. The growth of this conference, as you can see from the chart, has been phenomenal. Five years ago, the Kubernetes project – the software – was private and maintained within Google. About 5 years ago, Google released Kubernetes to Open Source, and since then the KubeCon event and the interest in this software has grown exponentially.
It certainly seems to me that Kubernetes represents a software inflection point similar to ones we've seen in the past. For instance, when Microsoft presented it's Microsoft Office Suite, they defined personal productivity applications for the PC. Or before Y2K, when enterprises were rewriting their existing software to avoid Y2K bugs, but in doing so were generally leaping onto SAP R/2 in order to avoid a issues with Y2K. Or maybe it’s a little bit like the introduction of Java, which defined a multi-platform execution environment in a virtual machine, and maybe also a bit like the early days of e-commerce when for the first time the worldwide web was linked to enterprise databases, transactions, and business processes.
This rapid growth in interest in Kubernetes has been phenomenal, but exponential growth is obviously unsustainable or the whole planet would soon be going to one software development conference. One thing that's very important to point out with this rapid growth (from basically nothing to 23,000 people attending these events) is that there is a people constraint in this ecosystem right now. There is a shortage of people who are deeply experienced. And even some of the exhibitors and sponsors at KubeCon came to the event just to recruit talented software developers with Kubernetes experience. But you can see from the chart that there's not a lot of people in the world who have more than five years of Kubernetes experience!
CNCF and its Open Source Project Ecosystem
In addition to Kubernetes, the Cloud Native Computing Foundation curates several other Open Source software projects. These projects provide services or other kinds of auxiliaries that are important for distributed applications. While Kubernetes is the flagship product, there are other projects that are in different stages of development. The CNCF breaks projects into three areas that they call “graduated” for the software projects that are ready to be incorporated into commercial products, “incubating” which refers to an open source software project that is in a more rapid state of development and change, and finally there's a third tier below this which CNCF calls “sandbox” projects, which are more embryonic projects that are newer, less fully developed, still emerging. And of course, there are any number of software projects outside of this CNCF ecosystem, but CNCF is a major ecosystem for open source software for the cloud.
From the conference, we could see the enterprise impact of Kubernetes is still relatively low. In other words, market leaders are using this technology now, but in general it's at its early stages of deployment even among the leaders, and most enterprises have not yet adopted containerized applications with Kubernetes for orchestration. But, growth in this area is inevitable. This is, as I said before, like Microsoft Office, or like SAP, or like Java; it's coming to the enterprise. Even though the penetration is still low, leaders are rolling out distributed applications and managing distributed applications at scale, Kubernetes is the tool that people are turning to in order to do this.
The auxiliary open source projects I mentioned before will grow the capabilities of Kubernetes over time. So, a number of auxiliary services for data storage, for stateful behavior, for network communications, software defined networking, etc. are going to supplement Kubernetes and make it more powerful. While at the same time, other engineers are working to make this kind of technology, as complex as it is, easier to use and to deploy.
Two Vertical Industries Driving Technology
I should mention a couple of vertical industry initiatives where Kubernetes is especially attractive. One of them is 5G telecommunications. Telecom service providers are extremely interested in digitizing their services as they move to 5G. Instead of maintaining services at a tower base cell and providing them via hardware/software appliances that are dedicated-function, telecom providers are now looking to virtualize these network functions and deploy them digitally. So they will have a very large set of applications to manage at a huge scale, and so they've turned to Kubernetes to do this.
A second vertical industry area that is important is the ability to manage new automotive products. This can be autonomous vehicles, fleets of vehicles, or just vehicles that have much more software content than vehicles used to have. Clearly, there's a need for these automotives to manage large scale software deployments at hundreds or thousands of end points and do so with very low costs and very high reliability. So, there are certainly vertical industry initiatives that are driving Kubernetes from the cloud service providers through the data centers toward the edge.
How to Orchestrate the Industrial Edge?
But what about the industrial edge? When we turned to the industrial edge (and the figure below is from Siemens Research) we can divide the compute world into four different domains. We really have at the industrial edge, much more restricted capability in terms of compute power, in terms of storage, in terms of networking, than we find at a data center, be that a corporate data center and much less than we find within the commercial public cloud. And we can go a level further and even see within the automation or manufacturing devices, things such as program logic controllers, CNC machines, robotics, etc., that these are generally addressed by an embedded system that is built for purpose.
One difficulty is that deploying Kubernetes and managing containerized applications at scale, requires larger amounts of compute, network and storage capacity than these edge domain and device domain systems now have. So, this is an area where there's a big challenge to adopt this new technology. Why am I so optimistic that this is going to happen? I'm very optimistic, because there are very similar challenges in the two huge vertical industries that I mentioned, the automotive and the telecommunications industry. These industries also have thousands, or tens of thousands of small systems on the edge on which they need to maintain and deploy software. And that challenge is going to have to be met one way or another. And there's extensive research and development going on now to do just that.
So, in terms of its industrial and industrial IoT impact (though industrial automation is traditionally a technology laggard), industrial IoT applications are definitely a target for Kubernetes. And this involves moving orchestrated, containerized software apps to the edge. As I mentioned, both automotive and industrial applications have similar kind of constraints. They have low compute capability, small footprint, and generally they also demand low bill-of-material costs for the kind of solutions that they can provide. This remains a challenge, but again, I think there are a number of venture stage companies and a lot of research going on to bridge this gap, and people are going to find a way to do that effectively.
But that makes the future very difficult to map out. This ecosystem is extremely dynamic. As I mentioned, Kubernetes was not even in the public domain five years ago. Now it has, if you will, taken over mind share in terms of the technology that people are going to use to orchestrate containerized applications. But, the next five years are likely to be equally revolutionary. So, it's absurdly difficult to map out this space and say, "Here is where it's going to go in 5 years."
Kubernetes as a Massive Control System
But I found that this little quote I saw at KubeCon was interesting and I think if you're working in manufacturing or manufacturing automation, you'll find this interesting, too. This is a description of Kubernetes by one of the co-chairs of their architecture special interest group.
“The entire system [that being a Kubernetes deployment] can now be described as an unbounded number of independent, asynchronous control loops reading from and writing to a schematasized resource store as the source of truth. This model has proven to be resilient, evolvable and extensible.”
What he's talking about here in terms of “control loops” are not control loops in the automation sense. They are control loops in the enterprise software sense. These control loops are functions that Kubernetes is performing to maintain a software deployment and monitor the health of this deployment. I found this interesting in that at this level (at the deployment level) for huge distributed applications, people view Kubernetes as a driver of a large number of independent and asynchronous control loops. It points out, to me, that the same sort of technology could be used to manage other types of control loops in automation within a manufacturing operation.
Research on Kubernetes and the Industrial Edge Software
This leads to an upcoming ARC research topic. ARC Advisory Group is beginning research into industrial edge orchestration, specifically the orchestration of applications that are distributed in industrial manufacturing, the industrial internet of things and infrastructure. Because this state of the technology is so early (even though it's critical for the future of industrial automation and for the fourth industrial revolution or industry 4-0) the field is very dynamic, and it's very difficult to map out such a nascent and varied landscape of technologies for integrating and orchestrating the industrial edge. During this research ARC, will be studying the products and technologies of many venture stage firms as well as open source projects that are designed to bridge the gap between the cloud and the industrial edge –and these include infrastructure for 5G telecommunications, edge networks, requirements to manage fleets of vehicles, as well as the networking opportunities that are afforded by 5G itself.
With this industry at such an early stage, any detailed market forecast would be highly speculative and very uncertain. But ARC has decided to map out this landscape and plans to provide as deliverables for this research a series of podcasts, webcasts, and reports for our ARC Advisory Service clients. So, ARC is reaching out to relevant suppliers in this space, be they hardware, software or services suppliers, to participate in this research initiative. If your firm would like to participate in this research, ARC welcomes your input. Please use this link to connect with ARC or feel free to contact me at firstname.lastname@example.org and I'll be happy to discuss this project with you.