Deployments
Deployments are the core of Ferry’s solution. Ferry carries out Deployments of Components to Node Groups via Ferry’s native integrations with your AWS or Azure account. If you link an AWS account to your Workspace, Ferry will deploy your software applications using AWS Greengrass within your own AWS account. And similarly, if you link a Microsoft Azure account to your Workspace, Ferry will deploy applications via Azure IoT Edge within your own Azure account.
This means that all times, you have full control & visibility within your own cloud provider account over your devices, applications & deployments.
Ferry’s purpose is to make deployments of applications from the cloud-to-device seamless, fast & secure - so you can spend more time building your application than on infrastructure. In this section, we cover:
How do Ferry Deployments work?
Smart Deployments: editing deployments & conflict resolution
How do Ferry Deployments work?
A Deployment in Ferry takes a set of published Component Versions and deploys them to a set of Node Groups (termed ‘targets’).
A Deployment can:
Have multiple Components assigned to a single Deployment
Have multiple Node Groups as targets for a given Deployment
This flexibility allows users to be able to organise their Deployments according to their organization’s needs and specific use cases.
For example, a manufacturer with two separate production lines might have data extraction sensors linked to industrial machines that are streaming data to the company’s cloud account (via Ferry!). In this case, the manufacturer might opt to have different data extraction scripts running on each production lines’ sensors but a common monitoring & logging framework that is to be used for both production lines. With Ferry, the manufacturer can easily set-up a deployment configuration for this exact use case:
If the manufacturer wants to update the monitoring component to a new version, they can easily update both Deployments with the new component version. This will update the monitoring component for both node groups.
Ferry provides a simple UI for each deployment. Within it, a user can add, edit and remove Components and Node Groups (i.e. targets) for the deployment. Selecting the “Deploy” button at the top initiates the deployment through the user’s linked Cloud Account.
How does a Node registered with Ferry (via its Node Group) know if there’s a new Deployment for it?
Nodes registered via Ferry will have either AWS Greengrass or Azure IoT Edge installed on them as their runtime depending on the Cloud Account you have linked to the Workspace. Nodes will also have security certificates provisioned on them for secure communication & authentication with your cloud account. In both cases, the Node’s runtime will periodically poll the relevant cloud account’s IoT service to check if there’s a new deployment relevant for that Node. If a new deployment has been initiated to a Node Group, the Nodes within that Node Group will retrieve the latest software application and attempt to run it.
Smart Deployments: editing deployments & conflict resolution
At times, users will want to edit deployments to remove or add software applications (Components) that are already live on a Node. Ferry abstracts the difficulties of managing deployments within AWS or Azure through our Smart Deployment features.
For example if we take AWS, without Ferry, users would need to:
Go into their cloud account, find out which components are running on their Nodes, manually adjust them, and create a new deployment.
Manually ensure that they don’t accidentally uninstall components that are already live on a Node.
Manually track whether there are two differing versions of the same component attempting to be deployed on the same Node.
Ferry automates away & proactively prevents these difficulties from occurring. With Ferry, users can use our no-code deployment tools to:
Add Component Versions (or new Components) to existing Deployments that automatically update what is running on the target Node Groups.
Edit Deployments to quickly & safely remove Components from running on Node Groups.
Ensure that two different versions of the same Component can never be deployed to a Node Group (conflict resolution).
(Azure only) Update the runtime configuration of Components (such as messaging routing, startup order, restart policies etc)
Ferry ensures that Nodes can only ever have one version of a Component running on it at a time. When you try to add a Component Version to a Deployment, we proactively calculate whether there would be a conflict to any affected Node Groups (including via other active Deployments to those Node Groups!). If there is a conflict we block the Deployment and guide the user on where the conflicts lie, and how to resolve them.
To illustrate this, take the example below:
In the above deployment flow, there are no conflicts. Node Group 1 runs Component A Version 1 (via Deployment 1) and Component B Version 1 (via Deployment 2).
Say that the user now creates a second version of Component A (Component A Version 2), and now tries to add that version to Deployment 2:
This would create a conflict where Node Group 1 would have two different versions of Component A (via two different Deployments) attempting to run on the Node Group.
With Smart Deployment, Ferry detects that a conflict would occur, and would prevent the user from adding Component A Version 2 to Deployment 2 to avoid this (completely proactively)!