Custom Applications on Edge

Above: various scientific applications displayed on the Edge workbench.

Why Edge for applications?

Deploying web apps in the cloud is a complex and time-consuming process that requires specialized skills and expertise. Typically, it involves multiple steps, such as setting up a cloud environment, configuring networks, and establishing access management. This complexity can lead to delays, extra costs, and potential risks for R&D teams who need to focus on the science rather than software engineering, infrastructure, and security.

With Edge, all of this is reduced to a simple three-step process:

1. Write your application, and package it as an industry-standard OCI (Docker) container image.
2. Create an application entry in Edge; providing a title, icon, and the name of the container image.
3. When a user clicks the icon to launch the app, Edge automatically downloads the image, provisions all compute resources (CPU, memory, even a GPU if enabled), and launches a private, secure instance of the app.

Edge's pre-configured and secure cloud environment eliminates the need for you to set up and configure your own environment. Edge also streamlines the deployment process by handling all aspects of app deployment, including authentication, compute scaling, and data encryption.

Finally, Edge automates the monitoring and management of your deployed apps, ensuring your cloud costs are optimized and under control.

What applications can run on Edge?

Edge considers two different type of applications:

1. Native Applications
2. Kubernetes Applications

Edge Native Applications

Common use cases include scientific visualization and analysis apps. These benefit from Edge's architecture, in which each user gets their own private instance of the app. That makes it easy to write compute-heavy apps without worrying about scaling or job management. And yes, this includes AI and machine-learning tasks which need a GPU.

In the online examples gallery we provide examples for some common toolkits:

• Streamlit, an easy-to-use framework for building data apps. (official docs)
• Panel, a data-exploration and web-app framework for Python. (official docs)
• Plotly Dash, a low-code framework for rapidly building data apps in Python. (official docs)
• React, the industry standard for building responsive web applications. (official docs)

Below: example app for feature detection, developed using the React framework.

Use case for Edge Native Applications

Edge Native Applications have been designed to support very specific use cases:

1. Allow beginner programmers to easily create an application and share it with their team. By supporting standard frameworks like Streamlit, Panel or Dash, beginner programmers can easily turn a notebook into an application.
2. Low-availability apps (eg a simulator or a prediction tool that is used sporadically). The Edge Native Applications are only running when they are in use, at the contrary of most standard web applications where at least some part of the infrastructure runs constantly. This provides an optimization in terms of cost, maintenance, and monitoring.
3. Web applications that require a lot of compute, memory, or compute and memory (eg apps that do heavy-duty scientific data processing). Edge Native Apps can be started with various compute profiles (number of cpus, memory and/or gpus)

If your application doesn't fit one of those three use cases, it is recommended to develop an Edge Kubernetes Application!

Kubernetes Apps on Edge

Kubernetes Apps on Edge are traditional web applications that run on the Edge Kubernetes cluster but are registered on Edge and have an application tile on the workbench. While Edge hosts and monitors Kubernetes Apps, it does not manage the lifecycle of these applications. Kubernetes Apps on Edge can make use of the features of the Edge managed Kubernetes cluster but also all the managed components of the cloud provider running behind Edge (e.g. database services, video streaming, etc.)

For more details about the Edge Kubernetes Apps, please read Kubernetes Applications.

Basic architecture for Edge Native Applications

Before diving in to the process of developing an Edge Native App, it's important that we review the basic architecture of how these apps work on Edge. Working through the examples will be much easier if you keep this in mind.

As we mentioned above, part of what makes Edge apps special is that each user gets their own running instance of the app. This is in contrast to a traditional web service, where one server is shared among many users. Some things which are difficult or impossible on a shared server become straightforward in Edge. For example, you can run compute-intensive tasks or write to local storage.

There is also no need for user management, handling a sign-in flow, permissions, etc., because Edge makes sure that only the user who launched the app can access it. This is enforced by a combination of Edge's own framework support layer and a (completely automatic) OAuth exchange between the app and Edge.

The image above is a highly-simplified version of the Edge architecture. First you define an app (as we'll see in the next section, by making an app version record). This definition includes the app name, icon, framework support, and a link to the Docker image. Then, when a user logs in and launches the app, they get their own private instance.

Importantly, from the user's perspective, they only have to go to the Edge server and log in. Edge hides all the complexity of proxying, different ports, security, and so on. That includes making sure the app is served over SSL/TLS.

Next steps

The next chapter will walk you through the process of creating a new application.