API ArchitectureAWS Chicago 12/1/2015

A short history lesson

Once upon a time, mainframes ruled the world.

Resources were precious and very limited.

A short history lesson

Many companies still rely on these systems today.

Not by choice, but due to heavy investment and commitment.

A short history lesson

Supply of qualified engineers continues to shrink.

Changes involve significant risk.

A short history lesson

Difficult to onboard new engineers.

Technical debt grows over time as fear prevents changes to existing systems.

Things got a little bit better

Rise of desktop computing replaces thin clients.

Client/Server architecture takes over.

Things got a little bit better

Web Browsers became “standard” clients.

HTTP provides a standard communication protocol.

But not really…

Multi-year projects were accepted as the norm.

Post-release updates were painful and very rare.

But not really…

Browser wars of the late 90s.

Y2K made COBOL programmers relevant again.

Waterfall methodology

Once considered state of the art and commonly accepted as a best practice.

Successfully reigned as the gold standard until the Internet came along.

Waterfall methodology1956 - Waterfall development model first presented publicly

1970 - First formal description in a paper by Winston W. Royce, criticizing conventional wisdom and labeling it “non-working”.

1985 - United States Department of Defense mandates waterfall as a standard for contractors (DOD-STD-2167A)

What’s wrong with waterfall anyway?

Early choices locks the project into a design.

Requires foresight into future business needs.

Rigid and not easily adaptable as technology evolves.

Speed to market is severely limited.

Things really get better

1994-2001 Agile Methodology

2002-2005 Web Frameworks (Rails, Spring, Django, Flask, ASP.net, etc.)

2006 Amazon Web Services

Things really get better

A simple prototype or proof of concept could now be built quickly.

Short iteration cycles can add functionality to quickly get to a Minimum Viable Product

Deployed easily without having to procure or configure hardware.

Pitfalls

Technology is a moving target that evolves quickly.

Scaling is hard.

Frameworks often are tightly coupled.

Solutions

APIs and Microservices

Architecting for scale

Generative Technology

Microservices

Loosely coupled

Lightweight unix-like services

Rise of Docker and AWS services simplifies management

APIs

Business functions are encapsulated within API endpoints.

Easily consumed by client applications, without knowledge of backend implementation.

Allows for Engineers to focus on what they excel at

Architecting for Scale

Predicting growth is hard, overestimate to provide a buffer.

Individual components can scale independently without impacting the rest of the system.

Monitoring smaller parts quickly exposes bottlenecks or other performance issues.

Generative Technology

New platforms can consume the same API endpoints.

External partners can use your API and grow your business.

Public APIs will produce new and unimagined applications.

Twitter exampleTwitter began on Rails with a focus on SMS messaging.

Quickly outgrew their architecture.

Slowly replaced every portion of their architecture.

Invented new solutions to emerging problems.

Twitter API accelerated adoption

http://www.slideshare.net/RyanK/api-architecture

Twitter: @RyanK

http://elelsee.com