Automatic Scaling
A cloud enabled architecture must be well adapted to a virtualized hardware environment, where it is expected to be cost-effective and utilize only as much hardware as is needed at any point during the day. Effective management of micro-services is key.
Scaling in PE is achieved by multiplying ECD definitions, containing one or several workflows. The workflows can be based on the same or any number of different configurations. The configuration, behavior and management differs when scaling ECDs for realtime versus batch workflows.
Realtime
- Realtime workflows typically execute continuously.
- An ECD configured to run dynamic realtime workflows will always be up once started. A user can configure minimum and maximum number of ECDs to run simultaneously. Even if a workflow aborts, Kubernetes will restart it until it is manually attended to.
- Scaling out and in of the ECD is automatic, and based on thresholds of configurable metrics. For instance CPU load.
Batch
- Batch workflows typically execute periodically.
- An ECD configured to run batch workflows needs to be started before the workflows are scheduled to start.
- Scaling of batch ECDs is based on triggers. For instance; starting periodically, and stopping when workflows have finished processing all files.
Image below shows an example of a deployment in AWS, where Fargate hardware virtualization service is used when executing batch workflows that are scheduled a couple times a day. Realtime workflows that need to be executing continuously, are deployed on an EC2 instance. Any combination is possible - only EC2s, only Fargate, or a combination, depending on the price and/or architecture of preference.
