Hi!! It’s really great to see so many BBQ enthusiasts in the same room.
In the next 30 minutes will we talk about how to get great BBQ by using tech. We will touch topics like BBQ, IoT, BBQ, Serverless and eventdriven architecture, and did I say BBQ?
Quick poll. How may of you cook BBQ on a regular basis?
You that didn’t rise your hand, today you will fall in love!
This is COM203 and my name is Jimmy and I will be you pitmaster today!
So the agenda for the day is:
Background to the project
Overview of the architecture and how it has evolved over time
Cloud deep dive and – talk about changes I made and the benefits of that
Summary – and final thoughts
Before we dive into everything, who am I?
As I said, my name is Jimmy Dahlqvist!!
IoT, Serverless, BBQ fantast!
Serverless since 2016 – lambda Old
Day Job – Head of sigma – (cheer) collegues in audience
AWS Ambassador + Community Builder (cheer ??)
Let’s jump into the background so we all have the same context.
What is ?
Low & Slow – Vs hot and fast I normally target ~120c (250f) – Reason for doing that is….. Tenderize, render the fat, break down connecting tissue.
Styles – Us (varies by state, Texas, Tenesee, Nort caroline, New york…), Jamaica, Austrailia, UK – Sweden most US styles
Not cooking – Art! But doesn’t mean we can’t use Tech…..
Audience Poll!!
Kamado ?
UDS?
Electric ?
Offset ?
My offset smoker – Isn’t she a beuti!
How does an offset work + IoT Device – ANIMATION
IoT Device – Watch fire, help from technology, What does it do!!
Comment to content editor: The image is my own, taken by me.
This is an overview of the IoT Device and the food probes I use, standard 2.5mm thermistor probes.
What is a Thermistor?
Background and context done
Let’s look at the components, and architecture
Two parts – IoT device + cloud
Example services for both
CLICK!!!
Let us take a closer look at the IoT Device
Two parts – HW + SW
HW:
Rasp-Pi 4
2.5mm food probes – thermistor!
MCP3008 (10bit 8 channel)– AD converter – read voltage
SW:
AWS IoT Greengrass 2.0 – Core
Custom component – math voltage to temp
Initialy simple Python app updated over SSH
Problems – Logs and Hard to update
Done – Looked at IoT device
CLICK
Let’s talk about Cloud – where we will spend most of our time
First version of cloud looked like this…
Happy little man to the left I guess is me…
Device data -> IoT Core
IoT Core -> Rules -> Storage + Athena + Dynamo
IoT Core -> Rules -> Several SF business logic (thresholds, trends…)
API GW RESTful…
IoT rules as router –> on mqtt –> not on payload –> messages discarded in business logic
Each event –> one OBJECT in s3 –> Glue/Athena not optimized for that
Data written directly to storage (Storage First is good but…) –> Format dictated by the device –> need transform
Hard to extend –> Several services did same thing –> notification –> or needed to implement API
So I had a couple of areas that I wanted to improve.
I wanted to add the possibility to do a proper ETL and data transformation. So it would be easy to change how data is stored and presented in the cloud withour having to change the device,
Introduce a event driven architecture with EventBridge as the event router instead of relying to heavily on rules in IoT core. The rules are great but at this point they didn’t really fulfill what I wanted to accomplish.
Lastly decouple the services. Break the mini-monolith that I almost managed to build in the first iteration.
All changes was to create a more flexible system that was easy to extend and manage.
Let’s start by looking at the changes made for the IoT device
With the Initial problems I decided to test out Greengrass.
Interact with AWS Services – s3 config etc
AWS provided components – Log Manager
Build SW as components - Easy to push and publish new versions
AWS Lambda support
Now we move over to the cloud part what was done there
Second iteration several improvments.
IoT Core no longer primary message router -> EventBridge introduced -> EventDriven architecture -° Rules / targets / subscription
Business Logic -> Microservice pattern – with clear responsibility -> Communicating over EB and API
Transformation service -> EB Transform / augemnt
EB – PayLoad filtering
Let’s take a closer look at some parts of the architecture…..
And start with the ingress part……
CLICK! -> Animate
Favorite pattern – Storage First
Create reliable way to capture data – prevent data loss
Use managed services
Very powerful when incoming data doesn’t require instant transformation
The next part we should look at is the data augmentation
CLICK
This part became very important in the new design…
CLICK
….. It allowed me to decouple cloud development from device development
Data transform pattern
Data augmentation -> Additional information fetched from DynamoDB.
Data is transformed to an internal format -> Decouple from the IoT device
Almost no code. StepFunctions integration to other services
One of the most important services are the detection service
CLICK
This is where all the BBQ magic happens…..
CLICK
Threshold breach
Trends
Stall – Happens around 70c (160f). What is it?
Next part to look at is actually the entire system.
CLICK!!
Everything is built on a serverless and event-driven approach.
Reason You build an serverless and eventdriven architecture.
Loosely coupled services
Scale and fail independently
Cost effective – pay for what you use
Extensibility – easy and fast to extend
HA – built in
So have technology help me to become a better pitmaster and to get some great BBQ?
Some may say it’s cheating but why not use tech to help?
…. I let the result speak for it self!
So to summarize the last 30 minutes.
Building an IoT system
Serverless and event-driven
Get great BBQ with help of technology
And with that I say!
CLICK!!
Thank you for your attention! Thank you for listening! I hope you all get to have a continued great re:Invent!!
And PLEAS PLEASE fill in the session survey! It helps Amazon improve and it helps me improve as speaker!!
There is my twitter handle, follow me, connect on linked in!!
Once again! Thank you!!!!