Most commercial providers' SLA (like AWS, Azure) is focus on the resource layer and come from the provider's perspective, it give you service guarantee on the product they are offering. However, it doesn't seems to have an easier mechanism to "monitor" or even "manage" the so-call SLA metrics.

For non-commercial cases, SLA could be useful if the users require some sort of service guarantee or to automate resource provisioning.

I'm looking from different approach:

1. How do you specify users requirement (functional, non-functional) and map them (translate) into cloud.

2. How do you monitor the performance of the cloud (public or private).

3. In the event that the performance of the cloud is falling below expectation, how do you resolve and rectify it in an autonomous way. (automate resource provisioning?)

For more info on Cloud SLA, check out the EU project SLA@SOI. It published a book "Service Level Agreements for Cloud Computing". It proposes a multi-layer SLA management architecture.

Also check out the following papers:

1. An SLA Focused Financial Services Infrastructure

http://www.researchgate.net/publication/221657632_An_SLA_Focused_Financial_Services_Infrastructure

2. SLA-aware Resource Management

https://www.researchgate.net/publication/221657635_SLA-aware_Resource_Management

Conference Paper An SLA Focused Financial Services Infrastructure

Chapter SLA-aware Resource Management

For one thing, SLA parameters can be used in scheduling and allocating of virtual resources like CPU power and network bandwidth. Also SLA can be used as a performance quality check, in a way it answers the question "Does the private cloud meet the SLA requirements"?

Khaled,

thank you for your answer. But, if you say from provider side, the same result can be reached using resource monitoring, without engaging into an agreement protocol. A user always describes the resources he is going to use, even without an SLA.

Also in a non-commercial environment, like use of institution's or companies internal IT resources SLAs are quite common. This allows the IT to plan their infrastructure according to the needs of their internal customers. In case of a private Cloud provided as pat of the internal IT infrastructure an additional benefit for the IT would be that monitoring the SLA allows early detecting resource shortage and either provide additional resources internally or bursting into an external Cloud (if the policies would allow this) thus providing controlled elasticity on demand without the need to constantly assign resources for an estimated peak load.

Augusto,

I have developed a middleware system, during my PhD, that provides real-time (i.e., SLAs) and fault-tolerance for a large transportation company (mainly light-train systems). While it is not a true cloud computing platform, it is close enough (SOA based). The system is deployed in a private and closed cloud. The need for the enforcing of SLAs derives from the fact that the customers for these light-train managing solutions demand strict deadlines for specific operations, e.g., an alarm in a station must reach the control center within a specific time, otherwise the SLA is breached with financial implications.

I am not quite sure if I do understand your question the right way. An SLA is part of a contract. It's implementation therefore means only a contractual binding specification of several parameters.

Any application needing resources will have some requirements which can be specified. If a private cloud applications has to fulfill a task - and for fulfilling the task has several requirements - it has to rely on fulfillment of these requirements.

You are right that users will always specify these needs - but whatelse would an SLA be then a contractual guarantee for fulfillment these needs?

Counter question: What good is a service provider, if you can't rely on their service? Would you buy a mobile phone service from a vendor without the provision that they offer service in at least 95% of the country and at least 360 days per year even if they were cheap?

Hi Augusto,

by using SLA in your private / non-commercial cloud, you will have the benefits of an SLA, some of which may include:

- knowing what to monitor,

- knowing how to monitor,

- clearly defined peak values,

- ability to provide metrics - both for reporting progress, and for understanding when something is "wrong"

- clearly defines roles (so to avoid confusion later)

- defines accesslevels (who should have access to what, and why)

- defines responsabilities - who is in charge when something goes wrong, what to do, and sometimes even how to do it

From my perspective, the use of an SLA makes equall sense for a private / non-commercial cloud as for other clouds, perhaps even more. If your organization manage the cloud and the infrastructure yourself, situations may arise when a critical situation appear, and no-one knows how to deal with it. With an SLA, focus can be on fixing the problem, instead of figuring out who is to blame.

I think you're focusing on the financial part of SLAs, while they also consist a management unit and a language to describe promise to deliver -- both fairly useful for resource providers.

Even in a private cloud the users are "dependent" on the provisioned services. SLAs not only provide the necessary guarantees to the Users but also provide a means of management to the PROVIDERS. Moreover, SLAs having become a de facto standard for quantification, monitoring, compliance and fault tolerance of metered services have certain associated advantages when it comes to related IT services in governance.

Moreover, any application (either in a commercial environment or otherwise) has requirements that must be met . A SLA can be a way to specify these requirements.

I think it is a way to achieve goals, to guarantee QoS, fairness between the users of the cloud, and so on. In my opinion, SLAs are even more necessary in non-commercial clouds. E.g. for the fairness issue, what if a single user monopolises the use of the resources for a long time? Do we really have an "open" non-commercial cloud?

Most commercial providers' SLA (like AWS, Azure) is focus on the resource layer and come from the provider's perspective, it give you service guarantee on the product they are offering. However, it doesn't seems to have an easier mechanism to "monitor" or even "manage" the so-call SLA metrics.

For non-commercial cases, SLA could be useful if the users require some sort of service guarantee or to automate resource provisioning.

I'm looking from different approach:

1. How do you specify users requirement (functional, non-functional) and map them (translate) into cloud.

2. How do you monitor the performance of the cloud (public or private).

3. In the event that the performance of the cloud is falling below expectation, how do you resolve and rectify it in an autonomous way. (automate resource provisioning?)

For more info on Cloud SLA, check out the EU project SLA@SOI. It published a book "Service Level Agreements for Cloud Computing". It proposes a multi-layer SLA management architecture.

Also check out the following papers:

1. An SLA Focused Financial Services Infrastructure

http://www.researchgate.net/publication/221657632_An_SLA_Focused_Financial_Services_Infrastructure

2. SLA-aware Resource Management

https://www.researchgate.net/publication/221657635_SLA-aware_Resource_Management

Conference Paper An SLA Focused Financial Services Infrastructure

Chapter SLA-aware Resource Management

Maximilian,

your interpretation of my question is correct, and principle you are right: if the user requests a resource and the provider delivers it there is an implicit agreement.

However, in absence of an SLA protocol, many aspects of the provision are treated "best effort", which in many cases is sufficient for the task. For instance if you buy a CPU from EC3 they qualify the CPU, not the Mips or the NIC bandwidth.

The SLA is a cumbersome extension that has to take into account many subtle issues: have we to assume that the SLA must be always there (in a standardization perspective) or instead can we treat it as a sort of optional, mainly justified in case of a commercial service? The answer from Rolando says that there are cases where it is important for the user to have a binding reply from the partner.

The question is valid for any service in principle and varying levels of QoS may be offered and formalised in a SLA.

In not for profit offering, the QoS level should be compatible with the cost (none) and the minimum users' requirements that exist in any case. As an example, Internet best effort is what we all use, but we expect a minimum quality to be able to profit of it.

So formally, in my opinion, there is no need of an SLA, but practically the provider should understand the private cloud behaviour and compare it with users' expectation to gauge what's the value of the offer.

In case of a research oriented cloud, the cloud behaviour is essential to reach research goals (e.g. ensuring reproducibility of results)

1. SLAs in a commercial cloud have two aspects. One, SLAs that the cloud service provider provides to the user for the contracted services and second, the SLA that the cloud service provider gets from the network service provider to get the required bandwidth, latency, packet losses and other parameters.

2. In a non-commercial cloud while one cannot deny that assuring the required QoS to the users for the services provided is essential, the requirement of the other SLA is ie that between the network provider and the cloud operator still exists. It becomes absolutely necessary if NaaS is implemented.

3. If the non-commercial cloud interconnects with other clouds then QoS on this interconnection needs to be paid attention to.

While many associate SLA with performance, availabilty and reliability, one needs to keep in mind that there must be a need to assess compliance of the cloud services with the enterprise security policies and regulatory requirements. An SLA in a a private cloud setting may deal, for instance, with issues such as access control policies, encryption policies (keys lengths and lifetimes...), as well as means of ensuring non-repudiation (logging....)

Just to wrap-up an interesting discussion. The participants agree that SLA is of interest even in non-commercial clouds, especially when networking is involved (Lav). The reasons are twofold.

From the point of view of the user, the existence of a SLA allows to operate in demanding environments (Rolando) and to certify the compliance to internal policies (Yacine). From the point of view of the provider, the existence of a SLA improves resource management (Khaled, Wolfgang, Rolando, Kai and many others).

My impression is that this latter reason is not so relevant. After all, the provider is able to perform resource management using data contained in the requests, and the absence of an SLA simplifies the interaction. But I agree that the presence of a SLA opens new perspectives on the user side.

Yih gives references to the SLA@SOI working group, but there are many working groups and standardization bodies currently working around Cloud SLA: NIST, IETF, DMTF, OGF to name some of them.

Thank you to the participants...

I'm coming along late, but there's another point here: SLAs and other statements of non-functional requirements are a useful tool in developing a system such as a cloud platform. Many design decisions depend implicitly on assumptions about the service level to be provided; stating the SLA early makes those assumptions explicit, and provides a way for users to consider them while it's still cheap to change.

If you have an SLA with your customers, then you need one with your suppliers, irrespective of their legal status or profit-making status.

There is a cost for the provider to manage an SLA infrastructure, which may not be necessarily justified in a non commercial environment as you mentioned. However, it can provide a formal mechanism for quality assurance in service provisioning (formally establishing service quality metrics and monitoring service operations).

Private Cloud does not mean that it is used by a single person. Even if the Cloud resources (or platform or software services on top of it) are offered only company internal there are most likely different departments with different shares (and corresponding resource quality expectations) and working with data from different customers on it.

So if you consider SLAs as a mechanisms to steer the way how the available pool of resources and services is provided to the different user groups/departments or for different projects associated to different customers they are just the internal means to make sure that your external SLAs can be met.

If you offer just best effort to your customers and internal resources are just considered "common property" which might be the case in smaller companies your doubts might apply but in all other cases (which are in my view the clear majority) you do need internal SLAs as well as external ones.

The issue of SLA´s is about concerning the required/contracted RTO level and the impact analysis from risk on information for business infraestructure; in few words: it depends if is critical or not to the company; no matter what compliance, standards or laws rules the game, meanwhile the cost-benefit relationship turns down the $$

Just to give an idea of how much SLA can be useful, even in a private cloud, I'm implementing CAD teaching services in a cloud. From student perspectives, latency is not just a matter of QoS, as they use graphic sessions, which can become definitely not working if scrren updates are too slow. It means SLA is here directly related to functionality, becoming a mandatory feature of the environment.

Just to give an idea of how much SLA can be useful, even in a private cloud, I'm implementing CAD teaching services in a cloud. From student perspectives, latency is not just a matter of QoS, as they use graphic sessions, which can become definitely not working if scrren updates are too slow. It means SLA is here directly related to functionality, becoming a mandatory feature of the environment.

The primary objective in public cloud is either to maximize the profit ( provider perspective) or to minimize the cost ( user's perspective). But in private cloud the major focus is to maximize the utilization and minimize the make span. So the SLAs in public cloud mainly concentrate on finance, whereas the focus of SLAs in private cloud is to maximize the utilization. More precisely, when the user requirements are posted to the scheduler, the optimization function focus towards profit or cost in public cloud, whereas in private cloud it focuses on make span and utilization. During the SLA creation phase, besides SLOs, the agreed penalty mechanism is predominantly financial penalization ( like reducing the cost, providing extra time) in public cloud, whereas in case of private they are corrective penalization ( try to correct the system ).

First of all, in one hand, I think we must differentiate between non-commericla and Private Cloud. A private cCloud coul be offered to an External company by an Cloud Service Provider (CSP).

In the other hand, assuming we are speaking about a Private Cloud operated by the same company (for example a big company that want to offer cloud services to its different internal departments, branches, and so on) the the SLA could become in fact an OLA (Operational Level Agreement) as stated in ITIL, and the say to our internal user wahat can expect form the IT Department. It also lets us verify if we accomplish with our promises, and then to find out where we can or must improve.