Build multiple-user cloud policies with internalized SLAs

Develop a standard way of creating service level agreements that multiple partners can use

Internalized service level agreements can provide external customers with temporary access to internal resources — it's sort of a "bridge" policy that manages a process whereby you help a customer achieve a goal with his private application or service that he cannot otherwise achieve without the use of your internal resources. Follow along as the author details the components of an internalized service level agreement (SLA) and how to use them.

Judith M. Myerson, Systems Engineer and Architect

Judith M. Myerson is a systems architect and engineer. Her areas of interest include enterprise-wide systems, middleware technologies, database technologies, cloud computing, threshold policies, industries, network management, security, RFID technologies, presentation management, and project management.


developerWorks Contributing author
        level

12 March 2013

Also available in Chinese Russian

An external cloud computing service level agreement focuses on characteristics of the provider's data center and network infrastructure. While it's possible for a company to set up the cloud computing SLA for its private Platform as a Service (PaaS) to sit on top of the provider's public Infrastructure as a Service (IaaS), the company might want more control over the operating system, servers, and network infrastructure to fix the root cause of, say, frequent service interruptions.

By invoking a rider attached to the external SLA, the company can move private PaaS applications to its internal data center. When the company fixes the problem, it can return the more robust PaaS applications to the cloud.

This article provides a roadmap to internalizing an SLA with scenarios that provide SLA variables, service elements, and user controls and illustrate with a policy on how best to manage the SLAs.

Internalized SLAs are relative newcomers to the land of SLAs. They are a crossbreed between external SLAs (the oldest inhabitants) and internal SLAs (the not-so-young inhabitants). The ability to use them as effective tools has come about primarily because of the proliferation of cloud computing infrastructures — system and application resources can be replicated multiple times and reside in various locations.

External SLA inhabitants span across the external cloud that can form complex relationships among the customers, vendors, network service providers, and other external organizations. Scalability is one of the cloud's biggest advantages. External providers have controls over the operating systems, servers, and external network infrastructure.

Internal SLA inhabitants are more popular with IT departments in major enterprises that have found the costs of transferring data across an external network to be very high. These enterprises are in charge of the operating systems, servers, and network infrastructure within their internal data centers.

Internalized SLAs are the best of two worlds. An external SLA sports a rider. This rider would allow the cloud consumer to transport, for example, PaaS applications from the external cloud to the company's internal data center. Upon arrival, the company's internal SLA that was dormant is re-activated.

The cloud consumer (acting in this case as the internal provider) will have more control over the operating systems, servers, and network infrastructure that it needs to fix the problems. The cloud consumer then returns the more robust PaaS applications to the external cloud after re-activating the external SLA.

That's the idea. Let's look at it more closely.

Common SLA characteristics

All inhabitants of the SLA land have one thing in common. SLAs as defined are expectations among two or more parties regarding service quality, priorities, and responsibilities. The Cloud Service Customer Council views cloud computing SLAs as written expectations for service between cloud consumers and providers. The Council provides guidance to decision makers on what to expect and what to be aware of as they evaluate and compare user SLAs from cloud computing providers.

It's characteristic of these inhabitants to seek inputs from all parties to the SLA in order for the SLA to succeed during times of a major reorganization, downsizing, and the consolidation of services. Another trait the SLA should have is the references to certificates to operate for the IT infrastructure underlying the cloud services.


Scenario 1: Internal SLA for private PaaS

The company as the internal provider is in charge of internal data center that provides traditional IT and internal cloud services. The company controls the operating systems, services, and network infrastructure that underlies its private IaaS's virtual machines. All PaaS applications sit on top of these virtual machines.

The company negotiates with the developers on an internal SLA for private PaaS. Included in the SLA are four thresholds (explained later):

  • User
  • Resource
  • Data requests
  • Response time

All SaaS users assigned co-residents on the PaaS report they have no problems with accessing the PaaS applications. There are no service interruptions. The performance of PaaS platform meets the guaranteed service availability levels set forth in the SLA. The SaaS end users' expectations have been met. All PaaS developers are happy.


Scenario 2: External SLA for private PaaS in the cloud

The company wants to put its private PaaS on top of the provider's public IaaS so it can scale up and down cloud resources needed to develop, test, and run PaaS applications. The operating systems, servers, and network infrastructure in the company's data center are similar to those in the external provider's data center.

Before migrating to the cloud, the company, as the cloud computing consumer, negotiates with the external provider for an external SLA for its private PaaS. As part of the negotiation, the cloud consumer has controls over all the applications found in a full business life cycle. The external provider has controls, at a minimum over:

  • Operating systems
  • Servers
  • Network infrastructure

These controls are more constrained than those assigned to PaaS application developers within the company's data centers.

The external provider limits negotiation with the company on the user, resource, and data request threshold levels. The provider allows SaaS end users to access the private PaaS applications in the cloud.

There are no service interruptions. All PaaS developers are happy.


Scenario 3: Internalizing cloud computing SLA

The company, as a cloud consideration, decides to negotiate with the same external provider about internalizing the SLA attached with a "conversion" rider. Invoking the rider allows the internal provider to return the private PaaS to the company's data center.

For example, if the performance report from the external provider shows, for example, that the PaaS applications have experienced frequent interruptions, the internal provider invokes the rider to return the PaaS. The company is in charge of the operating system, servers, and internal network infrastructure underlying virtual machines. It enforces its internal SLA.

When the company has fixed the problem, it has the option to return the private PaaS to the provider's public IaaS and reinstate the external SLA. If the company decides not to return the PaaS, it can exercise the exit clause in the external SLA's rider.


SLA choice: Pros and cons

As with everything else in life, there are pros and cons in choosing traditional IT and cloud services. We'll take a look at three variables influencing the choice of a SLA:

  • Flexibility
  • Security
  • Visibility

Flexibility

When the company runs the private PaaS within its data center, it assumes the role of an internal provider. The company has almost complete flexibility with the traditional IT services. Since the company is in charge of traditional IT services, it is flexible as to what it will want to do with the internal SLA.

When the company assumes the role as an external cloud service consumer, its flexibility over the cloud services is constrained by the way the external provider supplies PaaS controls. Another constraint is that the external provider may limit negotiation with the cloud consumer on data, resource, and data requests thresholds for the PaaS. These flexibility and other constraints upon the cloud subscriber are written in the external SLA.

The cloud subscriber also negotiates with the external provider on the internalized SLA which allows the consumer to return the private PaaS to its data center so that the consumer, as the internal provider, can have more controls over the PaaS.

Security

With traditional computing, the company is in charge of security. In the internal SLA, the company determines:

  • How tightly its systems are locked up.
  • Who has access to the applications.
  • Who else can share its processing and storage capabilities.

Since the external provider controls many of these aspects, it may limit negotiation with the cloud subscriber on security controls in the external SLA:

  • SaaS users have no security controls.
  • PaaS application developers have some security controls.
  • IaaS network infrastructure specialists have more security controls.

The customer also negotiates with the provider on when to internalize the SLA; for example, moving the private PaaS back to the cloud subscriber's data center to fix a PaaS security problem. When the problem is fixed, the private PaaS is returned to the cloud.

Visibility

In setting up the internal SLA, the company has high visibility as to how secure the internal cloud and IT services are. The company, as the external cloud consumer, may not have much visibility as to how secure the cloud service is. It will most likely share cloud resources with other companies without knowing who the other businesses are.


External controls for service model users

Terms and conditions in the SLA are influenced by:

  • How much control external providers assigned to each service model user type.
  • Impacts of controls on flexibility, security, and visibility variables.

SaaS users: The only control the end user has is to access the SaaS application whether they are private individuals, businesses (small or medium), or government agencies. At a minimum the subscriber should negotiate with the provider on meeting the user's expectations on access control, system, response time (throughput), and inquiry responses.

SaaS providers: At a minimum, the provider controls the operating systems, services, and network infrastructure. The provider may limit negotiation with a SaaS subscriber on access control of a particular SaaS application. For instance, the terms in the SLA may differ from SaaS application to another depending on the application criticality and the type and SaaS user's expectations.

PaaS application developers: The developer controls and protects all the applications found in a full business life cycle, The developer builds, deploys, and runs, say, a custom retail management application. As part of the business life cycle, the developer uses spreadsheets, word processors, billing, payroll processing, and invoicing. As a minimum, the subscriber should negotiate with the provider on meeting the developers' expectations on access control, system respond speed, and load balancing.

PaaS providers: At a minimum, the provider controls the operating systems, servers, and network infrastructure needed to run the PaaS. The provider may allow negotiation with application developers on the user, resource, and data request threshold levels.

IaaS infrastructure specialists: The specialist controls the operating systems, network equipment, and deployed applications at the virtual machine level. The infrastructure specialist can scale up or down the virtual services or blocks of storage area.

IaaS providers: At a minimum, the provider controls the infrastructure of traditional computing resources underlying virtual machines. The provider sets the user, resource, and data requests threshold levels, and may allow negotiation with the IaaS infrastructure specialist on setting limits on scalability.


Internal controls for service model users

The company as the internal provider has more control over the private PaaS after moving it from the public IaaS in the cloud to its internal data center. It now has more flexibility and visibility over the PaaS and determines how the PaaS applications should be accessed.

SaaS users: The only control the end user has is to access the SaaS applications running on the PaaS. If the SaaS end user is also a PaaS co-resident, he can provide PaaS developers with reports if his expectations have been met. At a minimum the internal subscriber (such as a department head) should negotiate with the company on access control, system response time (throughput), and inquiry responses to the applications running on the private PaaS.

SaaS providers: At a minimum, the internal provider controls the operating systems, services, and network infrastructure. The provider may limit negotiation with a SaaS subscriber on access control of a particular SaaS application. For instance, the terms in the SLA may differ from SaaS application to another depending on application, departmental, and internal IT resource priorities.

PaaS application developers: The developer controls and protects all the applications found in a full business life cycle created by the application development unit or department in the company, The developer re-builds, tests, debugs, and runs the application. As part of the business life cycle, the developer uses spreadsheets, word processors, billing, payroll processing, and invoicing.

The developer ensures the following conditions are met:

  • SaaS end users' expectations as co-residents on access control and system response.
  • PaaS developers' expectations on load balancing.

PaaS providers: At a minimum, the internal provider controls the operating systems, servers, and network infrastructure needed to run the PaaS. The provider negotiates with application developers on the user, resource, and data request threshold levels, as well as how much control the application developers can have over the operating systems and servers at the virtual machine level.

IaaS infrastructure specialists: The specialist controls the operating systems, network equipment, and deployed applications at the virtual machine level. The specialist ensures virtual machines are adequate for use by the PaaS developers.

IaaS providers: At a minimum, the provider controls the infrastructure of traditional computing resources underlying virtual machines. The provider sets the user, resource, and data requests threshold levels.


SLA service elements

At a minimum SLA service elements include:

  • Description of services
  • User controls
  • Threshold types
  • Incident handling
  • Security service

They apply equally to the internal, external and internalized SLA models.

Description of services

This element describes services provided and the effective dates of agreement between a service provider and a cloud subscriber. The services are grouped into application or user groups depending on the objectives of the SLA.

User controls

This element describes user controls assigned by the provider depending on the cloud services the provider supplies to the cloud subscriber. If the company is the internal provider, it is in charge of running IT services and assigning user controls. If the company is an external cloud subscriber, its flexibility over the cloud services and user controls is constrained by the way the external provider supplies services to the cloud subscriber.

Threshold types

At a minimum, thresholds are grouped into:

  • User thresholds: Maximum number of developers who can concurrently access, develop, and run the application.
  • Resource thresholds: Maximum resource availability for consumption and scalability.
  • Data requests thresholds: Maximum number of data requests in queue the developers can send concurrently.
  • Response time thresholds: Service responding within a reasonable time to service time-outs and data requests from a service user.

Cloud user control over each threshold type depends on the type of cloud service the provider supplies to the cloud consumer. For example, the SaaS consumer must negotiate with the external provider on the number of users in a user license.

Incident handling

This element is the service that alerts the provider and cloud consumer and provides event escalation and remediation on system intrusion.

Security service

This element is the service that provides cloud service vulnerabilities updates, daily backups, failover and disaster recovery plans, and intrusion prevention tools.


SLA service constraints

Some service exceptions that can be potentially included in a SLA are denial of service, scheduled maintenance, service priority, and exit clause.

Denial of service includes client willful misconduct, network attacks, acts of God, and war strikes that render the system useless.

Scheduled maintenance covers software and operating system installations, patch ups and upgrades, and periodic malicious intrusion checks.

Service priority differs from one cloud user to another depending on:

  • User roles and responsibilities
  • Application priority
  • Network resource priority

Exit clause must specify whether it pertains to a specific or a set of cloud-based applications.


SLA management policy

To ensure the success of internalizing an SLA, a SLA management policy should be in place. If the company has to monitor only one internal SLA and one external SLA attached with a rider for internalizing the SLA, then SLA management is one of the many responsibilities of an IT manager. The policy would mercifully be short.

If the company has several SLAs to oversee — not just internal, external, and internalized SLAs, but also SLAs cover being a vendor or a content provider to other companies — then the company would need an SLA management officer as a full-time job. The policy would be longer.

Basic policy elements include purpose, scope, background, responsibilities, and constraints. At a minimum, the SLA management officer is responsible to:

  • Provide training sessions.
  • Resolve problems with the other parties.
  • Keep all parties informed of the SLA status.
  • Facilitate meetings and discussions about services.
  • Analyze data underlying the SLA problems.
  • Be skilled in communications and negotiations.
  • Coordinate in modifying the SLAs.
  • Conduct periodic SLA reviews.

In conclusion

Internalizing any SLA requires planning ahead of time to resolve the issues of how the SLA should be negotiated and managed. Internal and external providers must work together to resolve issues of SLA internalization. Consider an SLA management officer to craft a policy on managing multiple SLAs.

Resources

Learn

Get products and technologies

Discuss

  • Get involved in the developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Cloud computing on developerWorks


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • developerWorks Labs

    Experiment with new directions in software development.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • Try SoftLayer Cloud

    Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Cloud computing
ArticleID=861194
ArticleTitle=Build multiple-user cloud policies with internalized SLAs
publish-date=03122013