Orchestration of Sandbox Environments

Automatic creation of the "sandbox environments" layouts is very interesting use case. For the simplicity of this explanation, let’s take the problem of the state management and data-seeding out. It is a topic of a much larger conversation. So let’s assume here we’re not managing data and state and the sandbox environment will be relying on the existing configuration.

Let’s say you need to create a sandbox environment that is described by the following BoM manifest:

[
   { "id": "app1", "version": "2.0" },
   { "dependencies": "integration_environment" }
]

The orchestration sub-system talks to Accordance and identifies that the "app1" dependent on "app2" and "db1". Let’s say the right versions of the dependencies are present in the "Integration" environment. In this case the orchestration needs to deploy only the "app1" artifact version 2.0 and terminate the rest of the dependencies in the "integration" environment.

In the case where the BoM of "app1" specifically requires different versions of the dependencies, the system will identify that it can’t satisfy the requirements and will recommend to the orchestration to spin up the missing dependencies and still reconcile the dependencies at the provided environment.

In this example, "app2" is not present and the orchestration will spin up both "app1" and "app2":

[
   { "id": "app1", "version": "2.0" },
   { "id": "app2", "version": "3.0" },
   { "dependencies": "integration_environment" }
]