How APIs are Changing Software Development

Preview:

DESCRIPTION

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.

Citation preview

How APIs are changing Application Development

Steven Willmott 3scale Inc

@3scale - http://www.3scale.net

On Demand API Infrastructure: http://3scale.net @3scale

me: @njyx on twitter

Powering 250 APIsBillions API Calls / Month

San Francisco 23-25th Octoberhttp://www.apistrategyconference.com

To the Content…

“Software is Eating the World”

Marc Andreessen – WSJ / August 2011

“APIs are Eating Software”

API Days San Francisco 2013

Almost every major industry is becoming software driven

MusicRetail Video Telephony

Meaning:

Examples

Lytro: “Software Defined Cameras”

Philips Hue: “Software ControlledLighting”

Amazon: “Software Driven Retail”

Pixar: “Software powered animation”

APIs are Eating Software

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

Outside-In

More and More APIs are Proliferating

APIs Make Software Remotely Addressable

Wide Diversity of APIs out there

London Transport: Open Data

Evernote: “Platformization”

Netflix: “Massive Distribution”

JCI: “Software Controlled Buildings”

ThousandsOf Devices

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

But, What about “Inside-Out”?

How are APIs Changing Application Development?

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

Download & Add to Classpath

Became

Find and Integrate

Speed (Time to Market)

e.g. + Devops Borat

e.g.(Top Mashup on

Progr Web)

Richness / Functionality

e.g.

e.g.

Offboarding

e.g.

e.g.

(Rich Photo EffectsFor Mobile by SDK)

(Monitoring System in the Cloud)

Reliability

e.g.

e.g.

(Email by API)

(Amazon S3)

The Sum of the Two

Makes Interesting Things Happen

Software Development over Time

Software Before 1995 Software 1995 – 2010 Software 2010 -

Enables specialization, focus, much wider distribution

APIs enable componentization across organizational boundaries

I: New Type of Software Development

Software as Model-View-Controller

VIEW = FORM

MODEL = DATA

CONTROLLER = BUSINESS LOGIC

Model

View Controller

Now it can done at the company / organization level

Example “Models”

Model

Data Anywhere in any form

(copyrights / respective owners)

Example: Views

View

Many Delivery Channels

(copyrights / respective owners)

Example: Controllers

Controller

Many Delivery Channels

(copyrights / respective owners)

APIs Enable Separation & Focus

Model View Controller

Data Anywhere in any form

Many Delivery Channels

Third parties operating on data

Distributed Applications

Software + APIs allow Businesses to co-evolve

much faster

Fundamentally Different Model of Developing

Software

(MVC is only one model – the point is: componentization is possible)

II: But it’s extremely Hard

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

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

This is Distributed Systems Engineering

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

But Wait…

It’s even harder than that …

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!)

Most of these problems are completely unaddressed

Need to be if we are to reach 100’s of thousands of APIs

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!

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

These are a good Start

But the overall problem will get harder and harder

Conclusions

Take Away’s

1

2

The World will get Software & API EnabledRadical 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

I.e.

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

Keep Building!

steve@3scale.net@njyx, @3scale

We make Awesome API Management Tools:http://www.3scale.net/

Recommended