5 Service Management, SLAs, and Economics
5.1 Start With What “Service Management” Actually Buys You
The previous three chapters answered architecture questions: what cloud computing is, which service model a workload uses, and which deployment model and virtualization approach its infrastructure runs on. This chapter answers the operational question sitting underneath all of that once the architecture is chosen: how does the resulting service actually get run, measured, and paid for? Cloud service management “deals with the world of cloud computing and service management, ensuring optimal performance and efficiency in on-demand, virtual environments” – and it aims to give equal importance to the customer’s desired outcomes, managing services at no added cost or risk to the customer. The SLA, accounting and billing, the economics of scaling, and the cloud database layer this chapter covers are each a specific instrument for delivering that promise.
Not the same question as the sibling chapters: Production Cloud Deployment for IoT and Cloud Platform Queues ask “what launch checks, cost controls, and capacity records does an IoT deployment need?” This chapter asks the question underneath those: “what is an SLA, an accounting-to-billing pipeline, and a DBaaS product, mechanically, before any IoT operations decision gets made?”
5.2 Service Management Objectives and the Service Level Agreement
IBM’s own 2010 framing names nine objectives a cloud service-management practice is expected to deliver:
Standard Services
Clear & Complete Description of Services
Usage Monitoring and Billing
High Availability of Networks and Connectivity
Ease of Access
Portals for Service Selection
Rapid Fulfillment/Decommissioning of Resources
Service Guarantees
Secure Computing and Storage
The Service Level Agreement (SLA) is where several of those objectives – clear description of services, service guarantees – become a written commitment. An SLA defines the non-functional requirements expected from the service provider, provides a roadmap with clearly defined deliverables, and describes the quality, utility, and warranty of services the customer expects (K.T. Kearney & F. Torelli, “The SLA Model,” 2011).
What varies by provider, and what does not. The exact metric behind each SLA term differs from one service provider to the next – but the areas those metrics cover stay the same across providers: volume and quality of work, speed, and efficiency. Reading an unfamiliar SLA is a matter of finding where each of those four areas is measured, not learning a new vocabulary for each vendor.
5.3 Paying For It: Accounting, Billing, and Cloud vs. Traditional Economics
Turning a service guarantee into an actual invoice runs through two named steps:
Service Accounting
Aims to obtain resource-usage information, typically in the form of records. This depends on infrastructure and service monitoring, since usage information is obtained from metric measurements.
Billing
The service provider calculates billing information using three inputs together: the accounting records, the resource prices, and the provider’s own billing rules.
(M. Lindner, F. Marquez, C. Chapman, S. Clayman, D. Henriksson, and E. Elmroth, “The cloud supply chain: A framework for information, monitoring, accounting and billing,” CloudComp 2010.)
That accounting-then-billing pipeline sits inside a bigger economic contrast: traditional, owned infrastructure versus cloud infrastructure. The source frames each side by its own defining traits rather than a row-by-row comparison:
Traditional Data Centers
- Heterogeneous hardware
- Networked computing
- Remote server
Cloud Computing
- Off-premises
- Virtual hosting solution
- Heterogeneous hardware, software, and networks on the cloud
The source then names five dimensions where the two approaches diverge most, without elaborating on each individually: resilience and elasticity, flexibility and scalability, automation, running costs, and security. (Wikipedia – Cloud Computing.)
Those named differences are what make cloud economics its own topic rather than just “renting instead of buying.” The source’s own economics-of-scaling framework grounds that argument in two matched lists – what drives the benefit, and what the benefit actually is:
Number of Unique Customer Sets
Duty Cycles of Customer Set
Relative Displacement Duty Cycle
Load of Customer Set
(Kevin L. Jackson, “The Economic Benefit of Cloud Computing,” Forbes, 2011.) Those four customer-population metrics are what a provider’s economies of scale actually run on – more unique customers, with different duty cycles, different relative timing, and different load profiles, is what lets shared infrastructure stay highly utilized instead of sitting idle waiting for any one customer’s peak. The same source names six concrete incentives that follow from that scale:
Lower Cost
Cap-Ex Free Computing
Deploy Projects Faster; Foster Innovation
Scale as Needed
Lower Maintenance Costs
Resiliency and Redundancy
5.4 Under the Hood: Managing Data in the Cloud and Database-as-a-Service
Every economic argument above assumes the underlying workload can actually run well on shared, provider-managed infrastructure. For a database specifically, that is not automatic – evaluating a cloud database manager starts with three steps: define the type of application that will be served (the source’s own examples are data-asset protection, business intelligence, and e-commerce); determine how suitable those applications are for public or private clouds; and identify the factors that affect an easy development process.
Once an application type is defined, a cloud database-management system has to meet five named demands (D. Abadi, “Data management in the cloud: Limitations and opportunities,” IEEE Data Eng. Bull., 32(1):3-12, 2009):
Efficiency
Fault-Tolerance
Adaptive to Heterogeneity
Operational Comfort on Encrypted Data
Capable of Interfacing with Other Products/Solutions
Database-as-a-Service (DBaaS) is the productized answer to those five demands – a managed database offering rented the same way compute or storage is rented under IaaS. The source names five examples: Microsoft Azure SQL Database; Amazon Web Services’ DynamoDB and Relational Database Service; Google Cloud SQL and Google App Engine Datastore; ClearDB; and Database.com.
This list dates fast – verify before relying on it. The named DBaaS products above are what the source material names, current as of its own recording; they are not verified as this module’s current, up-to-date catalog. ClearDB, once a widely used MySQL-as-a-service option on this exact list, has since been discontinued – the clearest illustration in this chapter that a DBaaS product name is a snapshot in time, not a standing fact. Treat this list as “what a cloud DBMS landscape looks like,” not as “the current options,” and check each provider’s own current service catalog before using any of these names in a real decision.
5.5 Summary
Service management is the operational layer underneath every architecture choice earlier in this module: it aims for optimal performance in on-demand environments, framed by nine named IBM objectives and made concrete by the SLA’s quality/utility/warranty structure, where the covered areas (volume and quality of work, speed, efficiency) stay fixed even as exact metrics vary by provider. Turning that promise into an invoice runs through accounting (recording metered usage) then billing (combining those records with resource prices and billing rules). Cloud economics beats traditional, owned infrastructure on named dimensions – resilience, scalability, automation, running costs, security – and the economics-of-scaling framework ties four customer-population metrics to six concrete cost incentives. Underneath the data layer specifically, a cloud DBMS has to meet five named demands, and Database-as-a-Service is the productized answer to them – with a named-product list that, as ClearDB’s discontinuation shows, needs checking against current offerings rather than being treated as fixed.
5.6 Key Takeaway
An SLA’s covered areas are stable even when its numbers are not, and a DBaaS product list is a snapshot, not a standing fact. Before trusting either one, separate what the source material states as a structural rule (areas an SLA must cover, demands a cloud DBMS must meet) from what it states as a point-in-time example (a specific metric, a specific named product) – and re-verify only the second kind.
5.7 See Also
Deployment Models and Virtualization
The previous chapter in this module: once a deployment model and virtualization approach are chosen, this chapter covers how the resulting service gets managed, billed, and paid for.
Service Models: IaaS, PaaS, and SaaS
Who manages which layer of the stack – the responsibility bracket that the SLA and billing pipeline in this chapter ultimately hold each side accountable against.
Production Cloud Deployment for IoT
The applied companion chapter: turns cost and retention economics into a production launch record with quotas, back-pressure, and rollout safety.