Overview

Overview

The application enables users to deploy packages and execute services utilizing compute resources and data available within the DDOE platform. Designed for flexibility and scalability, it empowers users to meet diverse operational requirements while streamlining and automating complex workflows. Usage of this application consumes from the Serverless Automation budget. Functions run in the Application framework often make extensive use of DDOE Python SDK, to interact with the platform. For detailed SDK guides, read here.

• Package (DPK): A Package is a collection of static code with a schema that holds all the Modules, functions, and the code base from which they can be taken. Packages are used to build models or deploy services and refer to an entity that is processed using the application technology. Packages can be public, global, or specific to a particular Project and are limited to a maximum size of 100 MB.

• Function: Functions are the basic functional units of application. You can define the functions in the class, and when the service is deployed, you can run any of them. Functions are defined within a module, and multiple functions can be an access point to the application.

• Service: A serverless computing service allows users to run code without the need to manage servers or infrastructure. It can also be conceptualized as a deployed package that serves the code. When provided with the matching input for a function, it runs and returns the output.

• Application: An application is a software that is built using the Function as a Service computing model. In this model, the application's functionality is implemented as individual, independent functions or pieces of code. Each function is designed to perform a specific task and is triggered by events such as user actions, incoming data, or time-based events.

Package

A Package is installed by uploading files or connecting the codebase from Git.

• Packages should have a well-defined class structure.

• Classes contain different functions.

• Modules translate and define classes.

Service

A Service is a package deployed using defined compute resources.

• Init method – Runs on service initialization.

• Execution – Function invocation on items or other entities is considered an execution.

Trigger

The Trigger is a service configuration for automatic invocation of items (or other entities) to functions based on schedule or event criteria.

• CRON Trigger – Schedule-based trigger.  For example: every 1 hour, 1 day, etc.

• Event Trigger – Criteria-based invocation.  For example: when the item is created, updated, deleted, etc.

UI Slot

UI Slots are predetermined locations/buttons in the Platform. Assigning a function to one or more specific UI Slots allows users to invoke entities in context (items, annotations, datasets) to the selected function.
For example: Assigning YOLOv5 to the Annotation Studio allows running the model on the item and generate annotations._

Prerequisites

• Working with DDOE SDK requires having Python installed with the Dtlpy package.  Read these instructions for more information.

• Using Applications requires being a member of an Organization.  To become a member, ask a manager to add you.

Create Applications

DDOE allows you to create applications using codebase, GitHub repo, custom docker image, and via SDK.

1. Open the Marketplace from the left-side menu.

2. Click on the Actions > Create Application. The Create Application window is displayed, and edit the following fields:

3. Application Name: Provide a name for your new application.

4. Codebase Type: You can upload the codebase by zip files as Item or providing git URL.

   1. item: By default, Item is displayed. Select the ZIP file of the Codebase.

   2. git: The Git URL is how you locate and clone a repository, while a Git tag is a reference to a specific point in that repository's history.

      1. git URL: Enter the Git URL.

      2. git tag: Enter the Git tag.

      3. Add Secret Credentials: This allows you to add a secret username and password for the Git codebase.

5. Requirements (optional): If your code requires additional python libraries to run, upload a requirements.txt file specifying which python libraries need to be installed. Upload the requirement file (Requirements.txt):

   opencv-python==3.4.2.17

   • Requirements File Upload: Notice that the 'Requirements.txt' file must be uploaded separately from the codebase. You'll find an exclusive button for the requirements file upload in the application creation dialog.

   • Missing Python Libraries: Uninstalled Python libraries will trigger an initialization error, leading to a "Crash Loop - Requirements Error," preventing your application service from start running.

6. Modules consists of multiple functions may be defined in a single package under a module entity. This way, you will be able to use a single codebase for various services (applications). Make changes in the following fields:

   1. Modules Name: Define the module name (no limitations). By default, default_module is displayed.

   2. Entry Point: The main.py file you created should be defined as the module entry point. By default, main.py is displayed.

   3. Class Name: By default, ServiceRunner is displayed. Make changes, if required.

   4. INIT Inputs: Click on the Plus icon to add a new init input.

      1. Name: Enter a name for the input.

      2. Type: Select the type of the input from the list.

   5. Functions: Provide a Name and Description for the function. By default, run is displayed as a function name.

      1. Input: Click on the Plus icon to add new input. Enter the input name and select the type from the list. By default, item is displayed as the name and type of the input.

      2. Output: Click on the Plus icon to add new output. Enter the output name and select the type from the list. By default, item is displayed as the name and type of the output. Provide an action name, if required.

7. Add default app configuration:  Click App Config, and make changes in the following fields:

   1. Machine Type: Specifies the type of virtual machine (VM) to run your service.By default, regular-s is displayed. Select a new one from the list, if required.

   2. Create Autoscaler: Enables DDOE to automatically scale the number of running service (computing resources) replicas based on load.

      1. Min Replicas: This refers to the minimum number of instances (or "replicas") of your function that will be running at any given time, by default, it is set to 0. Make changes, if required.

      2. Max Replicas: This is the maximum number of instances that your function can scale up to. By default, it is set to 1. Setting it to 1 means your function will have at most one instance running at any time. Make changes, if required.

      3. Queue Size: The number of events or requests waiting to be processed. By default, it is set to 100. Make changes, if required.

   3. SDK Version: Defines the version of the DDOE Python SDK used in the service environment. By default, the latest SDK version is displayed. Click Update SDK Version to update the new version, if available.

   4. Module: Select a model from the list. Modules are a reference to a Python file containing the Python class (by default, ServiceRunner) with functions inside it.

   5. Concurrency: Maximum number of concurrent function executions a single service instance can handle. By default, 10 is displayed. Higher values can improve throughput but require more resources.

   6. Execution Timeout:  Maximum time (in seconds) a single function execution is allowed to run. By default timeout  is 3600 seconds.

   7. Drain Time: To ensure the completion of parallel running executions before terminating the pod, provide a Drain Time delay. After this designated period, the execution restarts. By default, 600s is displayed. Useful during scaling down or reset events.

   8. On Reset Action: An "On Reset Action" setting is related to how the application should respond when a specific trigger or condition necessitates resetting the state or execution of a function. Select one of the following when you reset the execution. By default, failed is displayed.

      1. failed: When the action is set to Failed for a reset condition, it implies that if the function encounters an issue requiring a reset (such as an execution error or a timeout), the system will mark the execution as failed. This option is typically used when it's critical to acknowledge that an error occurred, and it needs to be notified of the failure. Choosing Failed is appropriate for workflows where failure requires manual intervention, or where it's important to maintain strict error reporting and auditing.

      2. rerun: Setting the action to Rerun means that if the function hits a reset condition, the system automatically attempts to execute the function again. This approach is useful for handling transient errors or temporary issues that might not persist in a subsequent execution attempt.

   9. Max Attempts: Maximum number of execution attempts allowed. By default, 3 is displayed.

   10. Bot: A bot is a dummy project user with 'Developer' role permissions used for running services. By default, the latest Bot is displayed. Select a new one from the list, if needed.

   11. Docker Image: Specifies the Docker environment used to run the service. Provide your private or public docker image registry URL.

   12. Secrets and Integrations: For the private docker image integrations, attach cloud credentials (like AWS, GCP, Azure) or API keys required by the service. Select a secret or an integration from the list, if available. Otherwise, click on the + icon to create a secret for your application:

       1. Secret Name: Provide a name for the new secret.

       2. Secret: Enter the secret key.

       3. Provider: Select the provider from the list.

       4. Click Create Secret.

   13. Is service global: Makes the service accessible across multiple projects.

   14. Preemptible: Uses lower-cost, preemptible VM instances. It might be interrupted, but is cost-effective for stateless or non-critical tasks.

   15. Run service execution as process: Forces each service execution to run in its own isolated process. Useful for memory-heavy or isolated function needs.

8. Click Confirm.

9. Click Create Application. A success message is displayed, and the new application will be available in the Applications tab of the Marketplace.

Using Item Codebase

To create applications using the Item Codebase:

1. Open the Marketplace from the left-side menu.

2. Click on the Actions > Create Application. The Create Application window is displayed, and edit the following fields:

3. Application Name: Provide a name for your new application.

4. Codebase Type: By default, Item is selected.

   1. Click Select Codebase and upload the codebase as zip files.

5. Continue the steps available in the Create Applications.

Using Your GitHub Repo

To create applications using your GitHub Repo:

1. Open the Marketplace from the left-side menu.

2. Click on the Actions > Create Application. The Create Application window is displayed.

3. Make required updates in the following fields:

   1. Application Name: Provide a name for the new application.

   2. Codebase Type: Select the git from the list.

      1. git URL: Enter the Git URL. The Git URL is how you locate and clone a repository.

      2. git tag: Enter the Git tag. It is a reference to a specific point in that repository's history.

      3. Add Secret Credentials: This allows you to add a secret username and password for the Git codebase.

   3. Continue the steps available in the Create Applications.

Using Custom Docker Image

To create applications using Custom Docker Image:

The UI provides a straightforward way to create an application and connect your custom docker images through Docker registry integration. Perform the following process to complete the creation:

1. Prerequisites:

   1. Integrate Your Docker Registry: Connect your own registries, such as:

      1. AWS ECR

      2. GCP - GAR

      3. Docker Hub Container Registry

2. Create Application

3. Link Your Docker Image: While you create, provide the URL of your Docker image in the App Config -> Docker Image field.

4. Continue the Create Application steps.

Using SDK

• To create applications using the SDK, refer to the Your First Application

• To create custom docker image applications using the SDK, refer to the Using Customer Docker

Create Model Applications

The UI provides a straightforward way to create an application and connect your custom model through Docker registry integration.

1. Integrate Your Docker Registry: Connect your own registries, such as:

   1. AWS ECR

   2. GCP - GAR

   3. Docker Hub Container Registry

2. Create an Application

3. Link Your Docker Image:

   1. Provide the URL of your Docker image and link it to the application while creating the application.

   2. This enables DDOE to use your custom model for tasks such as predictions, training, and workflows.

   3. To update the docker image URL: While you create an application, in the App Config section, update the Docker Image field with your docker image URL.

4. Continue the Create Application steps.

Install Applications

DDOE allows the installations of applications by allowing them to be hosted and executed on:

• DDOE's Managed Compute (internal infrastructure): The Applications run on the DDOE's Compute.

  

• External Compute Providers (e.g., OpenAI, Azure, GCP, IBM, NVIDIA) via API Service Integration: The Applications run on external provider's compute, which requires secret credentials to complete the installation.

  

Install Applications Running on DDOE Compute

When applications run on DDOE’s internal compute:

• DPKs (DDOE Processing Kits) are deployed directly by DDOE, requiring no external authentication or cloud service integration.

• The application is fully hosted, managed, and executed within DDOE’s secure and scalable environment.

• This setup is ideal for customers seeking a hassle-free solution without the need to configure or maintain external cloud resources.

• All necessary compute resources (e.g., CPU, GPU) are provisioned and managed by DDOE, with billing handled directly through the DDOE platform.

To install, follow these steps:

1. Open the Marketplace from the left-side menu.

2. In the Applications tab, use the Deployed By filter from the left-side menu to filter the application.

3. Select the application that you want to install.

4. Click Install from the right-side panel. The Install Application popup window is displayed, and it lists all the application functions available in the DPK with a description and indicate if the selected application is deployable or not.

5. Click Install Application. A confirmation message is displayed, and click on the View Application to view it under the CloudOps -> Services tab.

Once you install an application, there is a green tick icon is visible on the application that is installed in the Marketplace -> Applications.

Install Applications Running on External Compute

DDOE allows customers to run applications on third-party infrastructure (e.g., OpenAI, Microsoft Azure, Google Cloud, IBM) through an API Service integration. Instead of running on DDOE's internal compute, these applications operate on the customer's own cloud account.

• DPKs are deployed by the external provider, and compute tasks (inference, training) run outside DDOE.

• A lightweight API wrapper within DDOE bridges the platform to the external application endpoint.

• Customers to provide access credentials, enabling secure, seamless integration.

• Compute costs are charged to the customer’s cloud provider, not DDOE—this leverages existing billing accounts and avoids new payment setups.

• Customers can bring their own applications from platforms like Google, IBM, or custom-hosted APIs.

• It is possible to complete the installation by selecting the Set up later option, these models will remain inactive and cannot be used until the necessary integrations are fully configured.

1. Open the Marketplace from the left-side menu.

2. In the Applications tab, use the Deployed By filter from the left-side menu to filter the application.

3. Select the application that that runs on an external compute.

   

4. Click Install from the right-side panel. An Install Application popup window is displayed, and it lists all the available functions specified in the package module with a description.

   

5. Click Proceed. The select secrets pop-up window is displayed.

   

6. Select a secret or an integration, as required. If not available,

   1. If there is no secret, click Add New Secret and follow the steps.

   2. To set the integration later, click Set Up Later.

7. Click Install Application. The application is installed and available in the CloudOps -> Services tab.

Once you install an Application, there is a green tick icon is visible on the applications that are installed.

Set Integration Credentials

To set Integration Credentials for the installed applications of external compute providers:

1. Open the Marketplace from the left-side menu.

2. In the Applications tab, select the installed application.

3. Click Actions from the right-side panel and select Edit Access Credentials. The Edit Application pop-up window is displayed.

   

4. Select the secrets or integrations as required.

5. Click Save Changes.

Install Pipeline Node Applications

1. Open the Marketplace from the left-side menu.

2. Select the Applications tab.

3. In the left-side filter -> Application Type, select the Pipeline Node.

4. Select a pipeline node from the list according to the requirement.

5. Click Install from the right-side panel. The Install Application popup is displayed.

6. Click Install Application. The node will be installed successfully, click View Application for more details.

Activate or Deactivate Applications

Installing an application activates the application. Once you install an Application to your project, the application becomes activated. Learn how to Activate or Deactivate.

Organizational Applications

Organization-level applications allow administrators and developers to deploy applications that can be shared and reused across multiple projects within the same organization. Unlike project-level applications, these applications are installed once at the organization scope and are deployed to the organization's System Project.

Once installed, the application becomes available to projects within the organization, providing a centralized way to manage shared services, workflows, and integrations.

Benefits

• Create and deploy applications at the organization level.

• Share applications across multiple projects within the organization.

• Enable application services to access data from projects across the organization, based on the applicable permissions.

• Reduce duplicate application deployments by maintaining a single organization-wide installation.

System Project and Organization Files

Each organization has a dedicated System Project that contains a Binaries dataset used to store organization-level files, deployment packages (DPKs), and application resources.

Access to files in the System Project is controlled by user roles:

Deployment Rules

• Organization-level DPKs and applications are stored and managed centrally within the System Project.

• A DPK can be installed only once at the organization scope, by adding scope = ‘organization’ in the app json

• If a DPK is installed at the organization level, it cannot be installed again within one of the organization's projects, and vice versa.

• Organization-level applications follow the same authentication and authorization model as organization-level DPKs.

Supported Codebase Sources

The application codebase can be sourced from:

• Stream-based codebases (Org or Public scope)

• Git repositories

• Items stored in the organization's System Project

IP Address Whitelisting

Hosting Applications on a remote server or having applications send data/events to one may require whitelisting the IP addresses used by the DDOE system.

Whitelisted IPs:

34.76.183.75  
104.199.5.216  
35.241.168.191  
35.240.12.251  
34.78.187.121  
34.78.238.94  
34.78.5.89

GIT Reference & Examples

For Application-related developer tutorials and examples, refer to Dataloop GIT tutorials.

Annotation Automation

Examples of functions that perform automation on items and annotations.
There are 3 functions in this package:

• Box to Segmentation – Receives a box detection annotation and an item and returns a segmentation of the detected object.

• 4-Points – Receives a 4-point Polygon that represents object edges and returns object segmentation.

• Auto Annotation – Receives and auto annotates an item using Maskrcnn.

git clone https://github.com/dataloop-ai/annotation-automation.git

Image Exif

Example of a function that extracts image Exif information and uploads it to item's metadata.

git clone https://github.com/dataloop-ai/image-exif.git

Video Tracker

Example of functions that track bounding-box annotations:

git clone https://github.com/dataloop-ai/video-tracker.git

More References

• Application Concepts

• Application Creation Guide

• Custom Docker Images

• Using External Credentials (Secrets, Token Keys, API Keys, etc.)