2. Agenda
From APIs to events
Event-driven choreography with Amazon EventBridge
Customer case study
Orchestration with AWS Step Functions
Tracing and observability
7. Manage APIs with Amazon API Gateway
Lambda
function
Lambda
function
VPC
Amazon CloudWatch
monitoring
Amazon
CloudFront
Mobile
apps
Endpoints on
Amazon EC2
Endpoints
in your PCAPI
Gateway cache
Websites
Regional API endpoints
Internet
Services
Any other
AWS service
All publicly
accessible
endpoints
8. HTTP APIs
Up to 70% lower cost
50% lower latency
Standard authentication
API Gateway
10. How do Serverless applications work?
API Gateway
Storage
Databases
Analytics
. . .
Your
unique
business
logic
API call
User uploads a picture
Customer data updated
Anomaly detected
. . .
Fully-managed
services
Events
Functions
11. Concise function logic
• Use functions to transform, not transport
• Use purposefully built services for communication fan-out, message handling, data
replication, and writing to data stores/databases
• Leave retry and error handling to the services themselves
• Read only what you need, for example:
• Message filters in Amazon SNS
• Fine-grained rules in Amazon EventBridge
• Query filters in Amazon RDS & Amazon Aurora
• Use Amazon S3 Select
• Properly indexed databases
• Leverage Synchronous Vs Asynchronous invocations
13. What is an “event” ?
“something that
happens”
Events tell us a fact
Immutable time-series
Time What
2019 06 21 08 07 06 CustomerCreated
2019 06 21 08 07 09 OrderCreated
2019 06 21 08 07 13 PaymentSuccessful
2019 06 21 08 07 17 CustomerUpdated
. . . . . .
14. Commands Vs Events
Command
Has an intent
Directed to a target
Personal communication
”CreateAccount”
“AddProduct”
Event
It’s a fact
For others to observe
Broadcast one to many
”AccountCreated”
“ProductAdded”
15. Introducing AWS Lambda Event Destinations
For asynchronous invocations, capture
success or failure
• Record contains details about the request
and response in JSON format
• Contains more information than data sent
to a DLQ
• Can send both outcomes to the same
destination
or
• Can send success to one destination,
failure to another
AWS Lambda
AWS Lambda
Amazon EventBridge
Amazon SNS
Amazon SQS
NEW!!!
25. Targets
AWS Lambda
Amazon Kinesis
Data Firehose
Amazon SNS
Expanding event sources
SaaS integrations
Amazon
EventBridge
Custom event bus
SaaS event bus
Default event bus
26. Developing with events
Amazon EventBridge
Presentation
Logic
Data
App server
AWS Step
Functions
Amazon
SQS
Amazon
SNS Messaging
AWS Step
Functions
AWS Step
Functions
AWS Lambda AWS Lambda
Custom event bus
SaaS event bus
Default event bus
27. Schema registry and discovery
Explicitly publish and discover
Integrations for JetBrains and VS Code
Language bindings for Java, Python,
and TypeScript
Source of truth for sharing schema
Amazon
EventBridge
33. Pattern
Customer
login
Login Shipping
Send order
to SAP
Data sync
Customer, VIP,
wishlist sync
Checkout
Submit
order
Payment
Authorize
payment
Commerce
platform
Order
Process
order
Order and
customer
updates
Event
relay
Customer
login
Invoke
every
minute
Events Order
complete
Customer
login
Payment
authorized
Order
submit
Order
complete
EventBridge
FIFO
queue
34. Pattern – Hub-and-spoke event bus
{
"version": "0",
"id": "6a7e8feb-b491-4cf7-a9f1-bf3703467718",
"detail-type": "State change Notification",
"source": "service-order-submit-dev",
"account": "111122223333",
"time": "2019-08-29T12:10:21Z",
"region": "eu-central-1",
"resources": [
"arn:aws:events:event-bus/checkout-bus"
],
"detail": {
}
}
Customer-specific
data goes in the
“detail”
35. Pattern – Hub-and-spoke event bus
{
"version": "0",
"id": "6a7e8feb-b491-4cf7-a9f1-bf3703467718",
"detail-type": "State change Notification",
"source": "service-order-submit-dev",
"account": "123456789012",
"time": "2019-08-29T12:10:21Z",
"region": "eu-central-1",
"resources": ["arn:aws:events:event-bus/checkout-bus"],
"detail": {
"event": {
"meta_data": {
"site_id": "LEGO Shop",
"type": "CHECKOUT",
"subtype": "ORDER",
"status": "COMPLETE"
},
"data": {
"order_number": "T123456789",
"customer_id": "bf3703467718-29T12-6a7e8feb"
}
}
}
}
Standard syntax
across multiple
services
Custom for each
service
38. Business workflow is rarely sequential start to finish
Multiple decision paths
Need to handle failure
Multiple-step processes
39. AWS Step Functions + Lambda
“Serverless” workflow management with
zero administration:
• Makes it easy to coordinate the
components of distributed applications and
microservices using visual workflows
• Automatically triggers and tracks each step
and retries when there are errors, so your
application executes in order and as
expected
• Logs the state of each step, so when things
do go wrong, you can quickly diagnose and
debug problems
Choice
Start
ExtractImageMetadata
CheckJobStatus
Amazon
Rekognition
ImageTypeCheck
NotSupportedImageType
End
Thumbnail
AddRekognizedTags
Tasks
Failure capture
Parallel tasks
40. AWS Step Functions: Integrations
Simplify building workloads, such as order processing,
report generation, and data analysis
Write and maintain less code; add services in minutes
More service integrations:
AWS Step
Functions
Amazon SNS Amazon SQS Amazon
SageMaker
AWS Glue AWS Batch Amazon ECS AWS Fargate Amazon EMR
NEW!!!
41. Simpler integration, less code
With serverless polling With direct service integrationStart
End
Lambda
functions
Start
End
No
Lambda
functions
42. Express workflows
High volume, short duration
Cost effective at scale
Streaming data processing –
IoT ingestion
Event streams over 100,000 per second
44. AWS X-Ray
Profile and troubleshoot
distributed applications:
• Lambda instruments incoming
requests for all supported
languages and can capture
calls made in code
• Amazon API Gateway
inserts a tracing header
into HTTP calls and reports
data back to X-Ray
var AWSXRay = require(‘aws-xray-sdk-core‘);
var AWS = AWSXRay.captureAWS(require(‘aws-sdk’));
S3Client = AWS.S3();
48. Finding successLambdausage
IT automation Data transformation Business critical application
Production
mission critical
Adoption curve
Considerations
Rapid development
Time-to-market – agility
Changing business
The pattern that supports high speed innovation (agility, velocity, decision making)
3 core architecture patterns: APIs, Events, Data streams
*** narrative to explain how this takes advantage of AWS platform resilience, and naturally scales with event volume ***
1/ One of my favorite descriptions of the Internet, that stuck with me from early on is – a collection of small pieces loosely joined (allowed it to grow so rapidly with such diversity)
2/ innovate – lots of experiments
3/ things loosely joined by APIs, Events and data flows are able to grow in different directions
1/ The first is API driven, request-reply services
2/ I often think of APIs as the front door of microservices
Org design
Innovate behind APIs - promises
1/ Inside of Amazon when we talk about 2-pizza teams, we often make a hardened API a requirement of any new team - using APIs to define the stable contract between teams.
2/ A service from team-A needs to call an API and get a valuable reply from the function built by team-B. APIs at the perimeter of Fargate services and Lambda functions, allow the teams to iterate actively without changing the request-reply structure between the teams.
** 2018 script **
1/ we’ve built a lot of microservices, and we’ve seen a lot of patterns in the management of the APIs
2/ often starts with auth, and is well integrated with cognito and IAM
3/ resource control - throttling
4/ integrated with X-Ray and CloudWatch
5/ reachability options
6/ direct connect
1/ API Gateway has a released a significant improvement for serverless api calls, which is the best way to build RESTful APIs for serverless applications
2/ lowering your cost 70% and cutting latency times on API calls by 50% or better.
3/ This new feature has its own configuration interface, and will let you import existing APIs from the API Gateway Management tool, or any 3rd party API management system.
4/ Authentication using OIDC/OAUTH2
*** we can hopefully spend a little more time on this ***
** we launched Lambda at re:Invent 5 years ago, and have seen use cases and application patterns emerge over time as Lambda became more integrated with a wide range of serverless capabilities throughout AWS.
1/ Our terminology has evolved over that time, also.
2/ I tend to think of a Serverless Application as being comprised of decoupled services that scale independently and trigger execution using events.
3/ We think there at least 3 application patterns that work really well, and make up the majority of Serverless Applications -
Real world (IoT); Old world (enterprise bus); Modern (mobile, decoupled)
1/ Events give you this great decoupling benefit
2/ individual services that react to each other
SQS FIFO; SNS DLQ; Integration controls
The first place to start is with the AWS event sources that already exist. We have our cloud native queueing and notification services…
1/ Any existing services that can post messages to publish messages to SNS, can start building NEW event-driven microservices built as functions in Lambda.
2/ AirBnB has created an opensource project for such a scenario. Having messages originate from containerized apps which result in an event triggering a Lambda is a very common use case.
3/ every time you use an AWS service, you can generate an event through EventBridge
.
But, earlier in the year we took another step with EventBridge by creating a 3rd party integration program. We actively work with some of the most common 3rd party software services running at AWS – services like: *** list partners ***. We think this program will continue to make it simpler for builders to subscribe to standard events 3rd parties they already use *** question whether we should single anyone out ***
** talk about the newest integration MongoDB?
– For teams starting from a clean sheet, who are able to build without existing constraints, I enjoy talking about the benefits of event-driven architectures. But, for teams with an existing investment in a production system, how do they envision using events to build new additions using an event-driven design?
But, sometimes a standard event doesn’t exist for the action you want to trap. So, we support custom events *** describe the previous process of building, documenting and publishing custom events ***
We’re certainly doing everything we can to make it easier to create event sources, but what are we doing to add to the ability to consume the events and build more complex coordination between functions? Step Functions is a useful tool for consuming events, and defining coordinated execution of multiple services in response to those events – often, we’ll shorten that description to “workflow”. *** longer explanation of Step Functions ? ***
So how do we track state between all these things?
How do we make sure things are executing in the right order and at the right time?
We need a state machine of course
In simpler terms, we need a way to orchestrate the different workflows between all the services
Set timeouts on tasks, interrupt execution, have tasks send heartbeats, and monitor and audit at fine granularity.
So how do we track state between all these things?
How do we make sure things are executing in the right order and at the right time?
We need a state machine of course
In simpler terms, we need a way to orchestrate the different workflows between all the services
Set timeouts on tasks, interrupt execution, have tasks send heartbeats, and monitor and audit at fine granularity.
Many applications contain workflows that must execute tasks in a reliable and repeatable sequence using independent components and services. Before Step Functions, customers who automated business processes had to spend weeks to write and then manage complex custom workflow code and interfaces.
Today, customers use AWS Step Functions to add resilient workflow automation to their applications. Workflows on Step Functions require less code to write and maintain. Step Functions integrates with AWS Lambda. This makes it easy to add Lambda tasks to workflows, such as calculating a credit score as part of a loan application workflow, or creating a customer account as part of a subscription workflow.
Customers asked us for more service integrations so that they could be even more productive with Step Functions. Now, developers can connect and coordinate eight more AWS compute, database and messaging services in minutes, without writing code. These new service integrations simplify and speed delivery of solutions for workloads such as order processing, report generation, and data analysis pipelines.
To manage asynchronous jobs, customers can create serverless polling loops to detect when a job completes.
With the new service integrations, when your workflows start an AWS Batch job, run a container on ECS or Fargate, or invoke a Lambda function, Step Functions will detect for you when the job, container, or function completes its work before transitioning to the next step.
So, this was a packed hour, with a lot to think about. But, most of you are here because you are considering future plans, and validating ideas you have. Teams looking to adopt serverless programming models introduce the fundamentals from a couple of different perspectives
