What’s “deployment”?

Deployment is the process of enabling pipelines with previously configured triggers.

This enabling can occur both in the test or prod environment. Check it out:

The workflow inside the Platform is composed by 3 phases. Have a better understanding of each one of them:

  • Build

Phase in which the pipelines are built.

Pipelines are constituted by “components”, which are organized by a logical, sequential or parallel structure so that an integration can be made (eg.: transform data and send it to ERP, API or DB.)

Components are processing units with well-defined roles (eg.: make a REST call to a HTTP address). The Platform components can use resources external to the pipeline, such as "accounts" and "globals", that on top of storing one or more pieces of information, also guarantee more security and reuse.

  • Run

Second phase, characterized by the pipeline deployment process. At this moment the pipeline is prepared and made available for consumption or execution. Formed by components and using external resources (accounts and globals), the pipeline is attached to a service that guarantees its execution according to the determined configurations. These configurations determine the pipeline control and processing capacity in the environment (prod or test).

  • Monitor

In the third and last phase is possible to follow the deployed pipelines to analyze, check and track the executions status. That way, data about your pipelines behaviour will be available to support management and operation, enabling you to know, for example, the amount of requests executed with success or failure, the response time and the logs.

Runtime Concepts

Have a better understanding of the main Runtime concepts.

The deployment covers 3 parts. These are they:

  • Replicas

The replicas role is to determine the amount of replicas that will be enabled to attend your integrations, guaranteeing autonomy, concurrent executions and redundancy with high availability.

  • Concurrent Executions

Covers the concept of concurrent executions that each deployed replica supports.

The maximum number of concurrent executions is defined based on 3 deployment size ranges.

  • Size

The deployment size is directly related to the processing capacity and the memory of each one of the replicas.

The 3 deployment size ranges are:

  • SMALL: 1 to 10 concurrent executions

  • MEDIUM: 1 to 20 concurrent executions

  • LARGE: 1 to 40 concurrent executions

For example, if you configure 10 concurrent executions (SMALL) for your pipeline executions, it means that 10 messages can be concurrently processed.

  • Licenses

They are consumed according to the deployment size and number of replicas chosen.

On size SMALL each replica consumes 1 license.

On size MEDIUM each replica consumes 2 licenses.

On size LARGE each replica consumes 4 licenses.

If you have 16 licenses and 1 replica, it's possible to make:

  • 16 deployments SMALL

  • 8 deployments MEDIUM

  • 4 deployments LARGE

Still using 16 licenses, but with 2 replicas:

  • 8 deployments SMALL

  • 4 deployments MEDIUM

  • 2 deployments LARGE

Each deployment can have a different size with a different number of replicas.

Using 16 licenses and 1 replica per deployment:

  • 4 deployments SMALL

  • 4 deployments MEDIUM

  • 1 deployment LARGE

Using 16 licenses and different numbers of replicas:

  • 1 deployment SMALL with 4 replicas

  • 1 deployment MEDIUM with 2 replicas

  • 1 deployment LARGE with 2 replicas

  • Environment

The pipeline execution environments can be:

- prod

- test

When a pipeline is executed in the test environment, it means that its applications can be tested and changed. Consequently, you have a work environment that allows the free building and validations of pipelines before they actually go to production. The test environment proposal is to evaluate the pipeline construction and, for this matter, it doesn’t have the same attendance characteristics of the production environment.

When a pipeline is in the production environment and an evolutive change has to be made or if it presents some failure, we suggest your changes to be made in the test environment and, only after it, the pipeline can go back to production.

Did this answer your question?