Huge: Running an API at Scale
•Als PPTX, PDF herunterladen•
10 gefällt mir•3,846 views
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Huge: Running an API at Scale
Ähnlich wie Huge: Running an API at Scale (20)
Mehr von Apigee | Google Cloud
Mehr von Apigee | Google Cloud (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Huge: Running an API at Scale
- 1. HUGE: Running an API at Scale Sam Ramji @sramji Brian Pagano @brianpagano Ed Anuff @edanuff Apigee @apigee
- 4. “ People will do stuff with our API we never imagined. -VP of Marketing “ People will do stuff with our API we never imagined. -CTO
- 5. 80 Now What?
- 6. “ The constructionist hypothesis breaks down when confronted with the twin difficulties of scale and complexity. -P.W. Anderson More is Different
- 7. Web Value Chain Control Web Web Web Web Internal User Browsers Application Team Systems <HTML> <SCRIPT>
- 8. API Value Chain Control App App API Internal App API User Developer Team Systems
- 9. Running a huge web product and running a huge API product are different endeavors.
- 10. “ Running a platform is like running a town. -Ryan Sarver Director Twitter API
- 11. Complexity
- 13. From Direct to Indirect Indirect App App API User App Developer Team
- 14. Manage application developers & applications
- 15. Manage relationships between developers’ apps and our users.
- 16. OAuth App API token token token App API App User Team Developer
- 17. All applications are not created equal.
- 18. Chatty Applications – Application Developer’s POV App Developer App API
- 19. Chatty Applications – API Team’s POV API Team App API
- 20. More moving parts, but you can’t stand still.
- 21. Versioning App v1 API v1 App v2 API v2 App v3 API v3
- 22. Pro Tip: Do The Good Stuff • Test Driven Development • Continuous Integration • QA
- 23. Scale
- 24. Scale Doesn’t Happen When You Expect It
- 25. APIs Ask More of Internal Systems Internal API Systems
- 26. Ask Less of the API - Cache Internal App Web Cach API Systems e
- 27. Ask Even Less of the API – Geo Distributed Cache Euro Web Cach App e Internal Americas Web Cach Web API Systems App e Asia Web Cach App e
- 28. THANK YOU Subscribe to API webinars at: youtube.com/apigee
- 29. THANK YOU Questions and ideas to: groups.google.com/group/api-craft
- 30. THANK YOU Contact us at: @sramji sramji@apigee.com @brianpagano bpagano@apigee.com @edanuff ed@apigee.com
Hinweis der Redaktion
- 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