2. We can't overestimate the value of computers.
Yes, they are great for playing games and forwarding
funny emails. But real business is done on paper.
“
3. Most machine data never reaches the cloud
Medical equipment Industrial machinery Extreme environments
4. Why this problem isn’t going away
Law of physics Law of economics Law of the land
5. Three pillars of IoT
Things
Sense
& Act
Cloud
Storage
& Compute
Intelligence
Insights &
Logic → Action
7. AWS Greengrass
Cloud
AWS Greengrass extends AWS onto your devices, so they can act locally on
the data they generate, while still taking advantage of the cloud.
12. Greengrass Components
Greengrass is software, not
hardware (you bring your own)
2 Components that work together:
• Greengrass Core
• IoT Device SDK
13. AWS Greengrass Core (GGC)
The runtime responsible for
Lambda execution, messaging,
device shadows, security, and for
interacting directly with the cloud
14. AWS Greengrass Core (GGC)
• Min single-core 1 GHz
• Min 128 MB RAM
• x86 and ARM
• Linux (Ubuntu or Amazon)
• The sky is the limit
15. IoT device SDK
Any device that uses the IoT
device SDK can be configured to
interact with AWS Greengrass
core via the local network
Devices can be small or big
Starts with the IoT device SDK
for C++, more coming soon
16. Devices work together locally
An AWS Greengrass group
is a set of cores and other
devices configured to
communicate with one
another
17. Devices work together with the cloud
AWS Greengrass works
with AWS IoT to maintain
long-lived connections
and process data via
the rules engine
Your Lambda functions
can also interact directly
with other AWS services
19. Local Lambda
Lambda functions are event-driven
compute functions
With AWS Greengrass you can
write Lambda functions in the
cloud and deploy them locally
20. Local Lambda
AWS Greengrass runs Lambda
functions written in Python 2.7
Invoke Lambda functions with
messaging and shadow updates
21. Local Lambda—What you can do
Command and control
Offline operation
Data filtering and aggregation
Get smarter over time
22. Shadows
JSON documents that
represent state of your devices
and Lambda functions
Define them however is logical to
you—a car, an engine, a fleet
Sync to the cloud or
keep them local
23. Shadows – What you can do
Device state (current and desired)
Granular device state (only
synched to the cloud for debug)
Lightweight configuration
24. Messaging
Local MQTT pub/sub messaging
Define subscriptions between
publishers and subscribers
Apply MQTT topic filters
25. Security
Mutual auth, both locally and also
with the cloud
Certificate on your devices can be
associated to SigV4 credentials in
the cloud
You can directly call any AWS
service from AWS Greengrass
29. Why Greengrass is important
Data processed
in the cloud
Data
processed
locally
Embedded
developer
Cloud
developer
Program devices with
modern languages,
deployment APIs, and
workflows
Cloud-based
development that adds
value to data that never
reach the cloud
Execute code locally
in response to data
30. How to get started today
Sign up for limited preview
Order AWS Snowball Edge
http://aws.amazon.com/Greengrass
This one is funny to me because of course, here’s a paper salesman who assumes paper must be the answer to everything.
Does Greengrass solve a durable problem, or can everything eventually run in the cloud?
Yes, Greengrass solves a durable problem for three structural reasons: The first is economics: the cost of bandwidth is not falling as fast as the cost of storage and compute. Greengrass provides tools for locally aggregating and filtering data, making it easy to act on lower-value data locally, and upload high value data and aggregated data to the cloud for analytics and storage. The second set of durable problems is latency and last-mile connectivity. Latency to the cloud can be unacceptable for scenarios that involve timely automated decision making (crash avoidance, medical alerts), or physically remote operating environments (mining sites, aircraft in-flight) especially in conjunction with wide-area wireless networks (such as cellular). So some decision-making must continue to be executed locally on the device. High-value and safety-critical processes must also continue working when the internet connection is down. The third set of durable problems is compliance and privacy. For legal or compliance reasons, and concerns around privacy, some industries prefer to store or duplicate some data locally. For example, hospitals may be required to keep all records locally, even if they are also duplicated in the cloud. Some governments impose data sovereignty restrictions on where data may be stored.
Looking at these 3 fundamental constituents,
The acronym “IoT” in fact should have a different meaning:
I: for INTELLIGENCE
O: for ORCHESTRATION
T: forTHINGS
Cloud-Orchestration is key to simplifying the complexity of IoT solutions.
A year ago, at this very same place, we started in the cloud and announced our AWS IoT Service.
AWS IoT started with:
a platform that enables you to securely connect devices to AWS Services and other devices
secure data and interactions
process and act upon device data
enable applications to interact with devices even when they are offline.
And during the course of 2016 we successively added add. feature like
IPv6 and websocket support
iOS SDK
to name a few.
We’re going to help you put intelligence through the body of the application that still takes advantage of the head
Today, I want to talk about how AWS is approaching the first pillar of IoT on the “things side”, often called the edge.
I am proud to introduce limited preview of our new service called AWS Greengrass to you.
AWS Greengrass brings local compute, messaging, data caching, and sync to connected devices even when they are not connected to the internet
AWS Greengrass is a software platform for running AWS Lambda functions and AWS IoT functionality locally on virtually any connected device. With AWS Greengrass, connected devices can run AWS Lambda functions, keep device data in sync, and communicate with other devices securely – even when not connected to the Internet. AWS Greengrass works on almost any device with a general-purpose CPU that runs Ubuntu or Amazon Linux, and supports ARM and x86 architectures. Building cloud-enabled devices that work offline required maintaining separate code bases for local and cloud execution. Programming AWS Greengrass devices is easy; developers can use the same programming language (Python during the limited preview phase) and model that they use in their existing AWS environments. This means developers can create and test their device software in the cloud, and then seamlessly deploy it to all of their devices.
The AWS IoT Device SDK helps you to easily and quickly connect your hardware device to AWS IoT. It provides enhanced features so that your hardware device can seamlessly and securely work with the Device Gateway and Device Shadow provided by AWS IoT.
Launched a couple of them along with AWS IoT last year, and now we have 7.
You can use this as a bridge to the cloud, or to create a local distributed system.
Does Greengrass solve a durable problem, or can everything eventually run in the cloud?
Yes, Greengrass solves a durable problem for three structural reasons: The first is economics: the cost of bandwidth is not falling as fast as the cost of storage and compute. Greengrass provides tools for locally aggregating and filtering data, making it easy to act on lower-value data locally, and upload high value data and aggregated data to the cloud for analytics and storage. The second set of durable problems is latency and last-mile connectivity. Latency to the cloud can be unacceptable for scenarios that involve timely automated decision making (crash avoidance, medical alerts), or physically remote operating environments (mining sites, aircraft in-flight) especially in conjunction with wide-area wireless networks (such as cellular). So some decision-making must continue to be executed locally on the device. High-value and safety-critical processes must also continue working when the internet connection is down. The third set of durable problems is compliance and privacy. For legal or compliance reasons, and concerns around privacy, some industries prefer to store or duplicate some data locally. For example, hospitals may be required to keep all records locally, even if they are also duplicated in the cloud. Some governments impose data sovereignty restrictions on where data may be stored.