Cloud policy development Create a service level agreement that can be used by multiple partners

External cloud computing Http://www.aliyun.com/zixun/aggregation/14189.html "> Service level agreements focus on the characteristics of the provider's data center and network infrastructure. Although companies can set up cloud computing SLAs for their proprietary platforms, services (PaaS), the SLA is based on the provider's public infrastructure as a service (IaaS), but companies may want to take more control of the operating system, servers, and network infrastructure to address some of the root causes of problems, such as frequent service outages.

By invoking additional terms attached to an external SLA, companies can migrate private PaaS applications to their internal data centers. When a company solves a problem, it can return a more robust PaaS application to the cloud.

This article provides a roadmap of an internal SLA, where scenarios provide SLA variables, service elements, and user controls, using a strategy that demonstrates how best to manage SLAs.

An internalization SLA is relatively new in the SLA area. They are the product of an external SLA (the oldest resident) mixed with an internal SLA (not a very young resident). The ability to use them as an effective tool is mainly due to the proliferation of cloud computing infrastructures, which can be replicated and placed in different locations multiple times.

External SLA residents are dispersed across the external cloud, creating complex relationships between customers, suppliers, network service providers, and other external organizations. Scalability is one of the biggest advantages of the cloud. External providers can control operating systems, servers, and external network infrastructures.

Internal SLA residents are primarily the IT departments in the enterprise, and they find it costly to transmit data over the external network. These enterprises are responsible for managing operating systems, servers, and network infrastructures within their internal data centers.

The internalization of SLAs combined with two of the family. An additional clause is attached to an external SLA. This additional clause allows cloud users to transfer PaaS applications from the external cloud to the company's internal data center. After the application arrives, the internal SLAs to be used in the company are reactivated.

Cloud consumers, who act as internal providers in this case, have more control over the operating system, server, and network infrastructure that need to fix the problem. The cloud consumer returns a more robust PaaS application to the external cloud after reactivating the external SLA.

That's the idea. Let's analyze the idea in more detail.

Common SLA Features

All residents of SLA territory have a common feature. By definition, an SLA is the expectation of two or more parties in terms of quality of service, priority, and responsibility. The Cloud Services Client Committee treats cloud computing SLAs as written expectations of services between cloud users and providers. When policymakers evaluate and contrast user SLAs from cloud computing providers, the Committee provides them with guidance on what they expect and what they should know.

One feature of these residents is the search for input from all parties to the SLA in order for the SLA to be effective during significant reorganization, streamlining, and consolidation of services. Another feature that SLAs should have is the reference specification to operate the underlying IT infrastructure of the cloud service.

Scenario 1: Internal SLAs for private PaaS

As an in-house provider, the company is responsible for providing internal data centers for traditional IT and internal cloud services. Companies control the operating system, services, and network infrastructure of virtual machines that support their private IaaS. All PaaS applications are located on these virtual machines.

The company negotiates with developers on internal SLAs for private PaaS. The SLA contains 4 thresholds (explained later):

All SaaS users who have been designated as a resident of the PAAs indicate that they have a smooth access to the PAAs application and that no service interruption has occurred. The performance of the PaaS platform meets the guaranteed service availability level as defined in the SLA. The expectations of SaaS end users have been met. All PaaS developers are satisfied.

Scenario 2: External SLAs for private PaaS in the cloud

The company wants to place its private PaaS above the public IaaS of the provider, which expands and concentrates on the needs of developing, testing, and running PaaS applications. The operating system, server, and network infrastructure within the corporate data center is similar to the data center of the external provider.

Before migrating to the cloud, the company, as a cloud user, negotiates external SLAs with external providers for their private PaaS. As part of the negotiation, the cloud consumer can control all applications that exist within a full business lifecycle. External providers can control at a minimum:

These controls are more limited than the controls assigned to the PaaS application developers within the corporate data center.

External providers limit control over the level of user, resource, and data request thresholds with the company. Providers allow SaaS end users to access private PaaS applications in the cloud.

No service interruption occurred. All PaaS developers are satisfied.