© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

November 30, 2016

IoT401

Serverless IoT Back Ends

Olawale Oladehin, AWS Solutions Architect

Ben Kehoe, iRobot Cloud Robotics Research Scientist

The Things in the Internet of Things…

AWS re:Invent 2016

Olawale “Wale” Oladehin

• Amazon Web Services

Solutions Architect

@oladehin

Assuming you’ve heard of…

AWS

Lambda

Amazon

DynamoDB

AWS IoT

IoT

shadow

AWS IoT

rule

Amazon

SNS

Amazon

API

GatewayAmazon

SQS

Amazon

KinesisAmazon

Elasticsearch

Service

What will you learn in this session

• Benefits of serverless IoT back ends

• Foundations of serverless IoT back ends

• iRobot customer experience

Advantages of

serverless IoT back ends

What are the principles of an IoT architecture?

Fault-tolerant

Decoupled Scalable

Cost-efficient

Visibility

Agility

Secure

Microservices

Distributed

Anti-fragile

DevOps

Low latency

Event sourcing

Advantages of serverless IoT back ends

Scalable Event-drivenDon’t pay for

idle

Stateless

Blueprint for serverless IoT

back ends

Blueprint for serverless IoT back ends

AWS LambdaAWS IoT Amazon API

Gateway

Blueprint for serverless IoT back ends

State management

Amazon

DynamoDB

Amazon

ElastiCache

Amazon

Elasticsearch

Service

AWS IoT

IoT

shadow

Amazon API

GatewayAWS Lambda

Blueprint for serverless IoT back ends

Fast pipeline

AWS IoT Amazon API

GatewayAWS Lambda

Amazon

S3

Amazon

Kinesis

Amazon

SQS

Amazon

SNS

Blueprint for serverless IoT back ends

Operations

Amazon

CloudWatch

AWS

CloudFormation

AWS IoT Amazon API

GatewayAWS Lambda

Blueprint for serverless IoT back ends

State management Operations

Amazon

S3Amazon

DynamoDB

Amazon

ElastiCache Amazon

CloudWatch

AWS

CloudFormation

Amazon

Elasticsearch

Service

Amazon

Kinesis

AWS IoT

IoT

shadow

Amazon

SQS

Amazon API

Gateway

Amazon

SNS

AWS Lambda

Fast pipeline

Example architecture for

serverless IoT back end

Example: smart transportation

Mobile device

Turnstiles

State management

State management Operations

Amazon

S3Amazon

DynamoDB

Amazon

ElastiCache Amazon

CloudWatch

AWS

CloudFormation

Amazon

Elasticsearch

Service

Amazon

Kinesis

IoT

shadow

Amazon

SQS

Amazon

SNS

Fast pipeline

Stateless != state doesn’t matter

• How do we deal with state?

• Store output

• Search index

• Time series

• Structured

Stateless != state doesn’t matter

• How do we deal with state?

• Store output

• Store each event• Analytics

• True system

history

• Arbitrary

projections(x)

Smart transportation – mobile device

Topic:

$aws/events/subscriptions/subscribed/*

API Gateway Lambda Sign up

Events

Lambda AWS IoT

Republish rule

Fault-tolerant

Cost-efficient

Scalable

Agile

Secure

Visibility

IoT

shadow

Offline SNS

Registration

Lambda

Smart transportation – shadow republish

{

"sql": "SELECT topics as state.reported.stationsFROM '$aws/events/subscriptions/subscribed/#'" WHERE eventType = 'subscribed',

"actions": [{

"republish": {

"topic":"$$aws/things/${topic(5)}/shadow/update", "roleArn":"arn:aws:iam::123456789:role/republish"

}

}]

}

Fast pipeline

State management Fast pipeline Operations

Amazon

S3Amazon

DynamoDB

Amazon

ElastiCache Amazon

CloudWatch

AWS

CloudFormation

Amazon

Elasticsearch

Service

Amazon

Kinesis

IoT

shadow

Amazon

SQS

Amazon

SNS

Fast pipeline - components

• AWS Lambda

• Internal

applications

• Amazon Kinesis

• Amazon SQS

• Amazon SNS

• Amazon S3

ConsumerPipeProducer

• AWS IoT rules

• AWS Lambda

• Amazon API

Gateway

When to use a fast pipeline

AWS IoT Republish

Rule

AWS Lambda IoT pipeline

Transactions per

second

Predictable or steady

volume

Infrequent or steady

volume

High or

unpredictable

volume

Communication

pattern

Request/ACK

Publish/Subscribe

Request/ACK

Request/Response

Request/ACK

Request/Response

Ingest

Deployment

pattern

Rule replacement Lambda alias Consumer

replacement

Transformations IoT data

Rules engine context

Contextual

transformation

Aggregations

Event-analysis

Smart transportation – pipeline

Time Series

Traffic

Commuter

Subway

Event

Amazon

Kinesis

Firehose

Time Series

Backup

Commuter

Online Status

Topic: LWT disconnects

Delay Connection

Events

Fault-Tolerant

Cost-efficient

Scalable

Agile

Secure

Visibility

Amazon

Kinesis

Streams

Poller / Worker

Functions

Topic:

train/<line>/station/<sid>

Topic: user/<id>/trip/<tid>

IoT operations

State management Fast pipeline Operations

Amazon

S3Amazon

DynamoDB

Amazon

ElastiCache Amazon

CloudWatch

AWS

CloudFormation

Amazon

Elasticsearch

Service

Amazon

Kinesis

IoT

shadow

Amazon

SQS

Amazon

SNS

IoT operations

• Custom CloudWatch logs and metrics

• Shared library in AWS Lambda code

• Application metrics attached IoT rule

• Enable AWS IoT CloudWatch Logs

• Deployment

• Group functions into services

• Fault-tolerant

• Graceful degradation

• Trigger automatic failover

• Configure CloudWatch alarms

Smart transportation – metrics

Fault-tolerant

Cost-efficient

Scalable

Agile

Secure

Visibility

AlarmCloudWatch

Amazon

KinesisLambda

Smart transportation – operations IoT rule

{

"sql": "SELECT *,newuuid() AS requestId, timestamp() AS timestamp, topic(2) AS subwayId, topic(4) AS stationId FROM 'train/+/station/+/v1' ",

"actions": [{

...

}]

}

Smart transportation – deployment

Service separation:

• Share data

• Interface API

Gateway

• Interface AWS

LambdaSubscription service

Tollgate service

Connections service

Blueprint for serverless IoT back ends

State management Operations

Amazon

S3Amazon

DynamoDB

Amazon

ElastiCache Amazon

CloudWatch

AWS

CloudFormation

Amazon

Elasticsearch

Service

Amazon

Kinesis

AWS IoT

IoT

shadow

Amazon

SQS

Amazon API

Gateway

Amazon

SNS

AWS Lambda

Fast pipeline

AWS re:Invent 2016

Ben Kehoe

• iRobot Cloud Robotics

Research Scientist

@ben11kehoe

The

Consumer

Robot

Company

Just live your life - House does the right thing.

- Automatically configured and maintained.

- Adapts to your preferences.

Foundational Milestone

The Roomba 900 series provides

compelling user benefits today and is a

foundation for expanding the value of

robots in the home.

Key to this step is that Roomba is

connected and it systematically

navigates and maps the home.

In 10 months, we mapped more than 500

million square feet

IoT business

• User pays for device once

• Company pays cloud costs

for life of device

• Subscription models

• Result: without subscription,

minimize cloud cost

Choosing serverless at iRobot

• Experience building devices, not

cloud applications

• Fleet already at scale

• Go straight to serverless to skip

the undifferentiated heavy lifting

step

Serverless architecture @ iRobot

Login &

associate

Robot

registration

Firmware

update

Maintenance

data

MappingRobot

settings

Push

notifications

Mission

history

Robot

reset

Before serverless architecture

def foo(input):

quux = bar(input.baz)

internalState.quux = quux

def bar(input):

# do work

return result

Serverless architecture

def handler(event, context):

quux = Lambda.Invoke(

'bar',

event['baz'])

DynamoDB.PutItem(

'quux',

quux)

def handler(

event,

context):

# do work

return result

Foo

ExternalState

Bar

Serverless architecture

/register Check

cert

Robots to

register Queue

reader

Register

robot

Logging Lifecycle event

PermissionsCreate shadowDead letter queue

Serverless architecture

• Component graph = call graph

• Distributed system thinking:

• Traditionally occurs at system boundaries

• Serverless: must be treated

systematically

• Build robust-by-design systems

Architecture selection

Monolithic/layered Microservices

Microservices: interservice communication

Microservices

Robot history Permissions

Lambda LambdaAPI Gateway DynamoDB

KMS

Service interface: API Gateway backed by Lambda

https://www.prerender.cloud/lambda-latency

Robot history Permissions

Lambda LambdaAPI Gateway DynamoDB

KMS

Alternative: direct resource access through service

SDK

Microservices in code…

…but a monolith in deployment

Red/black deployment

Terminology (arbitrary)

Blue/green: update behind

the load balancer

Red/black: entirely

new copy

Red/black deployment options

Red/black an individual service?

Or the entire application?

Service discovery

Client discovery of endpoints

• How does a client

switch from one

endpoint to another?

Client ?

red.example.com

black.example.com

Client discovery of endpoints

• How does a client

switch from one

endpoint to another?

• DNS?Client

Route53

red.example.com

black.example.com

prod.example.comCNAME

red.example.com

CNAME

black.example.com

Client discovery of endpoints

• How does a client

switch from one

endpoint to another?

• DNS?

• Service discovery

service

• How do we

deploy this

service?

Client

red.example.com

black.example.com

HTTPS GET

svcdisc.example.com

{

"host":

"red.example.com"

}

{

"host":

"black.example.com"

}

Deployment for well-known endpoints

Client

red.svcdisc.example.com

black.svcdisc.example.com

HTTPS GET

svcdisc.example.comCloudFront

Secure file transfer

Request topic

Presigned URL

Symmetric

encryption key

Robot

public key

Response topic

Presigned URL

Object encrypted with

symmetric key

HTTPS call

to presigned URL

S3

KMS

Robot

certificate

S3

bucket

+

symmetric key

encrypted with

robot public key

IoT security: certificates

Robot

certificate

+ signed timestamp

CA certificate

Unauthenticated

HTTPS

Robot

certificate

Authenticated

MQTT

Ops for AWS IoT:

account structure

Account structure

• Shadow and topics are not

namespaced

• If sharing accounts:

• Devs might step on

each other’s toes

• Harder to purge for

testing

• After ~10 accounts, adding

accounts gets amortized via

process

acct 1 acct 2 acct 3

us-east-1 NO NO

us-west-2 YES YES YES

eu-west-1 YES YES YES

Certificates, accounts, and regions

• Certificates in AWS IoT

must be unique in a region

even across accounts

• In another region, certificate

can exist in the same or

another account

• Certificates can be

transferred

Account structure

• Given constraints on

certificates, how do you

provision devices?

• Option 1: Separate CA(s)

for each dev accounts

• Option 2: Single Initial Point

of Contact account (prod or

other), push to other

accounts

Serverless Ops

Serverless ops

• Serverless is not NoOps

• Infrastructure as code

• Build artifacts

• Observability

• Logging

• Auditing

• Security

• Billing

Summary: iRobot’s cloud journey

• iRobot's place in the smart home

• Non-subscription cloud services are cost-sensitive

• Skip heavy lifting with serverless

• Patterns:• Direct resource access

• Full red/black deployments

• Service discovery service with well-known endpoint• CloudFront for deployment

• Enables AWS WAF

• Secure file transfer

• Account structure

• Serverless ops

Summary

Summary

• Goals of IoT architectures

• Benefits of serverless IoT back ends

• Blueprint for serverless IoT back ends

• State management

• Fast pipeline

• IoT operations

Thank you!

Remember to complete

your evaluations!

Related Sessions

• IoT403 Robots: The Fading Line Between Real and

Virtual Worlds

• SRV402 – Operating Your Production API

• SRV303 – Coca-Cola: Running Serverless Applications

with Enterprise Requirements