What is Edge Cloud? - Two differing views about what makes an Edge Cloud

I always enjoy talking to Richard Simon, the Cloud Therapist. His cloud native enthusiasm, now infused with his experiences of being CTO at T-Systems, challenge some of my IT pre-conceptions, and I like to think I make him consider some of his own.

The reason for our latest conversation was to get his take on the recent AWS Summit in London. In particular, I wanted to get the lowdown on any AWS Outposts and Wavelength discussions that might throw more light on AWS Edge Computing strategy. In reality, AWS tried to cram so much into one day that was barely more than a rehash of the last AWS Re:Invent that Richard came away a little disappointed and had nothing new for me.

However, that didn’t stop us debating the issue of Edge Computing and what constitutes Edge Cloud. Here at Bloor, we start from the point of view that Cloud is fundamentally a consumption model rather than a particular service or location. For us, it is just as relevant for in-house IT departments to set up and run a private cloud service for their users, as it is for them to decide to use the public cloud services of one of the big 3 vendors, or any mix of private and public cloud from multiple vendors for that matter. The fact that these services are run at, or nearer to the Edge is irrelevant.

Richard’s definition of an Edge Cloud was more specific. In his view it is an extension of the Cloud provider’s, specifically in this instance AWS, Microsoft Azure or Google Cloud Compute, managed environment out to an edge location. The implication is that you don’t have to build and deploy your own cloud, or use a different cloud provider’s service. You use the same management console, with the same (or subset of) the services you are already using, so get a very consistent look and feel from edge to hyperscale datacentre.

Ultimately this boils down to an age-old buy versus build question. In the case of AWS Outposts and Azure Stack and Azure Stack Edge you have to take their own hardware appliances into your edge locations. Google Anthos is different, and more like build than buy, in that you are responsible for setting up on-premises hardware and deploying Anthos. Anthos is also designed to make it easy to port container-based applications across multiple different clouds, reducing the potential vendor lock-in you get with the other two.

If there is an application that runs at the Edge that you believe is important to the success of your business, and it only runs on AWS or Azure then buying it, and the whole proprietary stack that comes with it, makes total sense. Otherwise, you will be looking at building, partially at least, your own infrastructure and development stack. But that doesn’t stop you running it for your users as a private cloud, or using a cloud platform from a provider other than the big 3.