Skip to content

Latest commit

 

History

History
98 lines (71 loc) · 3.61 KB

SLA-Spec-Presentation.md

File metadata and controls

98 lines (71 loc) · 3.61 KB
Raw

Service Level Agreement Spec for APIs

OpenAPI SIG

Abstract

API consumers expect Service Level Agreements (SLAs) for production APIs which specify their capabilities such as rate limits, performance, quality and so on. However, currently the OpenAPI Spec (OAS) does not provide a method to capture SLA requirements within the specification.

The SLA for OpenAPI Special Interest Group has been working on a Spec for SLA definitions, that works hand in hand with OAS. In this talk, we will present the current state of the Spec, as well as the main use cases and benefits it enables: ranging from SLA documentation, automatic SLA enforcement, automatic middleware configuration, to SLA verification.

We will demonstrate how to generate OpenAPI with SLAs from their corresponding Service Level Objectives (SLOs) and how to make use of it in conjunction with your CI/CD pipeline and finally demonstrate measurement to performance and quality SLAs & SLOs with tooling against production APIs.

Finally, we'll then discuss how you can help improve and extend the spec by contributing to discussions and tooling.

SLA Spec

  • DSL for defining a set of metrics and constraints regarding service availability, quality of the service like minimal and maximal throughput, latency, quotas, rate-limits, pricing plans
  • Declarative YAML document
  • Meant to be used alongside OpenAPI, which can't (and should not) describe runtime aspects

75%

Why now?

  • API & Services Proliferation!
  • Hard to keep track of configuration in each deployment, each environment
  • Hard to replicate and review configurations
  • Need a precise way to specify runtime behavior, one that can be checked in, diffed and used for testing, repeatably
  • Avoid misconfiguration, which leaves your service open to Security and Availability problems

How to use it

  1. Start with a document specifying what you need
  2. Review with your team for correctness
  3. Document becomes part of deployment
  4. Validate using automation
  5. Use as basis for next iteration so you can have a precise record of each state

How it benefits API Consumers

  • Accurate SLA/Plans Documentation, know what to expect
  • Clients can understand better how to use a Service
  • Automatically adjust its consumption (e.g. throttling)
  • 3d party assurance for stated availability

How it benefits DevOps

  • Service/Gateway Configuration
  • SLA/Plans Testing, Validation, Compliance
  • Helps review and rollback configuration changes

How it benefits Business

  • Enforces limits
  • Accountability and Precision around plans & monetization
  • Easier to evolve monetization and plans

How it benefits Toolmakers

  • Provide more value in your products
  • Render customized documentation for each environment
  • Users can use and deploy more gateways since it's easier to configure and control them

Where to go from here

  • Contribute!
    • Need to improve for reuse & Overlays
  • Implement!
    • Gateway plugins: Kong, Tyk, Ambassador
    • Documentation: Readme, SwaggerUI, Stoplight Elements, Optic
    • Testing & Monitoring: Postman, SoapUI, Moesif, APIMetrics
    • Test Generation, Mocking: Prism, ServiceV, WireMock, Mockintosh

Summary

  • Declare SLA quotas, limits, plans
  • Service/Gateway Configuration
  • SLA/Plans Documentation
  • SLA/Plans Testing, Validation, Compliance

Info