Amy Negrette - Gateways to Gateways: API Development with AWS We will go over how to plan and migrate legacy APIs with API Gateway options in AWS such as EKS and Lambda. We will also compare a traditional web server API design with a serverless one. AWS Community Day aws community day | midwest 2019

1. MIDWEST | CHICAGO

2. Gateways to Gateways:
API Development in the Cloud
Amy Arambulo Negrette | Cloudreach | 2019

3. Who am I?
Amy Arambulo
Negrette
I build a lot of APIs a lot of
different ways for a lot of
different people.

4. Let’s talk APIs

5. What are APIs?
“A system of tools and resources in an operating system, enabling
developers to create software applications.”
What do we mean?
The Abstracted Layer that allows communication to application logic
and returns a response – OR – the application which traffics the
request to the logic. 5

6. “Serverless computing (or serverless for
short), is an execution model where the
cloud provider (AWS, Azure, or Google
Cloud) is responsible for executing a piece
of code by dynamically allocating the
resources.” – The Serverless Stack
6

7. What is Serverless really?
An Event Driven Application Design that
leverages Cloud Native Services.
• Fast
• Optimized
• Scales
• Pay-as-You-Go
7

8. Decisions, decisions!
8

9. New Development
9

10. 10
Containers
Containers are like small, streamlined virtual
machines. Except where a virtual machine is an
entire system, OS and all, a Container will only
have an application and its dependencies, using
the OS and Kernel of the machine it lives on.
For APIs housed in containers, an API, its
framework, and a webserver can live in the
container, while its required infrastructure, such
as a Linux or Windows machine, remain outside.
Source: Docker.com | What is a
Container?

11. 11
Containers
Pros:
Ø Can move from machine to machine
Ø No need to upskill API developers*
Ø More Runtime Control
Cons:
Ø High overhead on Container Maintenance
Ø One bad container…
Source: Docker.com | What is a
Container?

12. 12
Serverless architecture uses Cloud Native
services to create an infrastructure that
does not need to be managed by the
Developer. It most often uses a
combination of a Cloud Provided API
Gateway and Functions as a Service or
Containers.
For developing APIs, the Cloud Provider
will create a collection of endpoints that
connect to a Cloud Compute Service
triggered by Events such as HTTP Requests
or Event Queues.
Serverless

13. 13
Pros:
Ø Lightweight
Ø Pay-as-you-go
Ø Cloud Native, Cloud Optimized
Cons:
Ø A very different Programming
Paradigm
Ø Vendor Lock
Ø Developers touch more
Infrastructure
Serverless

14. Legacy APIs
14

15. 15
Lift & Shift
Pros:
Ø Least Code Changes
Ø Fastest to Live
Ø No Upskilling
Cons:
Ø Pay Per Hour
Ø Lose Optimization

16. 16
Modernize
Pros:
Ø Optimized
Ø Future Proof
Cons:
Ø Slow to Market
Ø Requires overhaul of
infrastructure and software
Ø Language Specific

17. Why Serverless?
17

18. 1818

19. 19
Application Requirements
Ø Maintains a database of Unicorns and States
Ø Allow Authentication for Users
Ø Maintain a database of Users
Ø Maintain a history of Actions
Ø Allow Users to order Unicorns

20. 20
Application Diagram

21. 21
All about the $$$$
This includes no scaling, no auto-patching, and an always-on design.

22. 22
Serverless Design

23. 23
ServerLESS $$$
1,250,000 invocations for less than $1
2,000,000 are less than $4
API Gateway costs $3.50 per million
requests for the first 330m
Cognito is free for your first 50k maus
DynamoDB is $5.33 for 355k reads and
355k writes
Amplify costs $.15 per GB served.

24. 24
Version Control
Ø Track All Development & Prevent Loss
Ø Infrastructure as Code
Ø Deploying Cloud Native Resources using JSON or
YAML definitions
Ø Native and Framework Definitions can be tracked in
Git

25. 25
Serverless Application
Management
Ø Native Service for deploying AWS
Resources
Ø Defined in YAML
Ø Can Deploy from the Command
Line
Ø Deploys to a CloudFormation
Stack

26. 26
Terraform
Ø Good at deploying Multi-Cloud
Resources, Less good at Serverless
Resources
Ø Defined in HCL
Ø Deploys only from Command Line
Ø Does not create CloudFormation
Stack
Ø Need to repackage the deployment
package on every apply

27. 27
Serverless Framework
Ø Good at deploying *most*
Cloud Native Services
Ø Still need to build some things
manually
Ø Creates Stack definitions in the
Cloud
Ø Definitions can be checked into
Git

28. 28
Runtime Control - Layers
A function can use up to 5 layers at
a time. The total unzipped size of
the function and all layers can't
exceed the unzipped deployment
package size limit of 250 MB

29. 29
Monitoring – Cloudwatch & X-Ray
Ø Not End User
Friendly
Ø Requires
Instrumentation
Ø Requires a lot of
‘clicks’ to get there

30. 30
Monitoring - 3rd Party
Tools
Ø User Friendly
Ø Add as a Layer or Library
Ø Easy to Navigate
Ø More Visual Context

31. Ø How to build New APIs
Ø How to Migrate Legacy
APIs
Ø Breaking Apart Monolith
Applications
Ø The Costs of Monolith vs
Serverless
31
Ø Version Control with
Infrastructure as Code
Ø Controlling Runtimes
Ø Monitoring Serverless
Resources

32. Gateways to Gateways: API
Development in the Cloud
Amy Arambulo Negrette | Cloudreach
Linkedin: /in/amycodes
Twitter: @nerdypaws
32