As APIs are becoming popular to build Service-Based Ap-
plications (SBA), API Gateways are being increasingly used to facilitate
API features management. They o er API management functionalities
such as pricing plans support, user authentication, API versioning or
response caching. Some parts of the information that an API Gateway
needs are already included into a Service Level Agreement (SLA), that
providers use to describe the rights and the obligations of involved par-
ties in the service. Unfortunately, current API Gateways do not use any
SLA representation model nor SLA underlying technology, thereby miss-
ing potential opportunities. In this paper we analyze the state of the art
to justify the current situation and we identify some research challenges
so as to achieve SLA-Driven API Gateways.European CommissionSpanish and the Andalusian R&D&I programs TIN201232273Spanish and the Andalusian R&D&I programs TIC5906Spanish and the Andalusian R&D&I programs P12TIC-1867Spanish and the Andalusian R&D&I programs TIN2014-53986-RED

Fernández Montes, Pablo

Gámez Díaz, Antonio

Ruiz Cortés, Antonio

idUS. Depósito de Investigación Universidad de Sevilla

Towards SLA-Driven API GatewaysAntonio Ga´mez-Dı´az, Pablo Ferna´ndez-Montes, and Antonio Ruiz-Corte´sUniversity of Sevilla ?{agamez2,pablofm,aruiz}@us.esAbstract. As APIs are becoming popular to build Service-Based Ap-plications (SBA), API Gateways are being increasingly used to facilitateAPI features management. They offer API management functionalitiessuch as pricing plans support, user authentication, API versioning orresponse caching. Some parts of the information that an API Gatewayneeds are already included into a Service Level Agreement (SLA), thatproviders use to describe the rights and the obligations of involved par-ties in the service. Unfortunately, current API Gateways do not use anySLA representation model nor SLA underlying technology, thereby miss-ing potential opportunities. In this paper we analyze the state of the artto justify the current situation and we identify some research challengesso as to achieve SLA-Driven API Gateways.1 IntroductionAs software architecture is shifting form a product paradigm to a service paradigm(i.e. software as a service (SaaS)), the traditional models, where users buy aperpetual-use license (e.g. Microsoft Office) are moving to service-oriented mod-els, where users have to buy a subscription from the service provider (e.g. Zoho).Moreover, in the current Service-Oriented Computing paradigm, Service-BasedApplications (SBA) are becoming increasingly important, especially nowadayswith the popularization of cloud platforms.Furthermore, we can find a large API marketplace where providers get paidfor their clients API usage. In this context, most APIs have different pricingplans in order to fit with the customer’s needs and they have to determinatethe proper service level for each plan. These decisions need to be managed andaligned with business goals.Traditional service-oriented industries define contractual documents knownas Software Level Agreement (SLA) which stipulates and commits the providerto a required level of service according their business model. We can extendSLA model to APIs providers so that we get SLA managed services where bothcustomer and provider agree certain service properties, such as service levelobjectives, service features, up-time guarantees or number of requests.? This work has been partially supported by the European Commission (FEDER),the Spanish and the Andalusian R&D&I programs (grants TIN201232273 (TAPAS),TIC5906 (THEOS) and P12TIC-1867 (COPAS)) and TIN2014-53986-REDT.Since most API Gateways do not have any associated SLA, the businessmodel is coupled with the API Gateway logic, thus there exists a rigid andcomplex evolution, giving as a result a code difficult to maintain. Therefore,generated solutions will not be generic, scalable nor domain-independent ones.On the contrary, by having an implicit SLA, open, scalable, flexible and domain-independent solutions can be built.When API providers try to align technology with their business goals theycan use an API Gateway solution, i.e. a third-party solution that try to resolvesome API management common tasks such as user authentication, establishing acertain request limit per user or blocking resources depending upon the user whocalled the API. This solution is uncoupled from the API code. Nevertheless, theservice provider depends on a certain third-party gateway, which offers limitedfeatures that may not fit with the business needs.In this work we analyze APIs and API Gateways to identify requirementsfor a future framework that supports SLA-driven API Gateways solutions. Weanalyze a few APIs and study what they have in common. Next, we focus onsome API Gateway solutions existing in the market and we detail what theyreally offer. Finally, with this information, we could establish research goals sothat we continue working on this line. Figure 1 shows a context diagram thatrepresents the relationships between the elements we describe on the paper.Fig. 1. Context diagram.This paper is organized as follows: Section 2 describes the current situationof APIs by giving examples of real ones and analyzing its features. In Section3, we study a few examples of API gateways focus on its relationship withSLA management. Next, in Section 4 we try to identify new research challengesthat can be used as requirements for a further design and development. Finally,Section 5 shows some remarks and conclusions.2 Pricing plans in APIsIn this section we show the relationship between the properties that API providersare used to monitor and we analyze some real world APIs in order to highlightdifferent pricing plans.A Service Level Agreement (SLA) can be seen as containers of the functionaland non-functional properties that both parties (the service consumer and theservice provider) agree specifying its rights and obligations during the interac-tion. SLAs are widely used in the industry in situations where consumers andproviders need or desire to explicitly express certain guarantees over the servicetransaction. There exists several purposes to describe SLAs, for instance, WS-Agreement [1], purposed by Open Grid Forum. It is one of the firsts specificationwhich counts with well-defined validity criteria [3] and an environment to edit,validate and monitor SLAs1 [6].In connection with SLAs, APIs often monitor properties for each user oreach request (e.g. the number of requests, the called endpoint, user authenti-cation data, etc.). According to these properties and their own business model,providers can design pricing plans and get paid for their service usage. An impor-tant challenge for API service providers is managing different plans with theircustomers while satisfying their business objectives. These monitorable proper-ties could be introduced into the existent SLA between the consumer and theprovider. For this reason, it is possible to establish a relationship among SLAsand pricing plans.In order to illustrate the variability of existing API pricing plans we showand detail a real example in Figure 2.In Figure 2 we show the pricing plan of Semantic3 company, whose APIprovides access to a database of normalized e-commerce products, UPC, andpricing data. There exists 4 different plans which are primarily based upon dailyrequests amount. It also offers diverse features and support level for each plan.For instance, in free plan we are not able to access the full API data nor indexingcustom domains. Definitely, most APIs have to control user requests and thefeatures they offer to each client.API pricing plans range from completely free to paid plans. In this context,in order to capture the variability in the different scenarios we have studied 9different APIs.– Freemium (P1), when there exists a limited basic plan and users can over-take the limits depending on they pay for the service, e.g. AlchemyAPI hasfree plan of 1 thousand transactions per day but subsequent ones are paid.– Tiered (P2), when each tier has its own set of services and allowances foraccess to API resources and it is fixed a prize for each tier, e.g. Semantics3has 3 different paid plans.– Unit-based (P3), when pricing is based upon a pre-defined unit of mea-surement, such as API calls or the storage used on disk, e.g. GroupDocsestablishes a base price and $0.15 is billed for each extra operation.1 This environment is deployed at isa.us.es/IDEAS.Fig. 2. Semantics3 Pricing Plan.– Pay-as-you-go (P4), when a customer accumulates a monthly bill basingon what is its use of API resources, e.g Stupeflix defines a cost per each APIresource (such as $0.01 per minute of input video), thus the bill depends uponthe user usage.– Enterprise pricing (P5), when pricing is part of a larger sales process, it isa common way for large companies to price products and services based uponcustomer’s needs, e.g. in AlchemyAPI, clients with over 1 billion requests permonth are eligible for a custom plan.– Volume pricing (P6), when pricing is based upon volume purchases bybuying in bulk, e.g. MailGun defines an initial price of $0.00050 for first500,000 sent emails and $0.00035 for the next 1,000,000.We study some selected APIs in terms of their pricing plan they offer andadditional features. In Figure 3 we illustrate that comparison2, where a cell Cijmarked with an x means that API i supports the property j. Note there is notany property that could be considered as a particular case from another. Next,we detail an example extracted from the same table.A large part of studied APIs have a unit-based (P3) plan, probably due toit is easy to implement and is enough for many API providers. As an example,AlchemyAPI has two different pricing plans. On the one hand, it has 3 plansonly based on the daily request volume (between 90.000 and 3 million) and a2 The reference of all studied APIs can be found at: goo.gl/0n8cPrFig. 3. APIs comparative.free tier of 1000 requests is also available. On the other hand, we could select apay-as-you-use plan so that we would be billed only for the requests made.It is important to separate how the total cost is calculated from how theclient is billed. For instance, Algorithmia has a credit-based plan, where it isnecessary to add funds to one’s account to be able to continue making APIrequests. Nevertheless, it is only a particular case of a unit-based plan.As another example of unit-based plan, FlightStats has a plan based uponthe requests you made, although it distinguishes according to the resource typeyou call in the request (e.g. is more expensive to serve a request that impliesmore CPU or memory consumption). Groupdocs, whose pricing plan is not basedupon the requests amount but a pre-defined unit of measurement based their ownbusiness logic.3 Pricing plans in API GatewaysIn this section we discuss about the concept of API gateways (other authorsalready use this term: [10], [2]) and study how they could be related with pricingplans and SLA-Driven APIs by analyzing what they really offer.An API gateway offers API management features, such as security (e.g. ac-cess control, DoS attacks blocking), pricing plans support, API analytics, requestmonitoring, API lifecycle control (e.g. service orchestration, govern data flows,API design support) or response transformation (e.g. JSON to SOAP). Fur-thermore, API Gateways are usually implemented as virtual appliances, virtualmachine images, SaaS or reverse proxies.From the 13 API Gateways studied we have selected 13 criteria in order tocompare all of them. In Figure 4 we illustrate that comparison3, where a cellCij marked with an x means that platform i has the property j, and we providesome examples extracted from the same table.– Security:• Basic Authentication (Q1): it supports basic authorization methods,e.g. Mashape let us configure authentication by a HTTP header, a queryparameter and an API key.• Advanced Authentication (Q2): it supports advanced authorizationmethods, e.g. Apigee offers OAuth and LDAP authentications.• Attacks protection (Q3): it includes a way to protect itself from at-tacks, e.g. CA prevents our API from DoS attacks.– Pricing plans support:• Free Tier (Q4): it has a free plan with basic features or limited bysomehow, e.g. 3Scale offers a basic tier with 50 thousand calls per dayfor free.• Requests limit (Q5): there exists a way to establish quotas per user,e.g. with Azure it is possible to limit API calls by user to a custom value.• Enterprise Plans (Q6): it offers customized plans for enterprise clients,e.g. 3Scale let enterprise clients configure unlimited APIs with a guaran-teed availability.– Lifecycle control:• API versions (Q7): it supports versioning e.g. Axway let us set differentversions from the same API.• Orchestration (Q8): there exists a way to orchestrate RESTful servicesin terms of SOA governance, e.g. Akana let us control complete APIlifecycle and orchestrate all services involved.– Other features:• OpenSource (Q9): the code is available to anyone (e.g. WSO2 and APIUmbrella are both Open Source solutions).• Load balancing (Q10): it makes possible to do load balancing betweenvarious API servers, e.g. API Umbrella balance the requests between ourbackend.• Cache (Q11): it includes request caching in order to reduce the effectiveAPI calls amount, e.g. Apigee save the API responses in order to servethe same data if there is no changes.• Response conversion (Q12): it gives the possibility of converting APIresponse into another language, e.g. Akana perform a JSON to SOAPconversion.• Documentation (Q13): it generates a developer portal with API doc-umentation, e.g. Mashape generate an interactive documentation and aplayground where developers can make requests.3 The reference of all studied API Gateways can also be found at: goo.gl/0n8cPrFig. 4. API Gateways comparative.3Scale is an API gateway service provider who let us connect up to 3 differentAPIs with a daily traffic close to one million requests. It is possible to establishrequests filtering policies based upon trusted API keys, black and whitelistingor OAuth authentication. In order to create billing plans, we could limit therequests amount per user and create a billing for that use or simply a billingplan based upon the requests that a user has made; it is also possible to createtrial plans. Besides these core features, it also offers several statistics, a developerportal, documentation generation and different ways to deploy the reverse proxytowards 3Scale.Almost all API gateway studied services offer the same core functionality:request authorization and quota establishment so that various billing plans couldbe created. It might be enough for few APIs that do not need a more complexbusiness billing logic, but does not allow to introduce all business logic we mayneed.4 Research ChallengesWe propose API Gateways based on SLAs. We have analyzed API propertiesand billing needs and how third-party API Gateways solutions could be useful tosolve this problem. Nevertheless, there are some API requirements that are notsatisfied by the previous solution, so the only possibility is to code it manuallyinto the API code. This implies an increasing error probability and an API codecoupled itself with management one. Previously we have shown the importanceof considering SLAs in our design, therefore we focus on a SLA-Driven solution.In this section we analyze these requirements and we try to identify other onesthat could appear in a different scenario. Finally, we propose several researchchallenges in order to establish a road-map to focus our researches on.We can identity new requirements that could be met by a theoretical APIthat use a SLA based pricing plan.– Challenge 1: supporting temporarily in pricing plans. As current API gate-ways are static, if an API pricing plan depends on the moment that the APIis called, it would be necessary to code this logic manually. It is possibleto find more examples, such as support plan life-time (i.e. when it startsand expires) or time periods for guarantee terms (e.g. availability level isguaranteed only during Monday-Friday working hours). In this way, we havedynamics and elastic pricing plans, regulated according to demand cycles.In [7], [9] and [8] authors analyze formal temporarily in SLAs.– Challenge 2: adding a more fine-grained configuration by supporting otherfeatures and metrics than the requests amount. An API could define custommetrics that represent the cost for the business. For instance, metrics suchas CPU time consumption, memory or storage usage.– Challenge 3: adding support to compensations (penalties and rewards)according to the under-fulfillment or over-fulfillment of SLA service levelobjectives (SLO). For instance, API provider could be committed to serverequests in an established time; if there is a percentage of these requestserved out of time, provider should compensate client by certain way (e.g.claiming a refund). In [5] and [4] authors show the formal specification of aSLA with compensations.5 ConclusionsIn this paper we have shown an analysis of the state of art in API and APIGateway paradigm and propose a SLA-Driven solution in an API Gateway de-sign. The API and SaaS management is a difficult task and there is no solutionyet that help providers to automatize simple things like pricing management,feature limitation, billing based upon custom parameters, etc. Currently, serviceproviders have to code this logic by hand or they ought to resort to third-partyplatforms, which involves an extra cost. We try to define the main researchlines so that we could continue working on and, in the future, we could give aframework that permits APIs to be managed by Service Level Agreements.References1. Alain Andrieux, Karl Czajkowski, Asit Dan, Kate Keahey, Heiko Ludwig,Toshiyuki Nakata, Jim Pruyne, John Rofrano, Steve Tuecke, and Ming Xu. WebServices Agreement Specification (WS-Agreement). 2007.2. Mingyu Li, Qian Zhang, Hanyue Chu, Xiaohui Hu, and Fanjiang Xu. Conha: Ansoa-based api gateway for consolidating heterogeneous ha clusters. In 2013 IEEEInternational Conference on Cluster Computing (CLUSTER), pages 1–3. IEEE, 92013.3. Carlos Muller. On the Automated Analysis of WS-Agreement Documents. PhDthesis, 2013.4. Carlos Muller, Antonio Manuel Gutierrez, Octavio Martin-Diaz, Manuel Resinas,Pablo Fernandez, and Antonio Ruiz-Cortes. Towards a formal specification of slaswith compensations. In On the Move to Meaningful Internet Systems: OTM 2014Conferences, volume 8841 of Lecture Notes in Computer Science. Springer BerlinHeidelberg, 2014.5. Carlos Muller, Antonio Manuel Gutierrez, Manuel Resinas, Pablo Fernandez, andAntonio Ruiz-Cortes. Towards compensable slas. In 4th International Workshopon Adaptive Services for the Future Internet (WAS4FI in ESOCC14), 2014.6. Carlos Muller, Antonio Manuel Gutierrez, Manuel Resinas, Pablo Fernandez, An-tonio Ruiz-Cortes, Antonio Manuel Gutierrez, and Manuel Resinas. iagree studio:A platform to edit and validate ws-agreement documents. In 11th Intl. Conf. onService Oriented Computing (ICSOC), volume 8274 LNCS, pages 696–699, 2013.7. Carlos Muller, Octavio Martin-Diaz, Manuel Resinas, Pablo Fernandez, and Anto-nio Ruiz-Cortes. A ws-agreement extension for specifying temporal properties inslas. In III Jornadas Cient´ıico-Te´cnicas en Servicios Web y SOA, pages 77–84, 92007.8. Carlos Muller, Octavio Martin-Diaz, Antonio Ruiz-Cortes, Manuel Resinas, andPablo Fernandez. Improving temporal-awareness of ws-agreement. In 5th. Intl.Conf. on Service Oriented Computing (ICSOC), volume 4749 of LNCS, pages 193–206. Springer Verlag, 9 2007.9. Carlos Muller, Antonio Ruiz-Cortes, and Pablo Fernandez. Temporal-awarenessin slas. why should we be concerned? In Service-Oriented Computing - ICSOC2007 Workshops: 1st. Non-Functional Properties and Service Level Agreements inService Oriented Computing Workshop (NFPSLA), volume 4907 of LNCS, pages166–173. Springer Verlag, 9 2007.10. Qian Zhang, Hanyue Chu, Mingyu Li, and Xiaohui Hu. A unified api gatewayfor high availability clusters. In Proceedings 2013 International Conference onMechatronic Sciences, Electric Engineering and Computer (MEC), pages 2321–2325. IEEE, 12 2013.

Towards SLA-Driven API Gateways

https://idus.us.es/xmlui/bitstream/handle/11441/32160/sla-driven-api.pdf?sequence=1&isAllowed=y

Towards SLA-Driven API Gateways

Abstract

Similar works

Full text

Available Versions

idUS. Depósito de Investigación Universidad de Sevilla