Cloud computing – access and lock-ins
Continuing the recent series of articles on Cloud computing which has appeared in Law News over recent weeks (see Issue 27, 14 August 2015, Issue 32, 18 September 2015 and Issue 37, 23 October 2015), this article looks at issues of outages and lock-ins – what happens when things go wrong with the Cloud.
Outages are becoming somewhat commonplace as New Zealand and other countries upgrade their infrastructure, resulting in increasing internet congestion. Improperly prepared backups can see data lost, resulting in failure to access documents that need to be delivered to court and possible disaster for clients. All this means that backup plans need to be considered carefully before moving to the Cloud.
Lock-ins can also pose substantial problems for document recovery when you choose to move to the Cloud, especially when proprietary formats are not compatible with the applications or formats of the new provider. This article provides some insights into how to mitigate these problems.
Outages and access
The internet can be a minefield. Upgrades are increasing internet congestion and “network latency” as internet providers scramble to increase bandwidth backplanes. “Network latency” is a technical term used to describe the length of time it takes for a “packet” (i.e. the data being broken down into multiple parts for transmission across the internet, which is then put back together on the receiver’s end to reform the data) to reach its destination.
Such latency, on average, now exists at peak times between 150ms to 1900ms or higher, resulting in data transmission errors or timeout on routing devices which have much lower timeout thresholds than computers. The root cause is packets being broken down into multiple parts for quicker transmission across multiple paths to the source, which then recombines the packets to reform the data.
Accordingly, when a packet is not received in a certain time (or worse, is received out of order), the receiver drops the packet and asks for re-transmission in the right order causing websites to report “site not found” or, as with video, issues of pause or “stutter” or, as with text communications, duplication. These types of outages are not as severe as when the transmission line (such as ADSL or fibre) simply stops working or starts to drop packets repeatedly due to high congestion that can see connection interrupted and data having to be reacquired.
Accordingly, when looking at Cloud computing, firms need to consider how they will deal with outages and congestion, for example, how to get paperwork to court on time if unable to access the network or Cloud service. Of course, the easy answer is not to leave things to the last minute, but we all know that the realities of legal work do not always allow for this. It is therefore important to investigate what redundancies the Cloud service provider has in place, as well as your own redundancies and the costs of maintaining them.
Two examples below illustrate good practice for local redundancy and for Cloud service redundancy respectively.
Example 1: Local redundancy– small firm rural access to internet
Firm A has a small practice in rural New Zealand with moderate ADSL broadband and cellphone coverage. The broadband service is resold through Spark, so no matter who is chosen for provisioning of service, they connect back to the same ADSL DSLAM, which provides little redundancy if the network fails or gets congested.
Solution: In order to provide redundancy, Firm A will have to implement a single ADSL line for day-to-day operations and use the cellphone network and the phones’ internal hotspot connection software to gain access to the documents needed to complete the Court filing deadline. At the time of writing, rural broadband may also provide an option; however, I have found that costs simply make this option unrealistic for a long-term solution.
As this example shows, for a small outlay, a basic level of redundancy can be implemented to prevent failures. Firms in non-rural areas have a greater level of redundancy options with multiple fibre lines being available from multiple suppliers. With the implementation of low-cost “multiwan” (also known as “loadbalancing”) routers, service reliability can be increased across multiple suppliers, resulting in reduced latency.
Before choosing an option, however, it is important to know the delivery path for your area, as many New Zealand companies simply resell other service providers. Therefore, while it may look like you have separate connections, your outage, congestion and latency issues may not be resolved through a connection to what looks like a separate supplier.
However, what happens when Cloud data is missing or the Cloud service is offline? As with any server technology, failures do occur, and I discuss next what to check before adopting off-site services. When choosing a Cloud service provider, it is important to ask what redundancies that provider has in place for data retention, recovery, service access, power loss, network failure and network intrusion.
Example 2: Cloud provisioning – how I protect our infrastructure in Canada
I host a service that provides Cloud technology and video conferencing for alternative dispute resolution that is used by us and by clients in the UK, Canada and other parts of the world. We need to be up 24 hours a day, 7 days a week, due to the time zone differences and client usage. We had to make sure that the service was “war-proof” and had redundancy in case of a catastrophic failure.
Solution: The datacentre I chose was designed to withstand a nuclear blast with multiple generators and has its own dedicated fibre cables. These fibre cables run through Canada, the US, the UK and Europe with multi-homing connections to guarantee uptime. The servers providing the systems are connected via “raid array”, which has “hot swappable drives”, preventing data loss. In effect, if one drive fails, the others take over and rebuild the array data when a replacement is put in place, resulting in recovery without loss of data access. The servers are set up with redundancy so that if the server fails its duplicate takes over. In addition, the whole system is duplicated into a second datacentre located in another country, which comes online if the main datacentre is ever offline for more than 10 minutes. I myself use multiple connection redundancies to make sure we are always online.
This type of solution is paramount for a datacentre to maintain security and access to data for client information as and when needed. As a customer, your supplier should have no less than this minimum standard in place for your Cloud service. Most upscale providers provide this form of redundancy – however, they do not usually provide security level infrastructure unless requested, so keep in mind the questions from the privacy and security article earlier in this series (see Issue 37, 23 October 2015).
To obtain low cost access to this kind of service, careful planning and a review of your current systems is needed to make sure you are not over-purchasing what you will not use. Remember that the Cloud is “scalable” up, down and on demand to get the most cost-effective solution all the time, so firms need to feel comfortable with reducing loads when appropriate, as much as they are with increasing them when needed.
Transferring Cloud providers – unwanted detention (lock-ins)
What happens when you need to move your data to another provider? A lack of industry standards has resulted in difficulties with “lock-ins” when transferring services from one Cloud service provider to another. Lock-ins can be boiled down to three main types, as follows :
- legal lock-ins, where the customer has signed up to a minimum-term contract which includes the provider’s ability to increase prices (for a full discussion of contractual issues see Andrew Easterbrook’s article in the 2014 special Technology & Law edition of Law News, Issue 25, 1 August 2014);
- proprietary lock-ins, where the system or functionality makes it difficult to move to a competing provider; and
- psychological lock-ins, where people feel that changing the provider will create problems. In this case, it is important to look at the migration terms – does the provider undertake to assist with migration and what charge is involved?
Each of these issues must be considered carefully when looking into a move to the Cloud and if proper time is taken to review these issues the firm can protect against problems later on.
Some packages have internal applications that are not open standard, resulting in difficulties of sharing information outside the provider’s own Cloud service (for example such as Office 365’s Outlook application). The lack of adoption of open standard platforms by many providers, not just Microsoft, causes considerable concern to Cloud service deployment, as “APIs” (application program interfaces) are usually proprietary and prevent easy transfer across platforms or mobile devices. This results in data being locked-in to the chosen Cloud service provider and software. Further, if a service is discontinued, firms may be unable to access the data at all.
Therefore, firms need to consider carefully if they will go with an open source standard for their Cloud provisioning which will largely depend on the software currently used within the firm and whether that software should be replaced if not compatible.
Once compatibility questions have been answered, the Cloud service provider’s framework and what standard they provide can be evaluated.
These questions become even more important as we move into an age where sharing data to a mobile device has become almost a necessity for most businesses, so checking if your handheld devices can connect becomes an important consideration when choosing your Cloud service. Other considerations include security and business continuity, including backup arrangements and knowing where your data resides, as these affect your rights and compliance obligations, as discussed in previous articles in this series.
Look out for the final article in this series, coming up in December.