Skip to main content

Practical Issues to be Considered

Once you have chosen the right cloud vendor and equipped yourself with the right expertise for the cloud, here is a list of practical issues  to be remembered to make the cloud journey as smooth as possible.

  1.  Proper negotiation of service level agreement
  2.  Vendor lock-in
  3.  Change in organisational culture
  4.  Compliance and security of data
  5.  Commercial implication of shipping large volumes of data
  6.  Integration of the cloud into the existing system


Service Level Agreements (SLA)
Some cloud solutions providers offer higher service level guarantees in order to differentiate themselves from the competition. SLA has been defined majorly to understand the consequences of the failure of a service and has nothing to do with the actual reliability of the service.
The cloud providers need to guarantee the service that they will offer in case they are hired. The guarantee of up-time and services that are hired are to be noted in the SLA. In case the provider fails to meet the level of availability signed in the SLA, they will need to compensate the customer as signed in the document.
There will be a certain percentage of the fee that the providers will offer during downtime. This SLA will offer an insight into the provider’s level of commitment. The reason SLA is a criterion that one should take into consideration, is that the real up-time will not be known. Testimonials and reviews will give the provider’s real up-time, but till then SLA is a better proposition.
Vendor Lock-in and Legal Compliance
The application programming interface (API) offered by the cloud solution is an important criteria that one should evaluate. This helps one access the infrastructure and performs operations like provisioning and de-provisioning servers.
The API is supported by multiple providers, and vendors will reduce the lock-in and help towards migration whenever needed. Again, the application does not need to be changed majorly in this case. The developer-vendor ecosystem will help enhance the services and capabilities of the cloud solution provider.
Consider the cloud solution provider that offers a developer-vendor ecosystem and has taken into consideration all the legal compliance that will make migration easy and convenient. The API should be supported by majorly all vendors and should comply with all the legal and security requirements as defined by the enterprises. API monitoring and management should be easy with the tools offered by the cloud solution provider.
Network and Security of data
Cloud solutions are based on different layers like application layer, host layer and network layer which make it complex and interconnected in many ways. The solution has to be secure at all levels in order to ensure that the enterprise data stored in the cloud remains protected. Efforts need to be made to maintain an adequate level of application maturity and build on its security levels.
The provider’s application and network-level security needs to be scrutinized. Know if the cloud solution offers application-layer firewalls. Secure a sanity checklist for pre and post deployment and keep reviewing the security development programs at regular intervals to keep the code secure. The application security should be integrated into the system at regular intervals. The architecture and functional design of the cloud should be reviewed from a security perspective.

Comments

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 ...

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...

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...

tag