Cloud Based Service Level Agreements A common theme in the chatter about cloud computing is the need for SLAs around performance and availability. These SLAs simply don’t exist or are specified in a way that makes them look like they’ll never be violated. For example, Amazon’s availability SLA is around the network connectivity for an entire availability zone. So if you have a single instance that can access the internet (whether or not your app will run on it), there is no violation. This is hardly a new state of affairs and there doesn’t seem to be much change coming
Service level agreement
Accelerating vs. deflating time to SaaS revenue Over the past 8 months, we have seen an increase in the number of ISVs contacting us to help them plan a roadmap to SaaS. After reviewing these conversations, a trend has started to emerge. 1. On-Premise ISVs see the need to begin the journey, typically due to competitive and market pressures. 2. They understand and want to get to the technical end game — a true multi-tenanted, singular code basis — but they don’t know how or even why they should get there. 3. They want to get to that end game
Service Level Agreements should ideally be agreements that describe the services delivered, customer obligations, warranties, disclaimers, service management levels, service availability and termination clauses. There are some important factors that the buyer should consider when discussing the SLA with a provider: How do the provider calculate the availability figure? You need to understand their formula and also ask if the calculation is based per month, quarterly, annually or something else. How does the service schedule look like (planned maintenance)? Does the provider have some disclaimers in regard to “software failures”? Response times and latencies: How are they measured? Start time
