The next cloud battle is here and it is at the edge

More than a decade ago, Amazon Web Services was launched as a system that offered flexible compute instances. There are a lot of stories about the formation of AWS; some say that Amazon originally created AWS so that sellers on its marketplace wouldn’t have to deal with the IT burdens of setting up their own systems. We do know that it was launched without much fanfare as a side business for Amazon.com.

As enterprises large and small started to embrace AWS, it grew steadily but also quietly. The silent growth of AWS from a no-name system to over $5B/annual revenues in 2015 (which was the first time Amazon shared AWS figures) was a very clever play by Amazon. Today, almost all of Amazon’s operating income comes from AWS.

During this phase (2006-2015), most on-premises server, storage and networking vendors were going through a slow growth period, and they routinely cited the broader market slowdown (2008 crash and recession) as a rationale for their slowing growth. However, the truth was that a bulk of the growth was going to cloud or sophisticated homegrown technologies at cloud-scale companies (including Amazon, but also LinkedIn, Facebook, Twitter and Google, to name a few).

Microsoft eventually did make some bold decisions and got rid of the “strategy tax” that it imposed on customers and partners, and it finally rightsized the importance of Windows in the marketplace. This led to the “Azure Age” and the reinvention of Microsoft.

Google, not to be left behind, realized that enterprises are a pretty steady and margin-appropriate business model that can provide additional growth while it pursued moonshot projects with Android, autonomous cars, Google Lens, longevity research and so forth.

Fast forward to 2018, and the game is well into its middle innings. There is a reasonably clear roadmap of what needs to happen over the next three to five years for cloud services to improve and compete with each other. What classically started as a feature/performance fight quickly changed into the battle for data. Data has gravity and the “you can check out any time you like, but you can never leave” business model of cloud data (i.e., ingress is free, but we will charge you for taking data out of the cloud) leaves a lot to be desired. Then optimizations started that brought in deeper lock-in such as API (Cloud Vision APIs from Google) and algorithms as a service (such as the conversational interface with Amazon Lex).

There is a major trend that the cloud vendors now realize they must address, and that is the emergence of IoT edge. IoT is defined as intelligent systems that not only generate humongous amounts of data (imagine an autonomous vehicle, oil rigs with thousands of sensors, multiple devices on each and every thing and person), but that also require local intelligent computations.

The IoT edge is a challenge that the cloud was never prepared for. And it is one of the larger trends that, unless addressed, puts a ceiling on how large clouds can grow. Gartner Analyst Thomas Bittman says in his article “The Edge will Eat the Cloud” that “the agility of cloud computing is great … but it doesn’t overcome physics — the weight of data, the speed of light.”

This fact is not lost on cloud vendors, and they are starting to figure out ways to address it. In February, Google acquired LogMeIn’s Xively IoT platform, and in April, Microsoft announced that it will triple its spending to over $5 billion on IoT.

This is because cloud vendors already see that they are missing a huge portion of the IT market — the IoT/edge market. Not only that, they also understand that if left unaddressed, it threatens to upend their cloud revenues because the amount of data the IoT edge will generate dwarfs what is stored in their cloud data centers.

The reason current cloud offerings are not adequate to address the IoT and edge market stems from the fact that cloud design principles are orthogonal to the edge requirements.

The infrastructure for IoT and edge systems is very different from what the cloud was designed for:

1. Low footprint power sensitive software stack — Software cannot assume unlimited elasticity. The cost of an incremental container in the cloud is practically zero. Therefore, it’s optimized to fit in the least amount of memory and CPU footprint. Although it’s good for margins on a large scale, it’s a nonissue when it comes to solving important challenges quickly. It’s quite the opposite on the IoT edge. The IoT edge can be a very small device or a sensor that barely has any room for additional software.
2. Variable latency — The latency from the edge device to the cloud may vary from a few hundred milliseconds to infinite latency. Clouds are built with sophisticated inter-VM and inter-region latency targets.
3. Diverse network — The edge stack has to operate across a very diverse network system. Some edges may connect through Ethernet, cellular, satellite or Wi-Fi, to name a few. Clouds are predominantly standardized on wired, Ethernet network-like systems.
4. Unpredictable bandwidth — As a consequence of the network and the cost to get high-quality network bandwidth into IoT systems, the bandwidths also are variable. Software needs to be able to deal with this.
5. Occasional connectivity — IoT/edge systems may connect occasionally. This is true for high-speed trains or container ships when they connect back up to the network when they stop at stations or docks. This is also true for systems where connectivity is provided when a contractor with a “cell connection” drives up to an IoT device occasionally.

As organizations embark toward their data- and artificial intelligence-driven reinvention of their IoT edge systems, it’s important to keep in mind some principles that history has provided for us:

1. Open API — Use an open API platform and not one that provides further lock-in tangles into your cloud provider.
2. Fabric — Understand that connecting several IoT systems to regional and global cloud systems essentially constructs a data fabric. Solve this issue by making sure applications are able to access data in a single global namespace so that data movement does not result in rewriting applications.
3. Act locally, learn globally — Artificial intelligence and its sub-branch of machine learning on the edge require the ability to act locally and independently to react to local situations effectively without relying on the cloud. Having said that, the system/fabric needs to work in a way that it can learn globally from all the edges and then feed that intelligence back to every edge.
4. Don’t make it too big to fail — Putting all the control and management functions in the cloud will make the system prone to failures. The system should be decomposable into individual data clusters — whether on the edge, in regional clouds or in global clouds that allows for the ability to manage them either as a unified unit or individually.
5. Secure — As data-driven strategies push aggregated intelligent data to the cloud, there are security mechanisms now available to secure data in the cloud. But what about the edge? The security policy framework should not have to be recreated for the same data multiple times depending upon where the data currently resides.

Cloud providers are starting to realize that the afterthought approach to edge computing won’t work. That is the next battle, and it is going to be bigger than the cloud itself.

All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.