Service Level Agreement for Cloud Computing setup

SLA for Cloud Computing Service Provider

As a standard practice,  the customer and service provider enters into a service based agreement before commencing of any project. The agreement is a way to determine and note down the requirement from the customer, commitment by the vendor, and pricing for the entire project. The Service Level Agreement (SLA) in case of cloud migration from traditional infrastructure includes cloud carrier, provider, broker, and list of services required to make the upcoming solution operable.

Besides, the SLA mentions the model (Iaas, Saas, or Paas), method, and ETA from start to complete the migration.

The SLA is a legal entity and involves the law. Although, practically, SLAs are only for the formality and both sides keep enough room to manage extra requirements and additional time taken to develop the system. But, in case if the matter reaches the court of law, the SLA helps. In case of any organization, the SLA is not just a legal document; it also states the details of the entire project as the federal system seeks.

Method

A core SLA team initiated the SLA. This team consists of experts from the organization. The idea is to recognize the focal point of creating an interface with the service vendor on SLA.

Once the team is set up, and visions are straight the team chalks out the main agreement points. The experts who write the terms and conditions in the form of bullets ensure that they write down every single detail concisely. A very well written SLA forms the base of a trustworthy relationship between the vendor and service provider.

In case of any organization, moving its structure from traditional to cloud-based model like Iaas, multiple things must be part of SLA. Non-disclosure commitment of the data, adherence, and compliance with the government policies about the information handling, service commitment, output expectations, storage plans, backup plans, and total control on the system from access to destroyable rights are few of the points must be added to the SLA.

First of all, there has to be a Single Point of Contact (SPOC) from the organization to Cloud vendor. The SPOC helps to clear any chances of communication gaps. A vendor cannot say that they had informed about a possible downtime unless they write to the SPOC.

During the entire development process, the vendor should be asked to share the report of key functionaries, test cases, expected test results, and achieved results. Deviation beyond a certain level must be considered as a breach of the SLA.

Discussion

An SLA is shared in electronic form for review between both the parties must be on physical, and court notified paper. Each of the terms must be read, understood, and committed by both the parties.

Conclusion

When there are many small and large services being worked upon, an SLA becomes an important document. It has to be abided by both the parties for a smooth transition ad business operation.

Photo on Visualhunt.com

What is the best method to set up a Cloud?

Setting up a cloud infrastructure is not the issues, the only thing needs attention is the proper usage of all the services. For this, one needs to start from the Proof of Concept stage and then move towards the sustainable, stable application. The only step that you can omit from the software development lifecycle (SDLC) is the requirement gathering. This is so because the department knows the requirement.

The objective is to transform the entire system from legacy and distributed platform to unified cloud computing. In this endeavor, the first need is to determine the method to set the cloud up. The process entails a big deal of risk. After all, it’s not like changing the curtains of the window, and it needs a careful shift.

Among several methods available, the In-house development and deployment is the most appropriate in the view of safety and security of the information exposed to the development team. The in-house team can be restricted and controlled much easier than a set of people working remotely at a vendor’s premises.

The foremost thing about using an in-house development setup is that the existing subject matter experts can be used to write down requirements and test cases. There is no need to spend weeks in chalking out the plans and priorities.

The people who are already part of Department know well what information can be revealed to the developers and what details should be masked.

When the environment is all set, the new cloud computing programmers, database experts, network engineers, and technical writers can be hired. Each of the newcomers can be assigned specific roles under the supervision of existing experts. These existing experts may not be aware of choosing the best model or great programming framework, but of course, they would be aware of expected output quality.

The most important reason why the in-house development is preferred over an outsourcing paradigm is the security. The new developers can be made to sign the non-disclosure agreement. Apart from this, their computers can be blocked with the internet until the programs are ready. Restrictions on bringing storage media or phones can be controlled so that the chances of information leakage go out of the scene.

In-house development ensures the security of work. It also ascertains that the development is going on the right track and everything is being tested as per set standards. Developers and others have clarity of task and experts know what to expect. This way the client and vendor both work in the same cubicle, thus there is no scope of deviation from the expected results. Department of Defence manages sensitive information, and this is why the in-house development method will be appropriate.

In-house development and deployment is dependent on internal skills and availability of in-house resources to develop new services. In-house development and implementation should reduce the learning curve on how to link to legacy services. With In-house development and implementation, the enterprise owns the cloud service and can add updates on the enterprise timetable. In-house development and deployment offers potentially tighter controls during the testing process. In-house, test managers can work closely with other IT and business leaders to ensure complete testing is done.