Deploying Relativity to the Cloud

While people often use the term "Cloud" to ambiguously refer to online services, the "Relativity Server in the Cloud" feature is more targeted, and focuses specifically on hosting your middle tier on virtual cloud systems such as those provided by Amazon Web Services (AWS) or Microsoft Azure.

Of course, it has always been (and still is) possible to host Relativity Server and custom servers on cloud infrastructure "manually". But as of version 8.0, Relativity Server gains built-in features that make it integrate automatically with the cloud services, without manual code; actually, without manual setup of any kind.

For the initial release, Relativity Server in the Cloud focuses on hosting on Amazon Web Services, in particular combining the EC2, S3, RDS and DynamoDB services provided by Amazon. Future updates will add explicit support for Azure, as well as other hosting solutions depending on demand and requests.


A lot of people think of cloud hosted services such as Amazon EC2 as just another way to host and maintain a server somewhere online. For example, to host a website using this model, they'd boot up an EC2 instance, install Microsoft SQL and their custom server apps, maintain that instance and back it up rigorously. If the EC2 instance dies, and it will, that is a major event, costing effort to restore the system on a new server and get everything up and running again. In essence, very little is gained by using the "cloud" over a regular co-located server.

This is fundamentally flawed. The way to approach services in the cloud is to think of virtual instances, “servers”, as discardable components that hold no value, except for the actions they perform at a given time. Instances come and go, and if they die, it is no big deal. In fact, the load balancing or failover support should be encouraged to create, destroy or move instances as it sees fit. With this model, “losing” a server goes from being a terrible accident to something that happens routinely all the time and doesn’t matter at all.

The way to achieve this is to make each VM instance completely stateless and to not store anything “of value” on them. Instances are there to be booted up, do work, and go away (whether gracefully, or unexpectedly) at a moment's notice. And to go away without needing to be backed up beforehand — exactly because they hold no relevant data.

This brings us to the first pillar of “Relativity in the Cloud” functionality, and that is external configuration

External Configuration

One important part of a middle-tier server’s “state” is of course its configuration: For Relativity Server, this means its set of Domains, Schemas, Connection Strings, Business Rules Scripts, etc.

To get your VM instance(s) completely stateless, we need to enable them to configure themselves automatically from an external source, on boot. The idea here is that you can automatically boot up a VM instance (or ten of them) from a generic disk image, pass it a small bit of information (such as an S3 bucket name and access tokens), and get a running middle-tier server from it — without you or your sysadmin ever logging on to the instance and configuring anything.

This “generic” image could be a standard Relativity Server EC2 AMI provided by RemObjects Software, or it could be an image that you or your system admin created and fine-tuned yourself. But, and that is crucial, the image would and should not contain the core configuration that makes your server unique and focused on its job. You might want to fine-tune what version of Linux your image is based on, for example, but the image should not contain what we'd think of as “configuration” — i.e. the setup that changes frequently over the life-cycle of an application.

Once created, this image should remain usable for a long time, and be able to be booted up to dozens or hundreds of instances over the course of months (if not years) — only to be touched when you want to update to a new version of Linux, for example.

This means the actual configuration of the server needs to be stored elsewhere. When the instance gets booted up, it gets passed details where to find the external configuration (such as an S3 bucket name and login credentials) as part of its boot parameters, and configures itself from there, transparently.

Failover a Load Balancing

Core failover and load-balancing is something that cloud hosting solutions such as AWS or Azure will handle for you automatically and “for free” (technologically speaking, not financially), once the middle-tier services in the VM instances behave appropriately – which Relativity server does. A distributed session manager (more on that below) can optionally be used to let user sessions be seamlessly available across all running instances. This allows for even more flexibility when choosing your load balancing options.

The actual database would be stored in a service that is automatically protected by the cloud provider's infrastructure. For example, Amazon's RDS will automatically replicate databases, even between availability zones if desired, and if an RDS database should die, AWS can switch over transparently to the backup. RDS databases also allow to automatically back up to S3 at regular intervals. Similar options exist on Azure and other services.

Session Management with DynamoDB

One feature that can be important for a middle-tier server when scaling out is session management (it also might not matter, depending on how the server is structured). We already have Olympia Server as a way to let our customers share session state across multiple servers, but Olympia has one limitation, and that is that it moves session state to a new single point of failure, the one Olympia instance. If we look at the EC2 picture, Olympia would be its own EC2 instance that all Relativity instances would connect to. This helps make Relativity robust, but if the Olympia EC2 instance goes down, the system goes down (or at least, session data would become unreliable), and you'd lose any state stored in that Olympia EC2 instance (and no state should be stored in any instances, remember).

To solve this, session management can optionally be delegated to DynamoDB, Amazon's NoSQL database, to allow session data to seamlessly be available across all instances – essentially outsourcing the maintenance of the state data to a service that is already guaranteed to be robust and redundant by AWS (see above). Each Relativity instance can talk directly to DynamoDB to find and store state, and it will be instantly(-ish) available to any other instance, even across availability zones.

This can be done simply by selecting the DynamoDB session manager (also available as a standalone component for use in custom servers) and connecting it to the appropriate DynamoDB table.

Of course, local per-instance session management is still an option (and frankly the right option, in many scenarios), and Olympia Server is available as a new option in Relativity Server, as well.


By leveraging the cloud features discussed above, your Relativity Server middle tier is set up for optimum reliability. For more details, refer to the links below that discuss the individual cloud provider's services and their impact and contribution on the full system's reliability in more detail: