Blue Lines and Gradients - TKK · Case 2: Mashery Mashery brand not visible to API users No market place or API charging functionality integrated User-id can be shared between different

04.03.2010 Aalto University School of Science and Technology

1 / 27

API brokering

Saku Seppälä

Aalto University School of Science and Technology

Department of Computer Science and Engineering


2 / 27

OVERVIEW

● Technology Drivers● Business Theory Drivers● Web-service Background● API brokering / management in detail● 3 Company Cases

– StrikeIron– Mashery– 3 Scale


3 / 27

Technology Drivers for Open Services

● In 80s and 90s thin-client adoption slow– Rapid PC performance growth– Low speed network connections– High cost servers

● Today server infrastructure getting cheaper– Multi-core / socket server

● Basic application requirements constant● Netbooks


4 / 27

Cloud Technology

● IaaS (Infrastructure as a Service)– Computers owned by the cloud provider– No hardware management issues– Dynamic scaling of resources through virtualization– Billing is calculated by usage only

● PaaS (Platform as a Service)– No system administration– Simplified development– Scaling is provided by the PaaS framework

● SaaS (Software as a Service)– Ready to deploy application

Simplicity

Evolution


5 / 27

Inexpensive Cloud Infrastructure - Google

● No special servers from Sun / IBM etc.

● Build everything self● Standard components

– CPU price/performance– Batteries on motherboards– Custom Linux OS.

● 1160 servers in 1AAA shipping container

● Google File System● Bigtable

© Stephen Shankland/CNET 2009


6 / 27

Business Drivers


7 / 27

Open Innovation

Source:Henry William Chesbrough (2006) "Open Innovation: The New Imperative for Creating and Profiting from Technology"


8 / 27

Internet Service Evolution

websitee-commerce

e-businessvalue networks

openecosystems

-Order and pay online

-Reduction of transaction costs

-Maximize accessibility to new markets

-Visibility in the global market

-Diffusion and gathering of information

-Supply chain integration

-Economy in the value chain integration

-Reduction of cost exercise

-Portals

- New business models based on organizations internetworking

-Virtual enterprises

-Web 2.0 mashups

-Example amazon.comgoogle.com

-Dynamic aggregation of modular service platform

- Enduserdrivenselection and evolution among services

Extent of organizational change and IT exploitation

Businessbenefits

Adapted from Nachira, F. et. al. (2002)

PAST PRESENT FUTURE


9 / 27

Google & Amazon Value Networks

Network Operators/ ISPs

End users

Developers

Data / ServiceProviders

Google

Advertisers

Businesses

Tele Atlas

Network Operators/ ISPs

End users

Developers

Data / ServiceProviders

Amazon

Advertisers

AffiliatesVendors

Arto Kettula, 2009


10 / 27

Ecosystems

dynamic structure which consists of interconnected population of organizations.

unclear borders ..

is self-sustaining ..

develops through self-organization, emergence, co-evolution ..

contains competition and cooperation simultaneously

combined knowledge and capabilities

Characteristics of business ecosystem.Mirva Peltoniemi (2005)

Dynamics

Coupled withchanging

environment

Businessecosystem

Large numberof participants

Interconnectedness

Interaction

Competition and cooperation

Shared fate

Conscious choice

Aims at innovationsand commercial

success


11 / 27

Ecosystems vs Value Networks

Value network Business ecosystem

Structure Organized by one actor,reasonably static

Self-organizing, dynamic

Competition and cooperation

Cooperation Both simultaneously

Role of end users Passive Active role in selecting services and thus actors in the ecosystem

Knowledge Sharing limited to operational information

Openness of the technology platform as the motivator of cooperation

Control One powerful actor Decentralized decision making

Entry barriers High Low


12 / 27

Market Uncertainty / Experimentation - Gaynor

25 20 15 10 05 00-05-10-15-20-25

Var=1 Var=5 Var=10

Best experiment

Link of market uncertainty to value of experimentationNetwork Service Investment Guide, Gaynor 2003

Exp

erim

ent v

alue

Experiment number


13 / 27

Web-service history

● RPC● CORBA● Web-services

– SOAP, WSDL– UDDI (web-service broker)

● White, yellow, green pages● REST (select → get, insert → post, update

→ post, delete → delete)

Simplic ity


14 / 27

UDDI business registries

● Web service brokering from IBM, SAP, Microsoft● Research & vision on automatic service composition● Immature environment, few interesting services,

garbage collection, difficult● 2001-2006● Now as documentation

and registry for internalcompany services


15 / 27

API management

Twitter API receives easily ten times the traffic than the actual website – Twitter co-founder Biz Stone, 2007


16 / 27

API management

● Key management & access control ● Usage limit setting (key, user, call,

group) and monitoring ● Contract management with

partners and customers ● Customer metrics and tracking ● API traffic filtering and caching


17 / 27

Developer and Partner Community

● Content management system for API documentation

● Developer forums for providing support

● Application galleries


18 / 27

Monitoring and Analytics

● Track account sign-ups● Monitor account usage● Track method usage in

calls● Track trends


19 / 27

Billing and Payment

● Different usage plans per service

● Pricing rules to different metrics

● Receive payments


20 / 27

API brokering

● One place for managingdifferent API accounts

● Creates marketplace opportunity for paid APIs


21 / 27

Case 1: StrikeIron

● First API management / brokering service (2005)● Focus on providing services for SalesForce.com

business application platform Address and credit verification.

● Tight integration with the StrikeIron brand● API / web-service marketplace● Revenue model: a percentage from income● Growth of the marketplace has stalled


22 / 27

Case 1: StrikeIron

● Built on private cloudtechnology

● Functions as proxy betweenthe client and the API

● Requires no change inoriginal API coding

Client

API Provider

Access controlLoggingQuota controlLoad balancing

StrikeIronDevelopersupportportalandManagement interface

ProxyMngt / Developerportal

Sign-upget API-keysupport

Grant API-keysMonitorManage quotas

Map and forward call torealserv.example.com/realserv

Callws.strikeiron.com/service

API Manager


23 / 27

Case 2: Mashery

● Mashery brand not visible to API users● No market place or API charging functionality

integrated● User-id can be shared between different API providers● Customers: Alcatel-Lucent (Open API Service), Netflix,

LinkedIn, The Guardian, Best Buy, Shopping.com, New York Times, CNET

● Revenue model: monthly fee, based on usage and subscription plan


24 / 27

Case 2: Mashery

● Built on Amazon cloudservice

● Functions as a proxy● Requires no change in

original API coding

Client

API Provider

Access controlLoggingQuota controlLoad balancing

MasheryDevelopersupportportalandManagement interface

ProxyMngt / Developerportal

Sign-upget API-keysupport

Grant API-keysMonitorManage quotas

Map and forward call torealserv.example.com/realserv

Callapi.example.com/service

API Manager


25 / 27

Case 3: 3 Scale

● Founded 2007 and service started 2009● Offers marketplace functionality● Offers billing for API access● Revenue model: monthly fee or percentage of billing ● Otherwise similar as Mashery, but different technical

infrastructure● Smaller clients than Mashery →

use requires programming to use


26 / 27

Case 3: 3 Scale

● Built on Amazon cloud● API has to be programmed to use

special libraries that handle API management.

● PROS: Lower cost for 3Scalesince less traffic

● CONS: Integration means codingand Lock-in for customers as changing provider is difficult

Client

API Provider

3Scale plugin

Logging servers

Direct APIcalls

Access controlLoggingQuota control

API ManagerGrant API-keysMonitorManage quotasBilling

3Scale platform

Developer / managementportal

Sign-upAPI-key accesssupportpayments


27 / 27

Conclusions

● Cloud computing lowers server application development costs

● Business trends as Open Innovation and Ecosystems drive interaction between services

● API management services facilitate interaction in open systems

● In future API management services can turn to brokering services enabling web-service marketplaces

Documents

Blue Lines and Gradients - TKK · Case 2: Mashery Mashery brand not visible to API users No market place or API charging functionality integrated User-id can be shared between different