How to build a simple edge cloud: Q&A
Nick Chase - March 05, 2020
Last week we held a webinar explaining the basics behind creating edge clouds, but we didn't have enough time for all of the questions. So as is our tradition, here are the Q&As, including those we didn't get to on the call.
That said, there are some cloud native network functions, or CNFs, that are already available, such as Magma.
A cache registry is setup to keep a copy of each image requested by engines in your environment, so that duplicate requests can retrieve the image locally instead of downloading it again and again.
Read docs on Registry configured as Cache or Mirror: https://docs.docker.com/registry/recipes/mirror/
As far as latency, that's one of the things you're trying to mitigate with Edge in the first place; so while it might be too much to send an entire video stream, you might send just specific frames. Or perhaps you might send just specific measurements instead of complete telemetry, doing the initial analysis on the Edge node.
Don't forget, you can view the whole webinar here!
Does Docker Platform support GPUs?
Docker Engine 19.03 added support for GPUs. Also, we are working on adding features that make GPU availability visible for orchestration.
What's the difference between Docker and Docker Enterprise?
Docker CE or Community Edition is a free containerization platform managed by Docker, Inc.
Docker EE or Enterprise Engine is an integrated, fully supported and certified container platform, owned by Mirantis.
Docker EE is part of the Docker Enterprise platform, a suite of solutions to help manage and deploy applications securely which includes: Docker Trusted Registry, Docker Universal Control Plane, Docker Content Trust, and Docker Enterprise Engine.
So how would an edge device know where to contact the edge cloud? Would it be hard-coded?
It certainly COULD be hard-coded, though I personally would have the device call home just to find out where it should go for its actual configuration.Is it passing the video data to the Google container, or is it passing a container to the Google platform?
The idea is for an edge node to pass only the important data to the next step (in this case the Kubernetes cluster running on GKE). So in this case, the container running in the simulated camera is passing only individual video frames to the container that's running in the regional cloud.To access an application that is present on an Edge Cloud, for example, through a Mobile Network, a GATEWAY (e.g., PGW, UPF) is required. The question is: Are these Network functions ready to run in Containers? Do containers offer the necessary security for such Network functions?
In fact, many of these virtual network functions, or VNFs, have not yet been containerized, and need to run in Virtual Machines. One way to do this is to use a project like Virtlet, which enables you to run VMs as first-class citizens in a Kubernetes container; this way you can use VMs and Containers together.That said, there are some cloud native network functions, or CNFs, that are already available, such as Magma.
In the demo, you used AWS and GCP, where did Mirantis come into the picture?
In this particular example, the AWS piece was where we were running Docker Enterprise, which is now part of Mirantis. However, the discussion is purely on the technology; Mirantis isn't REQUIRED (though of course we would like you to consider it :)). Mirantis also has an Edge offering, Mirantis Cloud Platform Edge, that uses a different architecture.In your demo, may I say the edge cloud is running at your NB?
I don't quite understand the question, but the edge cloud in this case was a container running on my laptop, yes.Can you please explain again about the mirror registry and cache?
A mirror registry is a registry that holds images you expect to need in your environment. The idea is to bring images closer to your nodes so they can fetch them quickly and more efficiently than having each engine fetch a copy on the external network.A cache registry is setup to keep a copy of each image requested by engines in your environment, so that duplicate requests can retrieve the image locally instead of downloading it again and again.
Read docs on Registry configured as Cache or Mirror: https://docs.docker.com/registry/recipes/mirror/
You show as the UCP, but for the edge it seems very expensive to have a worked node with Docker EE, could you do this with Basic or Community engine at the edge, and still put your Image on Docker Trusted Registry?
Today, only Docker EE can pull from DTR. With Community Edition, you are missing key security features that are required to secure the last mile. If you have a need for a more efficient (reduced size) engine due to constraints in your device, please contact us for assistance and we will review your use case and offer advice. That said, if you're not going to use DTR, you could use Docker CE.So, video data isn’t passed to the central Google location, it is the central location that pushes approved images to the edge and the edge does all the facial comparison?
No, it's just the opposite. The edge recognizes that there is a face, but doesn't identify it. It just passes the image on to the "regional" cloud. The regional cloud, which happens to be running on GKE in this case, does the facial comparison, and if it finds a stranger, passes that image on to the "central" cloud, which happens to be running on Docker Enterprise on AWS in this case. So the flow of data is from the edge to the center.Can you take an example of configuration pushed to a camera device or a CPE device connecting a branch location? Like Walmart with CPE or Camera monitoring cash registers?
I'm not sure I completely understand the question, but I'll take a stab at it. Devices can be updated via either push, or pull. In a push situation, the central cloud sends instructions to the edge device. These instructions may include the new configuration, or they may simply include instructions to phone home for that new configuration. In a pull situation, the device will "phone home" to check for any instructions or configuration changes it needs to complete.There is another situation. We could have an ARM processor at the edge, and I believe there is not Docker EE engine in that case, but you could have development for an ARM processor on the Cloud.
Docker EE has been tested on Arm architecture and is ready for POC with customers. This applies to both cloud and Edge instances of Arm. Please contact us if you need more information on this use case.My question is around multi-tenancy. How can multiple enterprises push configurations to the end CPE or Camera devices with a multi-tenant central controller hosted in Cloud? How can we build a hierarchy to address latency aspects?
This one might require more questions about the use case. In general, multi-tenancy starts with the ingress of applications in the registry. Here, multiple images are received, scanned, and staged before they are deemed acceptable and made available to the end device. These images can come from multiple sources including Independent Software Vendors. From the controller interface, the operator can securely deploy these apps on the end points running a container runtime such as Docker Enterprise. The Hierarchy that is built to address latency is accomplished by moving the applications that process the data closer to the source of data creation and minimizing how much of this data is moved on the network. Then, if you can react to the output without having to go through a central hub, you can keep the latency as low as possible.At the edge device, do you actually install Docker and run a container in the device memory itself? If yes, what would be the memory footprint in the device's memory for docker?
Yes, the Edge device is expected to have a Container runtime engine such as Docker Enterprise Engine. We have done work with customers to reduce the impact to memory while maintaining the security features required to ensure an end to end secure environment. If you want more details, we'd need to review your specific use case.Can you compare running Docker and containers on the edge device versus an application written in a microcontroller language with the same functionality as the app running in the docker container alternative?
There is no impact to system performance due to running an app in a container versus directly on the OS. There is an overhead due to memory requirements. The question to ask is whether the use of containers in an end device with all the cloud native advantages outweigh the need for additional memory. As you can imagine the answer depends on the use case.Today there are several frameworks being proposed to provide HW management for Edge Clouds such as: OpenStack DCN, Mobile Edgex, Akraino etc. Does this heterogeneous environment tend to converge to a single solution? Which in your opinion?
Like most similar decisions, this is going to depend on too many factors to make a decision like this, including use case, staff familiarity, integration with the rest of your infrastructure.If the application's data is not ready yet at the edge how will the edge app behave?
That's the job of the Edge application; to deal with these issues so the processing closer to the center doesn't have to.Is the Python code available?
Yes, the Python code will be available as part of the "Build a Basic Edge Cloud" blog series. You can find part one of that series, which covers the actual surveillance system, here. Part 2, which is due out in the next few days, covers containerization, and part 3 will deploy the containers to their respective clusters.What does the demo app use to pass the vid images and approved pics back and forth between edge and central? Is mirroring the best or are you using like a restAPI push to where it needs to go?
In the case of this demo, it's using a mounted drive to pass images from the camera to the first container, and then it's using a REST API to pass images between clusters. Not that this is the ONLY way to do it, by any stretch of the imagination; it's just the simplest way to get the concept across.Will this example work with open hardware such as Arduino ?
I'm assuming that your question is whether you need an Arduino to do this, or whether it will work with open hardware. In fact I've never used an Arduino (though I really, really want to), so I can confidently say that edge doesn't depend on it. That said, your actual Edge Devices may have specific requirements, such as durability or low power requirements, but that's based on your specific use case and not Edge per se.What kind of edge nodes are you recommending if any? Thinking of high latency links where sending data to any cloud or out of the edge DC would be an issue.
It all depends on your use case. In some cases you may need specific hardware that fulfills a particular requirement, such as low power use or remote accessibility, or it may be a simple laptop or even a mobile phone. Remember, anything that's outside of a datacenter is technically "edge".As far as latency, that's one of the things you're trying to mitigate with Edge in the first place; so while it might be too much to send an entire video stream, you might send just specific frames. Or perhaps you might send just specific measurements instead of complete telemetry, doing the initial analysis on the Edge node.
How do you write that security system for kubernetes just mentioned?
Check out the white paper about Trusted Docker Containers.Don't forget, you can view the whole webinar here!
