Solum/FeatureBlueprints/Definitions

Assembly: An application at runtime. This is a collection of all the Components of an application. Think of this as the running application including all the stuff it relies on (databases, load balancer setup, etc.). Every Assembly has at least one Component.

Component: A part of your application that you want to be able to manage through Solum (start, pause, resume, delete, etc.). These are grouped into an Assembly.

Service: Something offered by the platform which can be referenced as part of the deployment plan. These often become components when the application is deployed. Some services will run / host / be configured by artifacts supplied by the user (e.g. a database initialised with a SQL script, or a web container hosting a WAR file), whereas some will not require any such artifact (e.g. an object store). Services may run in a single OS container, or they might run in multiple OS containers (elastic or otherwise), or they might be completely external.

Sensor: The Sensor resource represents dynamic data that can be collected from a resource through the API. For example, statistics about the access rate of a resource (usually a Component). Sensors can be added to Assembly, Component, or Service resources.

Operation: The Operation resource represents an action that can be taken on a resource through the API. Operations can be added to Assembly, Component, or Service resources.

Deployment Unit: (or OS container ?): A deployment unit (DU) is a unit of deployment for the application being deployed into an Assembly. For example, if Solum is configured to use containers for deploying application code, then the a DU would refer to a container instance. A deployment unit could be a Docker container, an LXC container, a VM, or something else. (NOTE: I've suggested "OS Containers" instead, as that means something to me in a way that "DU" does not. BTW my reading of the word "container" is a web container, not an OS container!)

Plan: A description of how to generate an Assembly to run an application. (Sometimes called a deployment plan.)

Build: A Solum service that builds/tests the Application in accordance with the instructions in the Plan to produce an Artifact for deployment. The Artifact generated will normally be a container image to be used within the DU.

Repo: A hosted location where the source code for an application is stored. It may be internal to Solum, or externally hosted through a supported SCM API.

Application (proposed): An application represents the raw ingredients of an application, i.e. the things which become an Assembly. It consists of a Deployment Plan plus a set of artifacts or a code repository and build instructions. It may also link to the assemblies generated from it (which may be more than one in different environments -- e.g. dev/staging/prod -- when we get in to lifecycle management).

Common actions

• Register: registers a new application in Solum and associates it with the user ( no application code is copied; no deployment is performed, yet).
• Deploy: deploys the application bits and generates a running application in an Assembly. Associates dependent services as needed. Builds the application bits from code if required.
• Build: builds the application, but does not create an Assembly to run it in. This is used for build-once-deploy-many use cases.