|
Organizations are depending more and more on services provided by cloud service providers. The benefits of using the cloud are well-documented, including the ability to scale capacity in a manner that is impossible with conventional data centers. Cloud service providers also allow organizations to outsource email, document management and even human resource services, thus focusing on their core expertise. However, it is worth being mindful of the famous quote (by Leslie Lamport) that “A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable.” In the case of an organization using cloud services, the failure of a computer you didn't even know existed and isn’t under your control and may not even be in the same country as you can render your business inoperable. This has occurred recently with the well-publicized Amazon outages. How can an organization control against this happening? This question leads back to why a service-level agreement (SLA) is critical. A reader may ask "Don’t cloud service providers have SLAs?" It is true that most have SLAs. However, it also must be noted that cloud service providers are more open to negotiating SLAs with larger organizations. In the case of small-to-medium-sized businesses they are more likely to simply cite performance metrics, as opposed to committing to a SLA. It’s also worth noting that even when a cloud service provider provides an SLA — the coverage may be inadequate. As a result, organizations (with or without SLAs) are often in a position where they have to trust the cloud service provider’s metrics and billing information. This approach raises many questions. For example, can an organization independently verify if the information provided by the cloud service provider regarding usage and uptime is accurate? Or in the event of a billing dispute with a cloud service provider, how does an organization provide an independent audit trail of the services they have used? For example, if a cloud service provider has a service lapse at 4:00am, will an organization have independent evidence of this situation? Or will the organization have to depend on the cloud service provider, or in the worst case scenario, its customers who tweet the outage, to inform them of an outage? Access to this type of independent information is critical and is especially important in any discussions of that need to be resolved via legal means. Don’t Trust, But Verify This mantra of "don’t trust but verify" could be useful for organizations to adopt as they drive better controls around the use of cloud services. One solution to this issue of control is to use a broker product, a cloud service broker, to meter the connections to the cloud service provider. A cloud service broker uses a pattern whereby an intermediary sits between the consumer (the organization) and the cloud service provider. Once in this position, the broker product can monitor the traffic and usage, all the time laying down its own audit trail. Independent Audit Trail of Cloud Usage This independent audit trail is similar to a consumer having an additional independent way of measuring cell phone usage — in addition to the bill provided by the cell phone provider. One of the key advantages of the cloud service broker is that it allows for SLA information to be collected for cloud services, from the point of view of the client. This allows the user of the cloud service broker to deal with one interface, which represents a contract, and then the broker connects to the services on the client's behalf. In fact, it's the broker product’s job to take the SLAs and translate them across subscribing service providers that may each have their own proprietary interface. What happens if an organization chooses not to run its cloud usage through a broker product? An organization may choose the option of baking monitoring capabilities into applications. This means the application that’s consuming the cloud service is also monitoring the cloud service provider. As such, this application would be responsible for raising alerts if the cloud service provider is not delivering the expected service level and response time. However, this approach places a lot of responsibilities on an application, as it expects the application to consume the cloud service, monitor the service and lay down audit information. The organization may say, "We trust the cloud service provider to say when their system is having problems". But that approach is not fool-proof and is effectively all "Trust" and no "Verify." Inevitable Onward March |
VordelThe VisionLeadership Investors Careers Events News |
SolutionsAPI ManagementGovernance Cloud Security Mobile Access Sharepoint/Siebel Replace Gateway |
ResourcesWorkshopsArticles Most Popular Datasheets Deployment Guides API Management B2B Integration Cloud Integration Gateway 101 Identity Management Mobile SOA Governance |
MediaEventsNews Blog |
Get HelpContact UsCustomer Support |
Follow Us on:©2013 Vordel Inc., |