MediationZone can be deployed in two different ways - classical and containerized. The main difference, is the way a cluster is installed, configured, and managed. The classical version uses DigitalRoute installables, the MediationZone System Topology Registry, and a third party to achieve high availability. The containerized version uses Kubernetes, pre-packaded YAML files and Docker containers. For installation in AWS, the infrastructure files are also provided.
The Desktop also comes in two different varieties; a web version for containerized, while for classical, it is typically installed locally.
The architecture in combination with support for deployment on Amazon Web Services infrastructure, and a wide range of OS platforms, on physical hardware, or in Virtual Machines.
Virtual Machines can be located either on-premises in a VM cluster (such as VMWare vSphere), or leveraging Virtual Machines hosted by public cloud providers (for example AWS EC2, GCP GCE, Azure VM)
The modular architecture enables cost-efficient mediation solutions.
...
In the case of patches or enhancements to the executable, the changes are introduced to the code server that will automatically propagate the change to all parts of an installation (i.e. clients, Execution Contexts etc.). For classical, there are upgrade scripts; while, for containerized, new Dockers are provided.
In the case of changes to the business processes, the changes can be made on a running workflow and will not lead to any downtime of the processing, it will become active the next time the workflow is started.
...
Configuration spaces can also be used for handling backups, to enable rollback of old configurations.
Workflow Mapping to Execution Contexts
Workflows can be mapped to Execution Contexts in several ways. The distribution can be up to the Platform to decide, in which case it can be configured to base it on load or number of workflows already running. A workflow - or a configured group of workflows - can be pre set to execute on particular Execution Contexts. Also, there is the possibility to map one or several Workflow Templates, including how many of each Template's instances that shall be started on a ECs with a particular name pattern. This way, the cluster can be easily scaled up and down. Please see section Execution Elasticity[hide]8.2[/hide] for more information.