- [Neel] Welcome to AWS IoT Greengrass 2.0 demo. So as you can see, I'm on AWS IoT Greengrass console. Let me give you a quick refresher of how it works. So if you remember, Greengrass is an edge software and a cloud service. Right, so on the edge side, Greengrass provides you the software abstraction layer on top of which you can bring your own software, or you can leverage some of the software that's already built for you by us at AWS. So, you can deploy your Lambda function, Docker container, native processes, and way more. And then, that can talk to the Greengrass cloud services, and also to different other AWS services for data exchange. Cool. So with that background, what are the core components of Greengrass? The first one is core devices. Right, so core device essentially runs the Greengrass core software. It's an edge device. It can be an intelligent gateway. This is where all the magic is happening on the edge, right, whether it is offline or it's online. So now, you can see that I have created a Greengrass demo core device. And what is going to happen is, on this core device, it will be deploying different software components, or there could be different peripheral devices, like your sensors and actuators on the factory itself, that can talk as a client to the Greengrass gateway over MQTT. So now, if I click on this core, you will see there are different software components that is actually running on the core, some of them are custom built by me. For example, the Publisher one, the Aggregator one, the Subscriber one, those are just Python scripts, which are essentially running as a component, versus the other components, like the Greengrass CLI or the Greengrass Nucleus, the Stream Manager, which is actually developed as a public component, and anyone can use that. So, let's click on the Nucleus, which is essentially the heart of Greengrass, and you need to have at least this component to run any Greengrass enabled devices. And, you can see that it has different kinds of configurations. It has the platform details of running on Linux, and it has some bootstrapping commands, as well, like what it needs to do when it comes up. Awesome. So now, let's say you want to create your own component, right? You have the public components that I was talking to you about that AWS has built for you. There are 40 of those today, starting from integration with SNS, or collecting OPC-UA tags, or connecting to a Modbus or connecting to Kinesis Firehose, or the different kind of machine learning classification-inferencing components that you can deploy, versus if you want to create your own based on programming language that your organization has standardized on. You click on Create component. You have to create a recipe. Yes, it's a recipe. It's like a Chef recipe, but it's more of a configuration file, where you can specify what does the platform looks like. What is, like, the commands that needs to run, and where those commands or the artifacts-- which is essentially your script, like the hello_world.py--resides. Maybe it's in an S3 bucket, or maybe it's in a GitHub, or somewhere else. And once you do that, you will click on Create component, and the component will be created for you. You can also import Lambda function, which is essentially a serverless function on AWS. And if you have already been using Lambda on Greengrass Version 1, and you want to bring those to Version 2, you can use Lambda, as well. Okay, so coming back to our homepage, and again, we are focusing on Version 2.0. So, you might see a Classic V1 version, you can just happily ignore, because V2 is the latest and greatest. So now, we have understood our core devices and components. Let's also look into deployments. That means you can have multiple deployments. You can build a CI/CD pipeline from the cloud to the edge. This had been a challenge in the past, and even today, where you have all this fleet of devices on the field, and then you do not really have a good mechanism to update them over the air throughout its life cycle. Like, OTA updates has been a pain-- and is a pain--for a lot of businesses. So, Greengrass makes it super easy for you, as you can build a continuous integration/continuous deployment cycle using Greengrass service on the cloud, which does a lot of heavy lifting on behalf of you. And not only does it deploy, it helps you to revise deployments. It helps you to roll out the deployment. So, let's take a look. Let me go back to the Core devices. And within each core devices, you can also see a Deployment tab, and you can see that the last deployment was completed for Greengrass Demo 1. This is how the deployment looks. Now, one other trick or the secret that I will tell you, is the deployment essentially uses AWS IoT jobs under the hood, which is part of the IoT Device Management family of capabilities, and those job capabilities, essentially uses job documents. That means in the job document, it's a JSON document, you specify like, hey, these are my three components that I want to deploy, and these are my policy, what needs to happen. If there is a problem, do I roll back or do I do something else? What is my timeout? You specify everything on the job documents. And then, job targets is essentially the core device that you are deploying the update, or it could be like a fleet of devices. It could be ten thousands of those devices that you want to deploy to. So, that is like the magic sauce for the OTA, if I may. So now, you have the deployment that is running, you want to probably revise it. So if you click on Revise here, it will ask you to revise the deployment. You can do Next. You can choose all your public components that you can see here. You can have your own component as well, custom components, which will show up here, you click Next. You'll see all of these different components. You can even configure these components with custom inputs. So, you can say your configuration should have a different set of values than what's in the default, right? So, you have a lot of control, along with the convenience. And then, you click Next. It will give you all these options, to like, what to do for the rollout. You do not want to roll out millions of devices together, right? You want to reduce your blast radius, in case of challenges. So you can say, you want to roll out at a constant rate, maybe thousand devices at a time, or you can do an exponential rate, that means only when thousand devices per minute is successful, you increase that by a certain factor, essentially. So, you have all this convenience at your fingertips. Then, you can specify the timeouts. For example, if my device is not connecting for next 7 days or 14 days, I probably do not want to send this batch out because I will already have another batch. which is built and ready to deploy, so it will automatically time out for you. You can cancel, if you have found a certain kind of failure, and based on this failure, you can have a cancel configuration. And finally, you can have different kinds of deployment policies. So, you can specify what are the response timeout, or you need to notify other components that the rollout has failed. You can choose whether you should roll back, or you should not roll back, based on the major or minor version you are pushing over the air. So for now, I'll just Cancel this revising deployment because it's doing healthy, and I have nothing else to deploy at this point of time. So that's, in a nutshell, what Greengrass is, and you will learn a lot more as you get your hands on with the service in the exercises. Thanks for staying with me. Good luck.
