Overview
A deployment strategy needs to be decided on early in the process as this will drastically impact how the software is maintained in the future.
Embedded deployment can be thought of as two parts: content strategy and environments.
Content strategy involves keeping track of which software goes to which client. Environments involves where the clients’ software will live once it is in a live state.
When managing different clients there are three strategies, which are listed below.
Content Strategy
Do you want all clients to receive all updates? Or are there exceptions?
Strategy 1: Monolith – Logical Tenancy
A single Project is created on the Development server. It is fully featured and goes to the client as is.
There are two ways around the customization issue. One is that the Project can contain specific methods that give the client access to what designer elements they can and cannot use.
The second is to maintain separate branches within the Repository for each client. That way clients do not have to be upgraded when a change is made to the monolith Project. They can be opted in as needed. This method can become cumbersome depending on the number of clients.
Another issue to consider is that there is typically only one Production environment with this model. Client projects will be logically separated, but streams of incoming data will occupy the same physical server. It is possible to maintain separate servers for specific clients to give physical separation, but this can become costly.
To learn more about logical multi-tenancy, see Multi-Tenant Architecture.
Positives
- Easy development/maintenance
- Easy deployment
Drawbacks
- Very large deployment package
- Upgrade for one client causes downtime for all
- Customization is possible, but difficult
Strategy 2: Shared Resources
In this method each customer has a separate Project and there is a main Project that contains resources that are shared. The shared resources could be a Subflow or a generic Rule.
This way customers can have their own internal logic that builds off of the shared resources without there needing to be individual copies that each are maintained. Whenever a change needs to be made to the shared resource it is only made once and it is instantly passed to each customer.
For example, in a back office context, a company has a standard process for onboarding new employees. This is a single Flow that handles various logic to make sure that an employee receives an email address, is set up in payroll, and etc. Now individual departments have specific needs as they onboard employees. Each has their own Project that handles their onboarding, drawing on the original flow referenced earlier. However, the Accounting department requires that their employees take anti-corruption training. The Engineering team needs their new employees to receive special equipment. The unique needs of each department are captured in their individual Projects by adding Steps after the shared Subflow.
Positives
- Downtime is only for specific clients getting upgrades
- Flexible
- Cost efficient
- Less work
Drawbacks
- Works best in container environment
Strategy 3: Clone
With this option a copy of important designer elements are copied. Currently there is no way to clone a complete Project, however each designer element in a Project can be copied and either kept within the same overall Project or added to a different Project.
Two ways of handling this would be have individual Projects for each customer, or to have separate Designer Folders for each customer within the original Project.
This allows a very straightforward deployment strategy where each clone has its own change management system. As a client is added, the generic Project is cloned on the development environment. Then the clone is passed to the Repository, and then to its Production environment. Because the clone is a completely independent Project it can be used on its own server or container.
The downside is that updates are not easy to pass along to the clones. Whatever changes are made to the generic Project will need to be manually made in all of the clone Projects. There are no shared resources. If the number of clients is large, this can become a daunting amount of work. However, the silver lining is that each Project can be customized to specific requirements.
Positives
- Simple deployment
- Physical separation possible
- Changes customized to each client
- Client specific downtime
Drawbacks
- Each Project will need to be modified separately
Notes
Conceptional clones – big picture is just copying flows and designer folders
Within the Project copy the designer folder
How do I handle
Option 2
Reference some commonality and bolt on additional resources
Other considerations - if there's going to be custom version of a flow for a user they can't be on the same server or in the same cluster
how to deploy a server as a group of clusters and how they interact with each other
the same flow can't be unique and callable by multiple people