Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
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
04.03.2010 Aalto University School of Science and Technology
2 / 27
OVERVIEW
● Technology Drivers● Business Theory Drivers● Web-service Background● API brokering / management in detail● 3 Company Cases
– StrikeIron– Mashery– 3 Scale
04.03.2010 Aalto University School of Science and Technology
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
04.03.2010 Aalto University School of Science and Technology
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
04.03.2010 Aalto University School of Science and Technology
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
04.03.2010 Aalto University School of Science and Technology
6 / 27
Business Drivers
04.03.2010 Aalto University School of Science and Technology
7 / 27
Open Innovation
Source:Henry William Chesbrough (2006) "Open Innovation: The New Imperative for Creating and Profiting from Technology"
04.03.2010 Aalto University School of Science and 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
04.03.2010 Aalto University School of Science and Technology
9 / 27
Google & Amazon Value Networks
Network Operators/ ISPs
End users
Developers
Data / ServiceProviders
Advertisers
Businesses
Tele Atlas
Network Operators/ ISPs
End users
Developers
Data / ServiceProviders
Amazon
Advertisers
AffiliatesVendors
Arto Kettula, 2009
04.03.2010 Aalto University School of Science and Technology
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
04.03.2010 Aalto University School of Science and Technology
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
04.03.2010 Aalto University School of Science and Technology
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
04.03.2010 Aalto University School of Science and Technology
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
04.03.2010 Aalto University School of Science and Technology
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
04.03.2010 Aalto University School of Science and Technology
15 / 27
API management
Twitter API receives easily ten times the traffic than the actual website – Twitter co-founder Biz Stone, 2007
04.03.2010 Aalto University School of Science and Technology
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
04.03.2010 Aalto University School of Science and Technology
17 / 27
Developer and Partner Community
● Content management system for API documentation
● Developer forums for providing support
● Application galleries
04.03.2010 Aalto University School of Science and Technology
18 / 27
Monitoring and Analytics
● Track account sign-ups● Monitor account usage● Track method usage in
calls● Track trends
04.03.2010 Aalto University School of Science and Technology
19 / 27
Billing and Payment
● Different usage plans per service
● Pricing rules to different metrics
● Receive payments
04.03.2010 Aalto University School of Science and Technology
20 / 27
API brokering
● One place for managingdifferent API accounts
● Creates marketplace opportunity for paid APIs
04.03.2010 Aalto University School of Science and Technology
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
04.03.2010 Aalto University School of Science and Technology
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
04.03.2010 Aalto University School of Science and Technology
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
04.03.2010 Aalto University School of Science and Technology
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
04.03.2010 Aalto University School of Science and Technology
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
04.03.2010 Aalto University School of Science and Technology
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
04.03.2010 Aalto University School of Science and Technology
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