Build proactive threshold policies on the cloud

Discover the impact of purpose, scope, background, consumer control, actions, and constraints

Often businesses and agencies implement technical, organizational, and business policies to ensure that users comply with the terms in the policy; in other words, to inform cloud computing service consumers and providers what they should do. This is the purpose of a carefully crafted threshold policy — too often, this level of policy does not exist. In this article, the author explains how to craft the policies with examples; follow these templates on purpose, scope, background, consumer control, actions, and constraints to learn to craft resource, user, and data request threshold policies for the cloud.

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.



30 May 2011

Also available in Chinese Japanese Spanish

Develop skills on this topic

This content is part of a progressive knowledge path for advancing your skills. See Cloud computing: Build an effective cloud policy

A carefully crafted threshold policy outlines what cloud computing service consumers and providers should do and can save providers countless hours of management time to develop the following policies:

  • Resource threshold policy: Ensures resource consumption is balanced dynamically for applications in the cloud below or at the threshold level.
  • User threshold policy: Ensures users can access concurrently the application up to the limit specified in a user license from the provider below or at the threshold level.
  • Data request threshold policy: Ensures data requests to the application can be processed immediately below or at the threshold level.

Each threshold policy is primarily shaped by three things:

  • What type of cloud service the provider hosts — Software as a Service (SaaS), Platform as a Service (PaaS), or Infrastructure as a Service (IaaS).
  • Whether it is public or private.
  • How much control the consumer has over the operating systems, hardware, and software.

Other variables to consider that can affect the policy landscape:

  • What proactive behavior application changes took place in order for an in-house application to work perfectly well in the cloud.
  • Whether the provider is internal within an organization-controlled data center or hosted externally by a member of the telecommunications industry.
  • And whether the type of industry the consumer represents is broad, such as retail, energy and utilities, financial markets, health care, or chemical and petroleum.

To satisfy consumer demand to review threshold policies, all providers should provide consumers with copies of the policies. The providers should encourage consumers to send questions that might need to be resolved or require negotiation before the consumer rents or subscribes to a cloud service type.

This article begins with an example of how a threshold policy is used and discusses how to use a checklist to get started on writing the policy with examples on purpose, scope, background, consumer control, actions, constraints and definitions.

Rehearse your own threshold policy drama

One of my major themes in writing about cloud-based policy creation (policies for any computing system, actually) is that you should be proactive: It's always a good idea to have a feel for how a threshold policy can affect your system. In one fictitious drama, a retail industry consumer of a cloud service had a large-scale application at a data center that did credit card validation in the cloud while workload demands were below the threshold level as set forth in the resource threshold policies. Number of users and data requests were also below the threshold level as set forth in the user and data requests threshold policies.

When the Christmas buying season crunch hit, the system detected higher workload demands exceeding threshold levels. In response, the system quickly created additional instances of resources to balance workload demands dynamically. This required additional users and higher number of data requests (both up to the limit specified in a user license).

As the retailer moved out of the buying crunch, the workload demands fell below the threshold level so instances of the resources in the cloud that were created were freed up. This reduced the number of users and data requests required to handle the workload demands.

Since this organization has some control over the hardware, they are able to negotiate with the cloud service provider on the terms set in the threshold policies. (It's always good to negotiate the parameters of the policy before the buying crunch.)


Pencils ready: Your checklist

Don't know where to start to build your own threshold policy? No worries; I present you with a checklist of what should be included in a threshold policy. Regardless of the type of policy you want to end up with, they all pretty much should include these elements:

  • Purpose: Reach for the goal
  • Scope: Put a fence around the policy
  • Background: Look what's behind the policy
  • Consumer control: How much? A lot? A little bit?
  • Actions: Ready? Roll up your sleeves
  • Constraints: Work with them

You can either develop each policy type individually or combine all three policy types — resource, user, data request — into one threshold policy. In a simplified scenario, I'll offer the all-in-one approach and give you a hint on what to do for each checklist item.

Purpose: Reach for the goal

To reach the goal of implementing threshold policies, briefly state what the policy is intended to do. You can use a template like this to give you an idea how to state the purpose:

The purpose of the policy is to help cloud service providers implement:

  • Resource threshold policy to ensure resource consumption is balanced dynamically for applications in the cloud at a specified threshold level.
  • User threshold policy to ensure users can access concurrently cloud applications at a specified threshold level below the maximum limit specified in a user license from the provider.
  • Data request threshold policy to ensure data requests to the applications sent by users concurrently can be processed immediately.

Scope: Put a fence around your policy

You define the scope by "putting the fence" around this policy. Within this boundary, you specify which cloud service types the provider hosts and the consumers rents or subscribes. You specify what the provider needs to do and how consumers can work with SaaS, PaaS, or IaaS individually or with all of them.

For example, if the provider hosts all three cloud service types, he needs to state whether:

  • The end user rents only a specific application.
  • The application developers rents only the PaaS to customize or change parameters to a specific SaaS application running on the PaaS.
  • The application developers and their SaaS users can purchase subscriptions to a co-resident SaaS application on the PaaS.
  • The infrastructure and network specialist rents the infrastructure (IaaS) to build a virtual infrastructure environment and to run the PaaS on this IaaS.

The provider needs to find out if the consumer will stay within the fence (comply with the terms of the policies). If the consumer strays out of the fence after agreeing to comply, the consumer runs the risk of violating the policy. In this case the provider must indicate the consequences of not complying to make sure the consumer stays within the fence.

Here is a template you can use to give you an idea how to state the scope:

  • This policy applies to all SaaS end users, PaaS application developers, and IaaS infrastructure and network architects. All end users, developers and architects consent to all of the provisions of this threshold policy and agree to comply with all of its terms and conditions. Any end users, developers and network architects whose actions violate this policy or any other related IT policy or regulations shall be subject to limitations or loss of service with the provider.

Background: Look what's behind the policy

The very first thing the consumer wants to know is whether the provider is internal or external. The next thing is what proactive behavior application changes were made to get threshold levels in an in-house application to work well in the cloud.

The consumer also wants to know how threshold levels are related to guaranteed levels of service availability as set forth in a service level agreement (SLA). For example, back to the Christmas buying crunch; this type of event causes resource instances to surge exceeding the threshold level and the system creates additional instances of resources to balance workload demands dynamically resulting in the need for additional users and data requests.

In the Christmas crunch drama, resource instances surge beyond the threshold level causing the system to create additional resource instances. Now let's pretend the drama goes into the next scene where the consumer is watching the dashboard showing how performance is sliding down due to unexpected system problems. The consumer demands the system be restored quickly and credits free time, or the right to terminate (not practical and unlikely, of course, during the buying crunch) as set forth in the SLA.

You can use a template like this to give you an idea what you should include:

  • The cloud service provider is hosted externally by IBM®, a member of the telecommunication industry.
  • If a surge in workload demands, users and data requests exceed threshold levels and will cause system performance to slide down from the guaranteed levels of availability for 30 days, the provider must give consumers credits, free time, or the right to terminate the service as set forth in the SLA. The provider must notify the consumer of the exceptions or constraints to the threshold policies.
  • A user license contains three types of maximum limits:
    • Users accessing concurrently the application.
    • Resource instances to be allocated to each user.
    • Data requests the user can handle during a surge in workload demands.
  • The provider will send the consumer a notice on the effective date of proactive behavioral changes to SaaS personnel applications.

Consumer control: How much? A lot or a little bit?

How much control should the consumer have over deployed applications, operating systems, storage, or networking? This depends on the role of a consumer — whether he's a SaaS end user, PaaS application developer, or IaaS infrastructure or network specialist.

  • A SaaS end user has access to the provider's application from a desktop or mobile device to process business tasks. That is all the control the end user has.

    The SaaS provider controls deployed applications, operating systems, storage, or networking.

  • A PaaS application developer controls all the applications found in a full business life cycle for the platform. A PaaS application developer controls all the applications found in a full business life cycle for the platform (for example, spreadsheets, word processors, backups, billing, payroll processing, and invoicing). The developer can build, deploy, run, and manage upgrades and patches to all functionalities of, say, a retail management application.

    The PaaS provider controls the operating system, hardware, or network infrastructure on which the applications are running.

  • An IaaS infrastructure architect controls: Operating systems, network equipment, and deployed applications at the virtual machine level, scaling the number of virtual servers or blocks of storage area up or down. An IaaS infrastructure and network specialist controls the OSs, network equipment, and deployed applications at the virtual machine level. This consumer can scale the number of virtual servers or blocks of storage area up or down.

    The IaaS provider controls the infrastructure of traditional computing resources in the cloud environment.

Each subsection you've just read provides the template you can use to define control attributes.

Actions: Roll up your sleeves

Here are some suggestions for actions to make consumers happy:

  • Action #1. Send consumers copies of the threshold policies for review and questions to be resolved before the consumer signs up for a cloud service.
  • Action #2. Indicate in a user license for a SaaS application a change in the maximum limit on concurrent users, resource instances for those users and data requests each user can handle.
  • Action #3. Establish threshold levels for the resource, user, and data requests threshold policies and reference each threshold policy to the guaranteed levels of service availability.
  • Action #4. Send notice to the consumer on planned proactive behavior changes to the application developed at a data center intended to replace the application currently running in the SaaS cloud.
  • Action #5. Permit the PaaS application developers and their SaaS users to subscribe to a co-resident SaaS application.

And here are some templates you can use:

  • Resource threshold policy: The provider sets resource threshold levels below the maximum number of additional resources to be consumed. The policy must state that resource threshold levels be below or at the guaranteed level of service availability forth in the Service Level Agreement (SLA).
  • User threshold policy: The provider sets user threshold levels below the maximum number of users that can access concurrently. The policy must state that the number of concurrent users is in proportion to the number of resource instances available to the users.
  • Data request threshold policy: The provider sets data request threshold levels below the maximum number of data requests and the maximum size of data requests that users can send concurrently. The number and size of data requests depend on the specifications in a user license for a cloud service type.
  • SaaS user license: The provider sets maximum limit on:
    • Users that can concurrently access the application.
    • Resource instances that users can use to access and run the application.
    • Data requests that users can send and receive concurrently using the available resource instances.

Constraints: Work with them

There will most probably be some constraints in your way, such as:

  • Service priority issues to different groups of consumers, depending on the roles assigned by the organization to consumers. An end user with administrative privileges has a higher priority over the end user that does not have them in accessing a SaaS application.
  • Change management governance groups. To reflect any changes, update the threshold policies and SLA.
  • Service exceptions to the threshold policies and the SLA. I'll give you a hint: Accidental of cutting fiber optics not being within direct control of the provider, scheduled maintenance (planned and unplanned), and proactive behavioral changes to applications migrating from in house to the cloud.
  • Service penalties when excess threshold levels results in system performance sliding down significantly from the guaranteed level of service availability. Give the consumer the right to get credits, refunds, or free or months as long as failure of guaranteeing the service is not a service exception. Specify in an exit clause on the process of enforcing the consumer's right to terminate a cloud service.

When you find constraints blocking you, the best thing is to work with them. First, you can use constraints to enhance security posture to threshold policies. Second, if there is a surge in work demands that exceed threshold levels, get ready with remedies to protect the consumer if system performance slides down from guaranteed levels of service availability.

Here are some templates you can use:

  • SaaS end user who functions as an administrator of a user license has a higher priority over other end users in accessing a licensed application.
  • An exit clause in the SLA is enforced when the provider allows the consumer to terminate the SLA after a specified period of time.
  • Due to recent organization change, policy governance group moved from Department ABC to Department XYZ. This requires an update to both threshold policies and the SLA.
  • Service exceptions currently cover:
    • Accidental cutting of fiber optics cables and other network issues not within the direct control of the service provider.
    • Denial of service attack against the provider's host.
    • Provider's scheduled maintenance.
    • Provider's service availability from 8 AM to 5 PM.

In conclusion

Crafting a threshold policy on resource, user, and data requests threshold levels requires plenty of pre-planning to resolve the issues on how purpose, scope, and background of the policy should be stated. Developers must communicate with the both the cloud service consumer and provider on the issues of how much control a consumer should have, what actions the provider should take, and what the probable and actual constraints to the policy are. Like with everything else in life, the most important thing of all do as a cloud consumer is to get a copy of the policy from the provider for review and resolve your position on any questions you have before negotiating with the provider.

Resources

Learn

Get products and technologies

Discuss

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=660834
ArticleTitle=Build proactive threshold policies on the cloud
publish-date=05302011