5 Service Management, SLAs, and Economics

5.1 Start With What “Service Management” Actually Buys You

The last three chapters asked what cloud is, which service model to use, and how to deploy and virtualize it. Now ask how to run, measure, and pay for the service. Cloud service management aims to keep on-demand virtual services useful and efficient. It gives the customer’s goals equal weight and aims to add no cost or risk for them. This chapter covers the service level agreement (SLA), accounting and billing, the economics of scaling, and the cloud database layer as tools for that work.

5.2 Service Management Objectives and the Service Level Agreement

Service management helps a customer choose a service, use it, and judge whether it meets their needs. A clear description and a selection portal make the offer easier to understand. Usage monitoring makes charges traceable, while availability and security practices help the service run reliably. The customer can compare these aims with the provider's actual terms and evidence. IBM's 2010 framing names nine objectives:

A service can do the right job yet still be too slow or often unavailable. These qualities are called non-functional requirements: they describe how well a service works rather than which task it performs. An SLA is a written agreement that sets out service expectations and how they are measured. Read its scope, measurement method, exclusions, and remedy as well as the target number.

The SLA model described by K.T. Kearney and F. Torelli (2011) uses the terms quality, utility, and warranty. Quality describes how well the service performs. Utility is what the service does for the customer, or whether it is fit for the intended purpose. Warranty concerns whether it is fit for use, such as being available when needed. For example, a storage service may provide a way to save files (utility) and an uptime commitment (warranty).

Moving to cloud changes where control sits rather than removing operational duties. Figure 5.1 compares capacity, failure, energy, and security boundaries side by side.

+

In Figure 5.1, start with CAPACITY: an owner buys room for peak demand, while a cloud user can add capacity and pay for its use. Next, FAILURE shows that a cloud user still needs to design for outages, such as by using more than one zone. The energy row asks what evidence is available for each setting. Finally, SECURITY shows shared duties: the provider runs the cloud, but the customer must still manage access, retention, and recovery. These choices affect both risk and cost.

5.3 Paying For It: Accounting, Billing, and Cloud vs. Traditional Economics

A service promise tells a customer what to expect. A bill answers a different question: what did the customer use, and what does that use cost? Accounting records usage; billing applies prices and rules to those records. For example, 120 compute-hours at $0.10 per hour cost $12 before any other charges or discounts. Storage and network use can add separate charges. A meter reading alone is not an invoice.

The accounting step relies on monitoring to measure resources and make usage records. Billing combines those records with rates and the provider’s rules, such as a free allowance or a discount. The cloud supply chain framework by Lindner and colleagues (CloudComp 2010) separates these steps so a customer can trace a charge back to its use.

Owned data centers and cloud services also differ in how capacity is paid for. An owner buys and maintains hardware, often with spare room for peaks. A cloud customer rents resources and can adjust capacity as demand changes. Both can use varied hardware and networks. Cloud hosting is often off premises and virtual, but those traits alone do not make it cheaper. Compare resilience and elasticity, flexibility and scalability, automation, running costs, and security for the actual workload.

Shared capacity can improve use of a provider’s equipment. The economics-of-scaling framework in Kevin L. Jackson’s 2011 article names four factors: the number of unique customer sets, their duty cycles, the relative timing of those cycles, and each set’s load. A duty cycle describes when a customer is active. If one customer’s peak occurs while another is quiet, the provider can serve both with less spare capacity than if their peaks coincide. This benefit depends on the shape and timing of demand, not customer count alone.

The same source lists six possible incentives: lower cost, computing without capital expense, faster projects and innovation, scaling as needed, lower maintenance costs, and resilience through redundancy. These are potential benefits, not guarantees. For a fair choice, include usage rates, data transfer, support, and the cost of the safeguards the workload needs.

5.4 Under the Hood: Managing Data in the Cloud and Database-as-a-Service

A database must fit the work it serves before its price can be judged. Start by defining the application, such as an online store or a data analysis system. Next ask whether a public or private cloud suits its needs. Then identify what developers need to build and operate it with ease.

A cloud database management system (DBMS) faces five demands described by D. Abadi (IEEE Data Engineering Bulletin, 2009). It should use resources efficiently and tolerate faults. It should adapt to varied hardware and data, work with encrypted data when needed, and connect to other products. The need to query encrypted data is a demanding requirement: check which operations a product supports and what protection they provide. Do not assume that every managed database can perform every query without decryption.

For example, a team storing sensitive records may need both queries on encrypted data and a link to its existing tools. Those map to encrypted-data operation and interoperability. Good speed and recovery alone do not prove either capability. Test each requirement against the product and the team’s threat model: which attackers and kinds of access the team needs protection against.

Database-as-a-Service (DBaaS) lets a customer use a managed database while the provider handles some operating tasks. The exact split of duties varies by product; the customer may still own access rules, data, and recovery choices. The source names examples including Azure SQL Database, Amazon DynamoDB and RDS, Google Cloud SQL and App Engine Datastore, ClearDB, and Database.com. This historical list is not a current catalog. Check each provider’s current service, features, and terms before making a choice.

The panel challenges the idea that speed and recovery are the only needs in this case. Look at the sensitive records first: the team wants to work with data that remains encrypted. Then follow the link to the other tools, which shows the need for the database to connect to the existing stack. Those are two distinct demands. A fast system that recovers from a failure may still lack the needed encrypted operations or interfaces, so each one needs its own check.

5.5 Summary

Service management turns a cloud service into something a customer can use, measure, and hold to account. An SLA sets out service expectations and how they are measured. Accounting records usage, then billing applies rates and rules. Shared capacity can lower costs when customer loads peak at different times, but the savings depend on the workload and the contract. A cloud database must also meet the needs of its data and users; a managed product does not remove the need to check its features and shared duties.

5.6 Key Takeaway

Check the promise, the bill, and the database against your workload.

5.7 See Also

The related pages connect these service terms to earlier choices and to the work of running an IoT deployment. Follow the first two links for the cloud foundations, or the last for an applied launch example.