Skip to main content

Contracting Issues

Negotiating contracts with the potential cloud vendors is complex but crucial for success in the cloud. While click-through agreements seem to make the work easier for low risk applications momentarily, organisations must consider opting for tailored contracts to ensure that all future applications to be hosted in the cloud are completely safe and devoid of legal issues. Some of the common issues that arise due to contracting pitfalls are:

(i). Vendor Lock-In

More than 75% of enterprises feel that moving to the cloud comes with some percentage of vendor lock-in. While the convenience to shop at one stop, draw a single tailored contract and the standardization of technology seem alluring, things may not look the same in the long run. Vendor lock-in hinders the path to rapid innovation and ultimately knocks down organisational health. Examining the exit options in the contract or opting for an open source cloud stack such as Open Stack may mitigate these problems.

(ii). Unilateral Termination

Standardized contracts from bigger cloud vendors may sometimes allow unilateral termination of the contract with a very small notice period. In such cases, the contract must outline the potential effects of the termination and ways to regulate them. The terms of post termination support must also be outlined in the legal contract drawn between the two parties.

(iii). Auditing Requirements

Does your cloud provider reveal the exact location of your data? Does your contract outline the procedures and technical solutions that are in place to protect data once it crosses the judicial boundaries? Cloud vendors transfer data from one location to another to balance load and avoid latency. As the data controller of the cloud, organisations must comply with the laws and regulations of the country where the service provider is located as well as with the location of data storage. Cloud auditing is the solution to ensure 100% compliance with all rules and legal requirements of the new environment.
Apart from these major issues, there are few other legal clauses that need the attention of the data controller while establishing a contract with a cloud provider.

Comments

Popular posts from this blog

Special Permissions in linux

The setuid permission on an executable file means that the command will run as the user owning the file, not as the user that ran the command. One example is the passwd command: [student@desktopX ~]$ ls -l /usr/bin/passwd -rw s r-xr-x. 1 root root 35504 Jul 16 2010 /usr/bin/passwd In a long listing, you can spot the setuid permissions by a lowercase s where you would normally expect the x (owner execute permissions) to be. If the owner does not have execute permissions, this will be replaced by an uppercase S . The special permission setgid on a directory means that files created in the directory will inherit their group ownership from the directory, rather than inheriting it from the creating user. This is commonly used on group collaborative directories to automatically change a file from the default private group to the shared group, or if files in a directory should be

The Seven-Step Model of Migration

Irrespective of the migration approach adopted, the Seven-step Model of Cloud Migration creates a more rational point of view towards the migration process and offers the ability to imbibe several best practices throughout the journey Step 1: Assess Cloud migration assessments are conducted to understand the complexities in the migration process at the code, design and architectural levels. The investment and the recurring costs are also evaluated along with gauging the tools, test cases, functionalities and other features related to the configuration. Step 2: Isolate The applications to be migrated to the cloud from the internal data center are freed of dependencies pertaining to the environment and the existing system. This step cuts a clearer picture about the complexity of the migration process. Step 3: Map Most organisations hold a detailed mapping of their environment with all the systems and applications. This information can be used to distinguish between the

RequestsDependencyWarning: urllib3 (1.24.1) or chardet (3.0.4) doesn't match a supported version

import tweepy /usr/lib/python2.7/dist-packages/requests/__init__.py:80: RequestsDependencyWarning: urllib3 (1.24.1) or chardet (3.0.4) doesn't match a supported version!   RequestsDependencyWarning) Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/local/lib/python2.7/dist-packages/tweepy/__init__.py", line 14, in <module>     from tweepy.api import API   File "/usr/local/lib/python2.7/dist-packages/tweepy/api.py", line 12, in <module>     from tweepy.binder import bind_api   File "/usr/local/lib/python2.7/dist-packages/tweepy/binder.py", line 11, in <module>     import requests   File "/usr/lib/python2.7/dist-packages/requests/__init__.py", line 97, in <module>     from . import utils   File "/usr/lib/python2.7/dist-packages/requests/utils.py", line 26, in <module>     from ._internal_utils import to_native_string   File "/usr/lib/python2.

tag