The Future of API Management Is Serverless

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Chris Munns – Senior Developer Advocate – AWS
Serverless
The Future of API
Management is
Serverless

About me:
Chris Munns - munns@amazon.com, @chrismunns
• Senior Developer Advocate - Serverless
• New Yorker
• Previously:
• AWS Business Development Manager – DevOps, July ’15 - Feb ‘17
• AWS Solutions Architect Nov, 2011- Dec 2014
• Formerly on operations teams @Etsy and @Meetup
• Little time at a hedge fund, Xerox and a few other startups
• Rochester Institute of Technology: Applied Networking and Systems
Administration ’05
• Internet infrastructure geek

https://secure.flickr.com/photos/mgifford/4525333972
Why are we
here today?

1994-2001
Development transformation at Amazon:
2001+
monolithic architecture +
hierarchical organization
decoupled services +
2 pizza teams

Two-pizza teams
Full ownership
Full accountability
Aligned incentives
“DevOps”

2 Pizza Team Responsibility Venn Diagram
Responsible for
THEIR
PRODUCT
Deployment tools
CI/CD tools
Monitoring tools
Metrics tool
Logging tools
APM tools
Infrastructure provisioning
tools
Security tools
Database management
tools
Testing tools
….
Not responsible for
*
*Unless their product belongs in the blue

Responsible for Not responsible for
*
NOT
THEIR
PRODUCT
*Unless their product belongs in the blue
Application development
Infrastructure management
Application configuration
Pipeline configuration
Alarms
Runbooks
Testing
Compliance
Roadmap tracking
Goals tracking
On-call
Support escalation
….

Determining the right balance
The more time spent on operational tasks, the
less time spent on development tasks

Determining the right balance
Teams aim to spend <20% of their time on non-
development tasks
The more time spent on operational tasks, the
less time spent on development tasks

Responsible for
THEIR
PRODUCT
Not responsible for
NOT
THEIR
PRODUCT
Can we shift more from a
team’s responsibility to the
platform/shared services?

No server is easier to manage than
"no server”.
Dr. Werner Vogels
Amazon CTO

No servers to provision
or manage
Scales with usage
Never pay for idle Availability and fault
tolerance built in
Serverless means…

SERVICES (ANYTHING)
Changes in
data state
Requests to
endpoints
Changes in
resource state
EVENT SOURCE FUNCTION
Node.js
Python
Java
C#
Go
Serverless applications

Create a unified
API frontend for
multiple micro-
services
Authenticate and
authorize
requests to a
backend
DDoS protection
and throttling for
your backend
Throttle, meter,
and monetize API
usage by 3rd
party developers
Amazon API Gateway

Amazon API Gateway
Internet
Mobile Apps
Websites
Services
AWS Lambda
functions
AWS
API Gateway
Cache
Endpoints on
Amazon EC2
Amazon
CloudWatch
Monitoring
Amazon
CloudFront
Any other AWS
service
YOUR VPC
Endpoints in
Your VPC
Regional API Endpoints
All publicly accessible
endpoints
AWS Lambda
functions

REST API vs GraphQL
Traditional data-fetching GraphQL
/posts
/postInfo
/postJustTitle
/postsByAuthor
/postNameStartsWithX
/commentsOnPost
Open, declarative data-fetching specification
!= Graph database
Use NoSQL, Relational, HTTP, etc.
GraphQL

How does GraphQL work?
{
"id": "1",
"name": "Get Milk",
“priority": "1"
},
{
"id": “2",
"name": “Go to gym",
“priority": “5"
},…
type Query {
getTodos: [Todo]
}
type Todo {
id: ID!
name: String
description: String
priority: Int
duedate: String
}
query {
getTodos {
id
name
priority
}
}
Model data with
application schema
Client requests what it
needs
Only that data is
returned

Realtime and offline data using GraphQL
Real-time
collaboration
Offline programming
model with sync
Your data sources
Fine-grained
access control
AWS AppSync

Yes!
We see a high ratio of private
to public APIs (approx. 10:1).
Possible pattern:
GraphQL for external facing
applications/clients
REST for internal services
Public
interface
Internal
services
Can these technologies co-exist?
The microservice’s iceberg

How does
serverless help with
development?
https://www.flickr.com/photos/lachlanhardy/4150836513/

Lines of Code (LoC)
Monolith = 10,000s to 1,000,000s
Microservices = 100s to 1000s
Lambda “nano-services” = 10s to 100s

Lines of Code (LoC)
Monolith = 10,000s to 1,000,000s
Microservices = 100s to 1000s
Lambda “nano-services” = 10s to 100s
+ Simplified testing of code
+ Easier to onboard new developers
+ Super fast deployment times
+ Orchestration in managed services not code
+ Reduced “blast radius” of issues
+ Greatly reduced technical debt

What can we do
with this?
https://www.flickr.com/photos/spacex/40143096241/

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
What happens if we
reduce operational
burden massively and
reduce the amount of
code we have to write?

What if 2 pizzas
is 1 too many?

<2 Pizza Team Model Potential Benefits (my words)
• Smaller getting started headcount for a new team
• Lower cost of experimentation for new ideas
• Even less drift between teams in terms of operating
procedures (more standards?)
• Greater agility/time to market
• Increased availability
• Reduced technical debt over time

FIN/ACK
• APIs are the future of application and service design
• Both REST and GraphQL have their pros/cons, but they
can live together in the same infrastructure
• Serverless technologies are changing how companies
build and run infrastructure at any scale
• What tasks are your teams focusing on that could be
shifted away from them to managed/shared services?

Chris Munns
munns@amazon.com
@chrismunnshttps://www.flickr.com/photos/theredproject/3302110152/

?
https://secure.flickr.com/photos/dullhunk/202872717/

The Future of API Management Is Serverless

More Related Content

The Future of API Management Is Serverless

Editor's Notes