Skip to main content

Cloud Contracting Models

models that are available in the industry -

 Standard Contract

Standard Contract model contains the most common terms and conditions listed in the agreement. It talks about

• The security and data protection standards followed by the cloud service providers
• Capacity allocation and scalability terms
• Location of the datacentres
• Lock-in period (which talks about how long the client would sign up for)
• Pricing structure and payment terms
• Periodic audits and updates
These are the general terms that would be included in a standard contracting model. This model is also referred to as Click-Through Agreement - as the client just needs to review the contract and sign off with minimal or no changes. Both the client and the service provider know about all the agreement terms prevalent in the industry. Usually, standard contracting model is utilised by the organisation whose cloud requirements are not mission critical or when they do not, intend to move their confidential and core business applications to the cloud.

 Negotiated Contract

As the name indicates, Negotiated Contract talks about specific terms and conditions in the agreement as per the unique requirements of the organisation. Usually, organisations which serve business customers negotiate strict terms and conditions and they would insist the cloud service provider to abide to it. The additional terms that are negotiated include:

  1. • Key Management and Encryption requests
  2. • Specific policies and procedures
  3. • Standard data transmission protocols as per the sector
  4. • API Integration and related set of guidelines
  5. • Contingency measures and action plan
  6. • Administrative roles and responsibilities

Time-bound Contract

This is either a standard contract or a negotiated contract, the whole validity is for a specific period. Say for example, some organisations have internal policies to change vendors every year or once in 3 years etc. This applies for all types of vendors they deal with. This ensures efficiency in services provided and move to the better ones if in case there are issues with existing vendors. This holds true for cloud service providers as well. If the organisation is happy with a specific cloud service provider whom they have trusted their data with, then they would renew it after the time frame in the contract gets over. If they are unhappy or if they found any discrepancies with the existing cloud service provider, then they would change them after a certain period. Some of the multinational corporations are known to levy heavy penalties for their vendors who do not comply with the contracts. The industrial term for such activity is “Contract Deviation”. If the cloud service provider is said to deviate from the contracts, then they might end up paying heavy penalties and in some cases, also face law suits. In such cases, the contract is terminated immediately and the data is moved to other third party service providers.

Comments

Post a Comment

thank you for visiting :)

Popular posts from this blog

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 ...
Post a Comment
Read more

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...
Post a Comment
Read more

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...
Post a Comment
Read more

tag