What's on this page

Deployment Model


This section introduces the deployment architecture and main configuration options for Stratoss™ Lifecycle Manager (LM) for a typical CICD configuration. It is expected that multiple Stratoss LMs will be deployed to automate the various tasks for each stage of the CICD process. Each set of LMs are coordinated around a repository of artifacts representing the external resources under management. The picture below shows a typical deployment. See here for more information on a typical LM CICD process.

Logical Deployment Architecture

The following logical functions are typically deployed together to deliver a complete CICD pipeline:

Each LM environment will also require a working Resource Manager.

Development and Production

Production LM environments must be installed to an existing kubernetes cluster using Helm. However Development LM environments can either be deployed to an existing kubernetes cluster or using an Allinone installer a fully working lightweight deployment can be deployed on a minimal linux server or virtual machine.

Logical Deployment Architecture

The Allinone LM deployments can be run on a standalone server or a laptop and can interact with a CICD Hub to do early resource development.

Deploying across multiple clusters

The LM environments required to deliver a complete CICD pipeline can be deployed to a single kubernetes cluster or individual LM environments can be deployed to separate kubernetes clusters.

Multiple Clusters

If deploying more than one LM environment to the same kubernetes cluster, consideration must be take for namespace and port conflicts. Also it is recommended a reverse proxy or a domain name server is used in front of the kubernetes clusters to access each individual LM instance.

Cluster storage configuration

For production deployments a kubernetes storage class can be provided or the default will be used. For Development Allinone deployments, no storage class is required. A development Allnone environment ties down the kubernetes version and common options to make the footprint as small as possible.


How to design your Lifecycle Manager Deployment

When designing your deployment there are a number of things that need to be taken into consideration. Some will be specific to your environment and to corporate policies, as such they may not be covered. Others are more universal and we will consider them here.

Typically an LM deployment will have the following environments:

Binding the individual LM Deployment Environments is the CI/CD Hub. This provides a common, secure, resilient and managed repository for all the artifacts of projects from which they can be deployed as required.

A typical deployment will have all three environments;


Use of namespaces

Namespaces can be a useful tool to allow the use of a single cluster to tbe used to support the deployment of multiple LM environments while maintaining isolation. This can potentially allow

In some cases customers chose to have a single LM env on the production cluster to ensure full isolation and the provision of the maximum set of cluster resources to the production instance.


LMCTL is typically present on a Jenkins slave to aid the CICD enviroment. However in the case of a designer where they are working from a local version control repository (git) then the designer will likely have their own LMCTL installed on the local machine for deployment to their development/design environment. This removes the burden of maintaining the full set of environments within the CICDhub which can be somewhat onerous when an ephemeral design env model is adopted.


When engineers are designing resource and assembly descriptors and packages they will need to have access to an LM instance where they can perform testing. For individual designers the LM environment will ideally need to be connected to a deployment location on which the descriptors can be tested.

The advantage of having multiple environments is that designers are able to debug assembly packages and perform destructive testing isolated from other users.

It is possible to spin up a design environment for specific cases and by connecting it to the CICD environment publish the results to make it available to other users. This has the advantage of allowing a user to have a repeatable, clean environment in which design and testing is performed. The cost of the LM design deployment is relatively low. The higher cost is likely to be in having an environment to which resources can be deployed during this phase.

At the higher end of cost is where each developer has their own deployment location. This provides the most isolation. However typically this is not required and individual developer/designer tenancies/projects in a shared VIM is sufficient allow developers to remain isolated.

The number of design environments required is a function of how many designers an organization has have and the nature of their work and is likely change over time potentially scaling down after the first phase of LM adoption.

A design environment will typically be a small allinone deployment. This is particularly true if an organization chooses to provide designers

It is imperative that in cases where unique ephemeral environments are used for individual designers that a CICDhub be deployed as a shared resilient repository across

Pre-production/ Staging

The pre-production environment which can be used for a number of functions

- Performance of consistent/certification testing as part of the CICD process
- Production behaviour is reproduced
- What if testing

In the use cases for LM a mirror of production can be difficult to attain. While the deployment of LM itself can be mirrored without issue the number and type of deployment locations/VIMs can be a prohibitive and impractical cost in many of not most applications.

A pre-production environment may be either a full replica of Production or a scaled down version. It will be fully functional but may for example omit High Availability and the capacity of a production environment.


Production is the final environment this should be commensurate with the projected near to medium timescale requirements of the specific deployment. The number of assembler’s and their complexity both in terms of the number of resources and ultimatly the projected number of LM transactions it will perform will determine how large it should be.

A production environment should leverage the High Availability (HA) in Stratoss LM. This will typically mean over provisioning the number of instances deployed for each Stratoss LM service.

Resource Managers

The Resource Manager (RM) acts as an intermediary between LM and the individual VIMs supporting the infrastructure in which LM managed resoruces are deployed. A resource manager may only service a single Stratoss LM instance. That is; An RM should be deployed with access to the Kafka instance used by Stratoss LM and Elastic Search filebeat is configured to pull the set of logs for its LM environs. Therefore care must be taken to ensure valid pairing. Failure to do so can result in anomalous behaviour.

At least one RM must be deployed and onboarded/registered with LM for any assembly design or instantiation to function.

Sizing Guidelines

Sizing Guidelines