Programming4us
         
 
 
Programming

Security Management in the Cloud - SaaS Availability Management

12/4/2010 3:26:08 PM
By virtue of the service delivery and business model, SaaS service providers are responsible for business continuity, application, and infrastructure security management processes. This means the tasks your IT organization once handled will now be handled by the CSP. Some mature organizations that are aligned with industry standards, such as ITIL, will be faced with new challenges of governance of SaaS services as they try to map internal service-level categories to a CSP. For example, if a marketing application is considered critical and has a high service-level requirement, how can the IT or business unit meet the internal marketing department’s availability expectation based on the SaaS provider’s SLA? In some cases, SaaS vendors may not offer SLAs and may simply address service terms via terms and conditions. For example, Salesforce.com does not offer a standardized SLA that describes and specifies performance criteria and service commitments. However, another CRM SaaS provider, NetSuite, offers the following SLA clauses:

Uptime Goal—NetSuite commits to provide 99.5% uptime with respect to the NetSuite application, excluding regularly scheduled maintenance times.

Scheduled and Unscheduled Maintenance—Regularly scheduled maintenance time does not count as downtime. Maintenance time is regularly scheduled if it is communicated at least two full business days in advance of the maintenance time. Regularly scheduled maintenance time typically is communicated at least a week in advance, scheduled to occur at night on the weekend, and takes less than 10–15 hours each quarter.

NetSuite hereby provides notice that every Saturday night 10:00pm–10:20pm Pacific Time is reserved for routine scheduled maintenance for use as needed.

Here is another SLA example:

During the Term of the applicable Google Apps Agreement, the Google Apps Covered Services web interface will be operational and available to Customer at least 99.9% of the time in any calendar month (the “Google Apps SLA”). If Google does not meet the Google Apps SLA, and if Customer meets its obligations under this Google Apps SLA, Customer will be eligible to receive the Service Credits described below. This Google Apps SLA states Customer’s sole and exclusive remedy for any failure by Google to provide the Service.

Monthly Uptime PercentageDays of Service added to the end of the Service term, at no charge to Customer
< 99.9% – ≥ 99.0%3
< 99.0% – ≥ 95.0%7
< 95.0%15

Customer Must Request Service Credit. In order to receive any of the Service Credits described above, Customer must notify Google within thirty days from the time Customer becomes eligible to receive a Service Credit. Failure to comply with this requirement will forfeit Customer’s right to receive a Service Credit.

Maximum Service Credit. The aggregate maximum number of Service Credits to be issued by Google to Customer for any and all Downtime Periods that occur in a single calendar month shall not exceed fifteen days of Service added to the end of Customer’s term for the Service. Service Credits may not be exchanged for, or converted to, monetary amounts.

Google Apps SLA Exclusions. The Google Apps SLA does not apply to any services that expressly exclude this Google Apps SLA (as stated in the documentation for such services) or any performance issues: (i) caused by factors outside of Google’s reasonable control; or (ii) that resulted from Customer’s equipment or third party equipment, or both (not within the primary control of Google).

There is no such thing as standard SLA among cloud service providers. Uptime guarantee, service credits, and service exclusions clauses will vary from provider to provider.

1. Customer Responsibility

Customers should understand the SLA and communication methods (e.g., email, RSS feed, website URL with outage information) to stay informed on service outages. When possible, customers should use automated tools such as Nagios or Siteuptime.com to verify the availability of the SaaS service.

As of this writing, customers of a SaaS service have a limited number of options to support availability management. Hence, customers should seek to understand the availability management factors, including the SLA of the service, and clarify with the CSP any gaps in SLA exclusions and service credits when disruptions occur. In a recently published white paper by the U.S.-based Software & Information Industry Association (SIIA), the efficacy of SaaS SLAs was analyzed in the context of software vendors moving to a SaaS delivery model. The paper concluded that certain elements are necessary to make the SLA an effective document, and states that:

Communication and clear expectations are required from both the service provider and their customers to identify what is important and realistic with respect to standards and expectations.

Customers of cloud services should note that a multitenant service delivery model is usually designed with a “one size fits all” operating principle, which means CSPs typically offer a standard SLA for all customers. Thus, CSPs may not be amenable to providing custom SLAs if the standard SLA does not meet your service-level requirements. However, if you are a medium or large enterprise with a sizable budget, a custom SLA may still be feasible.

Since most SaaS providers use virtualization technologies to deliver a multitenant service, customers should also understand how resource democratization occurs within the CSP to best predict the likelihood of system availability and performance during business fluctuations. If the resources (network, CPU, memory, storage) are not allocated in a fair manner across the tenants to perform the workload, it is conceivable that a highly demanding tenant may starve other tenants, which can result in lower service levels or poor user experience.

2. SaaS Health Monitoring

The following options are available to customers to stay informed on the health of their service:

  • Service health dashboard published by the CSP. Usually SaaS providers, such as Salesforce.com, publish the current state of the service, current outages that may impact customers, and upcoming scheduled maintenance services on their website (e.g., http://trust.salesforce.com/trust/status/).

  • The Cloud Computing Incidents Database (CCID). (This database is generally community-supported, and may not reflect all CSPs and all incidents that have occurred.)

  • Customer mailing list that notifies customers of occurring and recently occurred outages.

  • Internal or third-party-based service monitoring tools that periodically check SaaS provider health and alert customers when service becomes unavailable (e.g., Nagios monitoring tool).

  • RSS feed hosted at the SaaS service provider.

Other -----------------
- Security Management in the Cloud - Availability Management
- Security Management in the Cloud
- The Art of SEO : Trending, Seasonality, and Seasonal Fluctuations in Keyword Demand
- The Art of SEO : Leveraging the Long Tail of Keyword Demand
- The Art of SEO : Determining Keyword Value/Potential ROI
- Identity and Access Management : Cloud Service Provider IAM Practice
- Identity and Access Management : Cloud Authorization Management
- Identity and Access Management : IAM Practices in the Cloud (part 2) - Federated Identity
- Identity and Access Management : IAM Practices in the Cloud (part 1) - Cloud Identity Administration
- iPad SDK : Keyboard Extensions and Replacements (part 4) - Creating the Calculator
- iPad SDK : Keyboard Extensions and Replacements (part 3) - Creating the Keyboard Input View
- iPad SDK : Keyboard Extensions and Replacements (part 2)
- iPad SDK : Keyboard Extensions and Replacements (part 1) - Adding a Keyboard Button in Dudel
- iPad SDK : New Input Methods - Gesture Recognition
- iPad SDK : New Input Methods - Menu Additions
- iPad SDK : Implementing an About Panel in a Modal Way (part 2)
- iPad SDK : Implementing an About Panel in a Modal Way (part 1) - Creating the Modal Web View Controller
- Parallel Programming with Microsoft .Net : Dynamic Task Parallelism - Variations
- Keyword Research Tools (part 7) - comScore Marketer
- Keyword Research Tools (part 6)
 
 
Most View
- Perform a Readiness Check Using the Exchange Best Practices Analyzer
- Exchange Server 2010 : Upgrading from and Coexisting with Exchange Server 2007 (part 2) - Upgrading Message Connectivity From Exchange Server 2007
- Exchange Server 2010 : Managing Details Templates
- Windows 7 : Troubleshooting Strategies - Determining the Source of a Problem (part 2)
- Windows 7 : Preventing Users from Logging On at Certain Times
- Windows Small Business Server 2011 : A Networking Primer - Networking Hardware
- Windows Server 2008 : Configuring SMTP (part 6) - Using an SMTP Virtual Server
- Windows Phone 7 : Setting Up E-Mail and Your Calendar
- Using Non-Windows Systems to Access Exchange Server 2007 : Terminal Server Client for Mac
- Exchange 2007 : Install an Edge Transport Server
Top 10
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 3) - Configuring Recipient Filtering
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 2)
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 1)
- Implementing Edge Services for an Exchange Server 2007 Environment : Installing and Configuring the Edge Transport Server Components
- What's New in SharePoint 2013 (part 7) - BCS
- What's New in SharePoint 2013 (part 6) - SEARCH
- What's New in SharePoint 2013 (part 6) - WEB CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 5) - ENTERPRISE CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 4) - WORKFLOWS
- What's New in SharePoint 2013 (part 3) - REMOTE EVENTS