The document discusses the evolution of API and software architectures over time. It begins with a history of mainframe computing and waterfall development methodology. It then outlines the rise of client-server architectures, web frameworks, and cloud computing which enabled more agile development practices. Some pitfalls of early approaches are discussed like frameworks becoming tightly coupled. The document promotes microservices, APIs, architecting for scale, and generative technologies as modern solutions. It provides an example of how Twitter's architecture evolved in response to growth enabled by their public API.

1. API Architecture
AWS Chicago 12/1/2015

2. A short history lesson
Once upon a time,
mainframes ruled the world.
Resources were precious and
very limited.

3. A short history lesson
Many companies still rely on
these systems today.
Not by choice, but due to heavy
investment and commitment.

4. A short history lesson
Supply of qualified engineers
continues to shrink.
Changes involve significant risk.

5. A short history lesson
Difficult to onboard new
engineers.
Technical debt grows over time
as fear prevents changes to
existing systems.

6. Things got a little bit better
Rise of desktop computing
replaces thin clients.
Client/Server architecture takes
over.

7. Things got a little bit better
Web Browsers became
“standard” clients.
HTTP provides a standard
communication protocol.

8. But not really…
Multi-year projects were
accepted as the norm.
Post-release updates were
painful and very rare.

9. But not really…
Browser wars of the late 90s.
Y2K made COBOL
programmers relevant again.

10. 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.

11. Waterfall methodology
1956 - 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)

12. 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.

13. Things really get better
1994-2001 Agile Methodology
2002-2005 Web Frameworks
(Rails, Spring, Django, Flask, ASP.net, etc.)
2006 Amazon Web Services

14. 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.

15. Pitfalls
Technology is a moving target
that evolves quickly.
Scaling is hard.
Frameworks often are tightly
coupled.

16. Solutions
APIs and Microservices
Architecting for scale
Generative Technology

17. Microservices
Loosely coupled
Lightweight unix-like services
Rise of Docker and AWS
services simplifies management

18. 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

19. 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.

20. 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.

21. Twitter example
Twitter 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

22. http://www.slideshare.net/RyanK/api-architecture
Twitter: @RyanK
http://elelsee.com