Cloud computing SLA can break through the difficulties ushered in the spring

Cloud computing sla-is an agreement signed by a company after negotiating with a cloud-computing service provider when buying a network. This is to solve the problem that companies will realize when they purchase that they are disadvantaged in terms of the availability and performance of cloud computing-sometimes even extremely weak. In the end, however, the demand for the SLA is often different from the user's demand for cloud computing service level agreements.

At the application level, end users want cloud services to meet a usability standard and to use experience performance or quality (QoE) metrics, typically in response time. The user response to this experience is also varied. In a survey of cloud users, only about 10% per cent said they had received a specific SLA for their cloud computing services. There are many reasons for the huge gap between this demand and the actual situation, and most of them are difficult to resolve.

Cloud computing SLAs are struggling in a networked environment

The first problem facing cloud computing SLAs in the survey report is that they exclude network performance. Most cloud computing services are accessed through network connections from one company rather than cloud computing service providers, and you can imagine that cloud computing service providers simply cannot guarantee the performance of their network connections.

In addition, most of today's cloud computing services are accessed via the Internet, and the Internet is a service that cannot provide any guarantees. When you can't guarantee the connectivity of the network, it is difficult to negotiate cloud-computing SLAs with cloud-computing service providers; for the same reason, when there is a service component (a network) between your QoE measurement points and the cloud, users cannot prove that the services provided by the cloud services provider meet the SLA. This particular problem also affects the ability to connect cloud computing management and write management-level QoE SLAs.

Anyone who has written or monitored an SLA will be very much in agreement with the second-ranked issue in the survey report: the protocol does not or cannot determine a reasonable mechanism for measuring qoe to define compliance. The problem begins with seemingly simple questions that say in measurable terms, "what exactly should cloud providers ensure?" "For example, a user company can measure response time at multiple points and in several ways." Unless there is a mutually agreed measurement point definition and measurement criteria, it is impossible to have a practical operational, enforceable SLA.

In the survey report, the third problem with the cloud computing SLA is that the software components provided by the user and the applications created by the user may affect the QoE of the application. If we treat software as a service (SaaS) as the "highest level" cloud computing service, and the infrastructure as a service (IaaS) as the "lowest level" cloud computing services, then low-level services include more user-supplied components, Also, external connections created by users with higher-risk components will have an unpredictable impact on the overall performance of cloud computing services. Cloud computing service providers cannot guarantee, or even predict, how this part of the user-supplied component will affect the overall application QoE.

The fourth major problem with the SLA involved in the survey report is that cloud parameter settings can have a significant impact on application QoE, which means that SLAs must be written based on very specific parameter setting assumptions. In this way, special cases and even partial exceptions can lead to QoE and SLA problems.

Terms of the cloud computing SLA

The real problem here is that while there may be a number of reasons for not getting a truly meaningful SLA, those reasons cannot mitigate their needs. So how do you get the best possible SLA?

The answer, in short, is to avoid the problem; The basic principle is to understand what cloud computing services providers can actually guarantee. The essence of cloud computing services is to allocate virtual resources to actual applications. If you assign work as you expect, resource performance will achieve the same expected effect. Variables you must constrain include assigning parameters for resources and accessing resources over the network.

The most comprehensive SLAs you can get are often from the same provider of cloud computing services as network providers, so the most advantageous relationship for SLA purposes is the supply and demand of cloud computing services for network operators.

The second best option is to get a cloud computing service connection from an operator recommended and guaranteed by your cloud computing provider. In either case, you will need to use a VPN that differs from Internet or Internet VPN access and is "specifically provided" to secure specific communications.

In the resource allocation space, the simple rule is to ask, "What is a virtual resource here?" ”

In SaaS, virtual resources encompass everything because the user does not provide any components. Therefore, cloud computing service providers should have complete control over them and should write an SLA for all applications that are not network components.

In low-level cloud computing services such as platform Services (PaaS) or infrastructure i.e. services (IaaS), vendors should ensure the services they provide; Your goal is to determine how to measure the performance of the services provided by the vendor. In IaaS, the speed at which your application is allocated to the server will be the most volatile factor, and the speed at which a new server replaces the failed server will determine availability when a failure occurs.

PAAs is the most problematic part of the SLA clause, because you're not getting a commitment to a particular piece of hardware, but a platform that may include a large number of physical hosts and software elements to some extent. Determining how much response time variability may require you to create a "ping point" in the cloud through which you can deduct end-to-end application latency to measure network latency to determine the contribution of cloud computing application processing. Whatever you decide, these terms must be clearly stated in the contract, and the supplier must accept these terms.

The cloud-computing SLA may not be good for the buyer alone, but many SLAs in the current era do. With care, you can at least get a cloud-computing SLA that controls the level of risk and ensures that the cloud computing services you use can meet your business goals.