REST Capacity
This is a legacy license model. Customers currently using this model can still renew their licenses, but they will no longer be issued to new customers.
Description
A REST Capacity License is analogous to our Concurrent Operation license, but is for users of our REST APIs and when using self-hosted instances of our service. The concurrent operation license is only applicable to users of our Java APIs.
When the REST service starts it can be configured with a capacity. Normally this would bare some relation to the capacity of the machine (physical or virtual) running the service including the number of processor cores and its memory size. The capacity controls how many operations such as comparisons or merges that service can then run concurrently. At a technical level it configures the size of a Java thread executor pool. It is a good idea to configure the capacity to match the system on which the service runs so that execessive thread swapping is avoided and memory sizes do not grow out of control. When the number executing REST operations reaches the capacity limit requests to the REST API will be queued for execution and their status and that of the overall REST service (such as queue size) can be queried using REST calls.
The license server then controls the total capacity of the REST service(s) that are running on the network. The license server runs at a fixed network location and the REST services will contact it when starting, thereby consuming the units of REST capacity that it controls and the units of capacity are returned to the server at shutdown and in various failure scenarios.
When the capacity is exceeded new instances of the REST service cannot be started. It is possible to query the license server to discover the services that are in contact (there is a heartbeat mechanism in between the initial checkout and final checkin) and are consuming the capacity units.
License server redundency and resilience
License server redundency is possible using a triad of communicating license servers. Each service is then configured with all three server addresses and two servers are needed to form a ‘quorum’. The communicating/synchronized triad model is suited to cloud providers with different availabilty zones or AZs in a geographic region. In the triad model all three servers share the defined capacity.
Another form of redundency is server fallback. Here the REST services will be configured with an ordered list of servers and will attempt to obtain their configured capacity from them in turn. If a server cannot be contacted, or its capacity has been exhausted, the service moves onto the next server. In this configuration, often suited to servers in different geographic regions, you may choose to divide your capacity as specified in your order or renewal between a number of servers.
Use cases
The use cases for REST Capacity are similar to those for Concurrent Operation, although a REST API rather than Java API is in use. Where load balancing is needed for redundency a variable number of VMs running the service would be configured with the fixed IP address or hostname of the license server. Provided that the total capacity of the REST services does not exceed the quantity controlled by the license server, they can run on systems with changing identity; the licensing system does not then constrain where the services themselves run (in terms of IP address or hostname for example) provided there is network connectivity to the fixed license server location.
Sizing
At the time of writing we have found that one REST Capacity unit (or concurrent REST Operation) requires between 2 and 3 VPCUs or cores on AWS and Azure virtual machines. Plans are in progress to make more use of cores in our operations and when these updates are released it may be useful to increase your VM core counts to get better throughput for the allocated capacity size. Memory size is usually linearly proportional to data sizes and we recommend testing capacity using typical data with an evaluation prior to purchase.