Learn what Tiers are and when you should use them
What are Tiers?
Tiers refer to the logical layers or components that make up an application. A tier can be thought of as a distinct functional unit that performs a specific set of tasks. Each tier may be developed, maintained and deployed independently, making it easier to modify or upgrade one tier without affecting the others.
Tier Environments can be considered as sub-environments of a parent environment that can also be called a multi-tier environment.
This parent ↔︎ tiers relationship in Golive can be compared with the issue ↔︎ subtasks relationship in Jira
When should you use Tiers?
Typical contexts in which your should use Tiers:
Many ERP (Enterprise Resource Planning), CRM and other industry-specific software includes a set of modules that are designed to support specific business functions and processes. These modules can be customized and configured to meet the specific needs of an organization.
Each of these modules can be modeled a Tier environment to track specific setups, data sets, status, credentials,… All the modules together are composing the parent environment.
Most famous vendors of module based solutions include SAP, Oracle, Microsoft Dynamics, Salesforce, Temenos and Infor.
Dedicated microservices refer to services that are specifically designed and developed to perform a specific function within an application. Unlike general-purpose or shared microservices, which can be used in multiple applications, dedicated microservices are tightly coupled to a particular application and cannot be easily reused elsewhere.
Each dedicated microservice of an environment can be modeled as a Tier environment belonging to a parent environment.
Prefer modeling shared microservices (that can be used by multiple environments) as standalone environments connected with other environments using dependencies.
Learn more about dependencies here: Environment Dependencies
Add-ons / Plugins / Third party extensions
In an add-on based system, the core system provides a base set of features and functionalities, and users can add additional features by installing third-party add-ons or plugins. These add-ons are typically developed by independent developers or companies.
It is important to ensure that the add-ons are well-designed and tested, and that they integrate seamlessly with the core system to ensure optimal performance and security.
Jira and Confluence are good examples of add-on based systems that should be modeled as multi-tier environments:
1 parent environment to track the Jira instance (version of Jira, url, type of license, number of users,…)
1 tier environment per user installed apps (version of the app, status, settings, owner, administrators, licensing status,…)
A multi-tenant environment is a type of deployment where a single instance of an application serves multiple customers, known as tenants. Each tenant has its own isolated data, configuration, and user interface, but they all share the same underlying application and infrastructure.
In a multi-tenant environment, tenants are typically isolated from each other, meaning that one tenant's data cannot be accessed by another tenant. This is usually achieved through various means, such as data partitioning, virtualization, or access control mechanisms.
Each tenant can be modeled as a Tier environment with its own status, attributes, url,… This Tier environment can then be used to track license status, support tickets, bugs, specific setups,… of each customer.
Hosting multiple instances of the same application for different tenants WITHOUT any mutualized/shared resources is not multi tenancy. In this case prefer modeling each tenant as a standalone environment in Golive.
Multi Market / Multi Regions
A multi-market application is a software application that is designed to serve customers in multiple markets or regions. This may involve offering different product variations, pricing, or user interfaces to suit the needs of customers in different markets.
Multi-market applications are commonly used in e-commerce, where companies sell products or services to customers in different countries or regions. In this context, a multi-market application may offer different product variants, pricing, or shipping options based on the location of the customer.
Each market can be modeled as a Tier environment with its own status, attributes, url,… This Tier environment can then be used to track urls, rollout status, feature activations, dependencies with specific payment & local shipping providers,…
Model Multi-tier Environments
STEP 1 Open Application Settings
In order to add tiers to an environment, you must first setup your application by clicking the “Application Settings” button:
You must have “Manage Applications” permission in order to modify the application settings.
Learn more about permission here: Security & Permissions
STEP 2 Setup Application Tiers
Click on “Application Tiers” tab to setup the tiers of current application:
STEP 3 Add first Tier to current Environment
Click on “Add dependency” button and add your first dependency:
STEP 4 Manage existing tiers and add new ones
Once you have at least 1 tier defined, you can manage all your tiers in the “Tiers” section:
Tiers in Environment Views
You can filter the list of environments by types of parent/tier relationship. Adding new columns to your environment lists allows you to quickly browse and access tiers information:
Tier Environments are filtered by default!
In order to return Tiers, you must enable the “with tiers” option below the environment filter picker: