We wanted to make it work with CPUs and GPUs at the starting point. We have chosen to optimize on Intel configuration to start with. But, from a developer perspective that’s been abstracted out, we have virtualization and containerization on top of it. So the answer is complex, but, yes it is consistent with the OSI model by default because it is standard-compliant. That has been abstracted and various features were built including secure mobile breakout and inserting mobile and 4G technology. It is 100% compliant so there is not much learning to do. This is expanded upon in some white papers that are available on the website now. (https://alefedge.com/resources/white-papers/)

To start, no new skills will be needed if you already have interest in and familiarity with building cloud apps. As we layer more innovation on top of EdgeNet we will introduce new technologies, and this is all forthcoming. Quickstart guides, tutorials and more webinars are available. So to get in on the ground floor you only need an interest, excitement about and an aptitude to build cloud apps. We really want to leverage the imagination of the community.

The vision and strategy of EdgeNet is to keep it within ten milliseconds, and if possible, within five milliseconds so ultra low latency and ultra high bandwidth applications can actually leverage EdgeNet. Right now it is not within five to ten milliseconds. Rolling out EdgeNet is similar to how 3G and 4G were rolled out: discoverage then layer capacity. Our fifty locations were chosen based on proximity to Fortune 1000 companies. By the end of this year we hope to have a few hundred locations and a few thousand by the end of the next. It will have no impact on OSI models as such, we have abstracted that piece out. Certain apps may not be as high def as wanted but that is like having a 4G phone which sometimes has 2G bandwidth. EdgeNet and 5G will go through a learning curve. No special skills are needed to be able to customize it.

When building an application there are choices to be made on which microservices are responsive and which can be part of the control that requires authorization. For example we want to continue to host authentication databases in the cloud, not move them all over the place. Application design goes hand in hand with testing. Performance testing and being able to certify something as 5G/Edge ready will be something that Alef provides some guidelines for, for example for specific apps. Generally we can say here are some of the microservices that are recommended for hosting on the Edge, some that can be hosted in the cloud, and if we need to do something in between there are certain APIs to cross-connect. Latency and overall performance application testing is one area we are expecting a lot of work to go into. Please reach out to Ryan, Vijay, or someone else on the team to see how that can be a part of a marketplace offering.

The vision and strategy of Alef is to leverage the power of a network economy. Going back to the messaging days there were vertically integrated stacks that became open messaging stacks and multi-billion dollar corporations have been built based on messaging; similarly with voice. Once messaging and voice were made programmable a whole network economy was created. The main difference here in terms of learning from the paradigms is to make everything programmable and without vertical integration. That’s the power of the network economy and communities like Topcoder. Collective imagination leads to a lot of economic value. The approach we are taking is open, horizontal platforms that make it programmable across multiple dimensions. That is how we are starting the revolution and we are distinct in that. *We look forward to collaborative ecosystems. *

Downtime is often looked at as a bug. Since I’m talking to a dev community, let’s talk about how we can leverage this so-called bug and turn it into a feature. Edge can be not just a surrogate computing environment but also a backup computing environment. How can this be made possible as a product through API meant to be leveraged and gain diversity (because Edge, in the initial stages, will be potentially more expensive than cloud)? As the supply/demand curve starts to play out you want to do this in a careful manner so application performance works across the whole internet. So the answer is yes, we are building features, not yet ready in the form of APIs to make it programmable. Stay tuned.

Right now open APIs is what we have embarked on, though nothing is off the table, especially in the context of the community environment. There are many strategies in place which I’m not at liberty to expand upon right now. So the answer is yes, strategies are in place, but it’s a matter of timing in terms of what gets opened in Github, open source or other outlets. We are working with a number of partners who have taken a very open source approach which will be exposed as part of EdgeNet. If there is somebody in the community who wants to contribute to an open source module that can be rolled into the platform we’d be happy to take that forward. That program is in its infancy, right now we are working through the kinks with select, direct partners. Right now we have an open API environment. All in good time.