In this series of short blog posts, we’ll try to break down some of the engineering principles behind integrations. We’ll use examples from Seamless, but the principles will be universal.
Azure regions
One of the most powerful lines in all of the Seamless sales materials reads “Seamless can be deployed within an Azure region of your choice.” It seems so straightforward, but it provides really meaningful options for Recursyv and for Seamless users.
Let’s start with the basics: What is an Azure region?
Azure is the cloud computing environment provided by Microsoft. In practical terms, this means that when Recursyv operate Seamless, we’re actually running our code inside a Microsoft provided computing environment which, in physical terms, is hosted inside a Microsoft data centre.
An Azure region describes a set of data centres which are all connected with high-speed data lines. Typically an Azure region is aligned to a geographic region that you may recognise, within a single country or across a group of closely located countries. Over time, Microsoft continue to open more regions – most recently South Africa and the Middle East.
Using multiple data centres within a single region provides redundancy. If Data Centre A becomes unavailable, all services being run within Data Centre A can be switched over to Data Centre B. Ideally this will happen without users noticing a service interruption.
For security reasons, Microsoft typically won’t detail the specific location of any given data centre, except to confirm that if you subscribe to Azure services within a specific Azure region, the data centres will be located within that region.
At the time of writing this post (August 2019), Azure was available in 54 regions servicing 140 countries.
Okay, it’s about geography – but why does it matter?
There are two main reasons why it matters.
(1) Connectivity speed
If we’re syncing between two applications hosted on the West Coast of the USA but using Seamless within the UK, we’d be sending data across the continental USA and across the Atlantic to a UK data centre, performing Seamless core operations and then returning the data back across the Atlantic and back across the continental USA. This will have a significant time delay and, if you’re counting, unnecessary energy consumption. For two applications hosted on the West coast of the USA, we’d be wise to use an Azure region on the West coast of the USA.
Of course, we won’t always be syncing two applications hosted in the same place. In these scenarios, we’ll use data location as one of the considerations when advising customers where Seamless should be hosted.
(2) Relevant legislation
Arguably more important than data transfer speeds is the legislation/regulation that will apply to the Seamless user’s processing of data. There is a growing recognition of the importance of data housing commitments and associated legislation to support these. Within the EU, the GDPR (General Data Protection Regulation) is the most widely known such example.
Seamless users will typically have significant legislative commitments to look after the data that is being synced by Seamless. Choosing the appropriate data region will enable Seamless users to meet their commitments to their own customers/suppliers/partners.
Is it all as complicated as it sounds?
No. In most cases Recursyv will be able to provide advice on how to select the most appropriate Azure region. This will largely be driven by factors detailed here as well as some operational considerations which will be specific to the given integration.
At the time of writing, Recursyv are operating Seamless in the Azure regions in the UK, EU, USA and Australia with an implementation in Azure Germany being planned. In each case, the Seamless services are deployed within the Azure region in support of providing a mix of the appropriate connectivity speed and the most suitable legislative environment.