Email
Like
Liked ×
Save
Private Content
Embed
Loading embed code…
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.
Loading

+ Follow

Huge: Running an API at Scale

by Apigee on Jan 26, 2012

7,085 views

Accessibility

View text version

Upload Details

Uploaded via SlideShare as Microsoft PowerPoint

Usage Rights

File a copyright complaint

10 Embeds 5,728

http://blog.apigee.com	5565
http://blog.sonoasystems.com	93
http://apigee.com	36
http://feeds.apigee.com	13
http://blog.edit.apigee.net	7
http://webcache.googleusercontent.com	5
http://mktg-dev.wearepropeople.md	3
http://www.newsblur.com	3
http://translate.googleusercontent.com	2
http://ip54.216-86-157.static.steadfast.net	1

More...

Statistics

Likes: 6
Downloads: 49
Comments: 1
Embed Views: 5,728
Views on SlideShare: 1,357
Total Views: 7,085

1–1 of 1 previous next

Apigee at Apigee
1 year ago
Are you sure you want to

Creative Commons Attribution-Share Alike 3.0 United States License
== ED ==at 6 apart when opening the API: New UI Paradigm - continuous scrolling vs the page load paradigm. 1 to 2 orders of magnitude more content. * you wouldn't have predicted it - new reader application launched on TechCrunch
There is a big difference between running a prototype and running a big API product.
In the world of web products there’s variation in browsers. And they can be super wonky. But nowadays those variations are known and predictable.We control everything else. And importantly we control all the code that calls our servers.SAM: trivial complexity because it’s homogenous. There’s variety but the complexity is trivial. You can rely on :BroadbandPC CPUs
In the API world we control much less. The variation is much greater. And we can predict very little.Importantly, we don’t control any of the code that hits our servers.
CC photoshttp://www.flickr.com/photos/peopleforcherry/3427058289/ http://www.flickr.com/photos/ifmuth/606128545/If running a big web product is like running a big building then running an API is like running a city. Building/Web: linear, rational, predictable. It’s about the technology.City/API: non linear, irrational, unpredictable, its about the people.SAM: Chaos is another way of thinking about complexityFirst responsersJitters in the systemDifferent patterns of behaviourHard to predict
What drives complexity?
Sam
The first driver is going from direct to indirect
This is like the role of mayor.Track them: register developers and their appsMake sure they adhere to terms of useCut off violatorsPromote their applicationsKeep them happyCommunicate with themBring them usersSAM: as the API team your attitude has to be permeable. Allow the developers in your community to help you help them. Let’s the citizens be activists.
This is totally different than the web and very complex:track our usersTrack the relationships between the apps, developers and our usersThis isn’t just password resetThis is authorizing on behalf of the user which parts of their data that we store that the apps can use
What does this mean in terms of scaling up requests and responses?Between any two requests the user might revoke privileges from the appSo we must check every response against the wishes of our users. OAuth increases the number of API calls necessary to get a new client up and running on the API, although if your API is successful then that will average out to not too much. OAuth also means that you have a whole bunch of tokens to maintain -- one per end user, per device, per app -- for a big API that's easily millions. You need them to be available at all times, and in fact you need to be able to write to that database at all times, not just read from it, so that you can issue new tokens whenever new end users appear or whenever they get a new device. So that's a lot of tokens. We're finding that databases like Cassandra and Riak that are eventually consistent and let you write from anywhere are much more effective for this problem than databases that rely on master-slave replication.ED: you’ll be using muscles you’ve never had to use before.
You don’t
Bad developersDevelopers in a hurryOur API is not clear to themClient-side cachingiOS has restkit which uses Core Data to store data locallyAndroid has restlet for caching and some folks use squid on the client side as a reverse proxy
Your API docs might be unclearYou might not be offering guidance on best practicesAPI design might be terribleBut if we do the above correct there are still 2 key considerations:Publish SDK/Libraries or not?With an SDK you can package up your API usage best practices that developers will adoptBut it’s a lot more work: you are now in the software distribution business. At least follow the OSS model: githubetcThe big dog debate: resource-oriented API design or UI-oriented “shortcut” API designProbably do both: resource first as the baseline, then shortcuts as needed by UI
You have to version
Innovation happens on someone else’s schedule and not yours.
You don’t
You don’t
You don’t

6 Likes

Dave Budiman 5 months ago
Rafael Hofmann 6 months ago
iamsk7 Tags api apigee 9 months ago
rubystars Tags api 1 year ago
Kotaro Sugimoto, 代表取締役 at アウトロジック（OUTLOGIC） Tags api 1 year ago
fanbuildr Tags api development 1 year ago

Huge: Running an API at Scale Presentation Transcript

HUGE:Running an API at ScaleSam Ramji@sramjiBrian Pagano@brianpaganoEd Anuff@edanuff Apigee @apigee
groups.google.com/group/api-craft
youtube.com/apigee
“ People will do stuff with our API we never imagined. -VP of Marketing“ People will do stuff with our API we never imagined. -CTO
80 Now What?
“ The constructionist hypothesis breaks down when confronted with the twin difficulties of scale and complexity. -P.W. Anderson More is Different
Web Value Chain ControlWeb Web Web Web InternalUser Browsers Application Team Systems <HTML> <SCRIPT>
API Value Chain ControlApp App API Internal App APIUser Developer Team Systems
Running a huge web product and running a hugeAPI product are different endeavors.
“ Running a platform is like running a town. -Ryan Sarver Director Twitter API
Complexity
Cauchy Distribution
From Direct to Indirect IndirectApp App APIUser App Developer Team
Manage application developers & applications
Manage relationships between developers’ appsand our users.
OAuth App API token token token App API App User Team Developer
All applications are not created equal.
Chatty Applications – Application Developer’s POV App Developer App API
Chatty Applications – API Team’s POV API Team App API
More moving parts, but you can’t stand still.
Versioning App v1 API v1 App v2 API v2 App v3 API v3
Pro Tip: Do The Good Stuff• Test Driven Development• Continuous Integration• QA
Scale
Scale Doesn’t Happen When You Expect It
APIs Ask More of Internal Systems Internal API Systems
Ask Less of the API - Cache InternalApp Web Cach API Systems e
Ask Even Less of the API – Geo Distributed Cache Euro Web Cach App e InternalAmericas Web Cach Web API Systems App e Asia Web Cach App e
THANK YOUSubscribe to API webinars at:youtube.com/apigee
THANK YOUQuestions and ideas to:groups.google.com/group/api-craft
THANK YOUContact us at:@sramjisramji@apigee.com@brianpaganobpagano@apigee.com@edanuffed@apigee.com

Huge: Running an API at Scale

by Apigee on Jan 26, 2012

Accessibility

Categories

Upload Details

Usage Rights

10 Embeds 5,728

Statistics

Huge: Running an API at Scale Presentation Transcript