Nextmv Cloud overview

This diagram displays some of the core pieces of an optimization application.

Each application has an endpoint that is unique within the context of your account that you can post request to conduct a run of your application. This endpoint is in the form https://v1/applications/{your-app-id}/runs.

In its simplest form, you can get an application up and running on the cloud platform by performing one of the following commands and then running the cli run command on your binary:

• push which takes an application you are building locally, builds the application, and then pushes the resulting executable binary up to Nextmv Cloud. The push operation updates the developer binary. The platform maintains a special “instance” for this binary, and the binary always gets overwritten on a push, so there is only ever one un-versioned developer executable.
• promote which takes the current developer binary, and creates a new version from it. The new version then becomes active on your default application endpoint described above. You can run other binaries however using that endpoint and an optional input argument for the instance ID.

When running an application, not just the application is used, but an application version, and an application instance as well. Although this isn't exposed, there's a hint of this in the output when you create an application. There's a default instance id that is empty on the first run:

nextmv app create \
    --app-id 'pizza-delivery' \
    --name 'Pizza Delivery' \
    --description 'My pizza delivery app'

after you promote your application, the instance id is defined.

nextmv app promote \
    --app-id 'pizza-delivery' \
    --name 'Prod version' \
    --description 'my first prod version'

There are cases where you want to be more specific, here are some examples:

• You are delivering Pizza in NYC and Philly, and you want to use different optimization logic, even though both are part of your pizza delivery app.
• You want to see the runs that you’ve done recently in Philly only
• (future) You want to test a new version of your Pizza app before you move into production, and you want to make sure it doesn’t get updated while you are testing. Once you are happy with it, you just want to move that version into production.
• (future) You want to have different configuration settings for your optimization in NYC than in Philly

The best way to think of an application is a container for all of the assets used to solve a particular problem for your business. For example this would contain all of your run history, all of the versions you’ve defined, test results, etc. It also represents an endpoint to which you can submit runs for your application.

An application version represents a specific executable binary. While you can update the name and description of a version, you can’t change the referenced executable. This provides a mechanism to explicitly manage behavior throughout the app management process.

An application instance is a representation of a version and optional configuration that you want to use in some context. The same version can be used by multiple application instances. Examples include:

• You want to have different behaviors for an app version and configuration depending upon some criteria, like geographical area. You can specify different app instances for each area.
• You want to test two different app version/configuration combinations

When running an application, you specify an application instance. If no application instance is specified, then the endpoint will run the default application instance. If no default application instance is defined, then the run will fail. In future releases, application instances will be exposed directly, providing you with more flexibility.