Talk from the API Management Meeting, San Francisco, 9/11/2013. Covering how APIs change the way be build applications. Also covers why the API Economy will be a complex distributed system.

1. How APIs are changing
Application Development
Steven Willmott
3scale Inc
@3scale - http://www.3scale.net

2. On Demand API Infrastructure:
http://3scale.net @3scale
me: @njyx on twitter
Powering 250 APIs
Billions API Calls / Month

3. San Francisco 23-25th October
http://www.apistrategyconference.com

4. To the Content…

5. “Software is Eating the
World”
Marc Andreessen – WSJ / August 2011

6. “APIs are Eating Software”
API Days San Francisco 2013

7. Almost every major industry is
becoming software driven
MusicRetail Video Telephony
Meaning:
…

8. Examples
Lytro: “Software Defined
Cameras”
Philips Hue: “Software Controlled
Lighting”
Amazon: “Software Driven
Retail”
Pixar: “Software powered
animation”

9. APIs are Eating Software

10. Meaning:
1
2
APIs are the key glue that make this
software remotely addressable
APIs provide a myriad of new external
building blocks to speed up and enrich
software development
3
If you do these things together special
things happen

11. Outside-In
More and More APIs are Proliferating

12. APIs Make Software
Remotely Addressable

13. Wide Diversity of APIs out there
London Transport: Open Data
Evernote: “Platformization”
Netflix: “Massive Distribution”
JCI: “Software Controlled
Buildings”
Thousands
Of Devices

14. Software multiplies in value
many fold if you can talk to it

15. But, What about “Inside-Out”?
How are APIs Changing Application
Development?

16. APIs are the new Libs
“In computer science, a library is a collection
of implementations of behavior, written in
terms of a language, that has a well-defined
interface by which the behavior is invoked”
Credit: Wikipedia

17. Download & Add to
Classpath
Became
Find and Integrate

18. Speed (Time to Market)
e.g. + Devops Borat
e.g.
(Top Mashup on
Progr Web)

19. Richness / Functionality
e.g.
e.g.

20. Offboarding
e.g.
e.g.
(Rich Photo Effects
For Mobile by SDK)
(Monitoring System
in the Cloud)

21. Reliability
e.g.
e.g.
(Email by API)
(Amazon S3)

22. The Sum of the Two
Makes Interesting Things Happen

23. Software Development over Time
Software Before 1995 Software 1995 – 2010 Software 2010 -

24. Enables specialization, focus, much
wider distribution

25. APIs enable
componentization across
organizational boundaries

26. I: New Type of Software
Development

27. Software as Model-View-Controller
VIEW = FORM
MODEL = DATA
CONTROLLER = BUSINESS LOGIC
Model
View Controller

28. Now it can done at the
company / organization level

29. Example “Models”
Model
Data Anywhere in
any form
(copyrights / respective owners)

30. Example: Views
View
Many Delivery
Channels
(copyrights / respective owners)

31. Example: Controllers
Controller
Many Delivery
Channels
(copyrights / respective owners)

32. APIs Enable Separation & Focus
Model View Controller
Data Anywhere in
any form
Many Delivery
Channels
Third parties
operating on data
Distributed Applications

33. Software + APIs allow
Businesses to co-evolve
much faster

34. Fundamentally Different
Model of Developing
Software
(MVC is only one model – the point is:
componentization is possible)

35. II: But it’s extremely Hard

36. Downsides to Opening APIs…
• Security is key
• Scalability needs to be
built in
• It requires long term
support
• New type of business
interaction
• Vendors can Help
• In many cases some
of the work is
already done

37. Downsides to using external APIs…
• Latency?
• Availability?
• Security?
• SLAs?
• Cost
• Service Continuity?
• In most cases there
are no other ways
to solve the
problem
• Tools are emerging

38. This is Distributed Systems
Engineering

39. 10 Hard Things About
Building Distributed Systems
• Interface Definition &
Consistency
• Latency
• Slow or Dead?
• Distributed State
Synchronization
• Remote Clock Problems
• Error Detection
• Change Management
• Static & Dynamic
Testing
• Code Validation /
Verification
• Frame Problems

40. But Wait…
It’s even harder than that …

41. Distributed Across Organizational
Boundaries
• No access to source
code
• No knowledge of Server
Environment
• Security and Access
Permissions Everywhere
• Identity Problems
• Shared Semantics are
much harder to achieve
• Unknown / Mismatched
Scale Issues
• Danger of Much Wider
Interdependencies –
Frame problem is
worse!)

42. Most of these problems are
completely unaddressed
Need to be if we are to reach 100’s of
thousands of APIs

43. Progress Today
R&D / Experimental
• Distributed Verification
• Distributed Systems
Contracts
• Semantic Web Ontologies
• Service Descriptions?
Tools
• Neustar Webmetrics
• Runscope & others
• API-Hub
• Swagger Tools
• Pingdom et. al.
Lots of Interesting Problems to be Solved!

44. Strategies to Avoid Headaches
API Provider
• Publish Specifications
• Handle Versioning Carefully
• Provision for Scale & Rate
Limit
• Code Libraries
• Buffers, Queues, Webhooks
and Asychronous Responses
• Multiple Data Centers
Tools
• Monitoring
• Caching
• Mocks for Testing
• Buffers & Queues
• Failover Services
• Graceful Failure Modes
• Assume Failure Will happen

45. These are a good Start
But the overall problem will get
harder and harder

46. Conclusions

47. Take Away’s
1
2
The World will get Software & API
Enabled
Radical impact on the Software we
write and what is possible
=>
These new systems are complex
and hard to build
The “API Economy” will be way more complex than today’s Web

48. I.e.
The “API Economy” as a global system will
be way more complex than today’s Web

49. Keep Building!
steve@3scale.net
@njyx, @3scale
We make Awesome API Management Tools:
http://www.3scale.net/