The rise of edge computing marks the beginning of the next wave for enterprise Internet of Things platforms. Major public cloud providers — AWS, Google, and Microsoft — have extended their IoT platforms to the edge. For customers, edge computing is an extension of the public cloud. They get micro versions of cloud services including device management, machine-to-machine communication, authentication & authorization along with core compute services that are often delivered through containers and functions.
AWS Greengrass, Azure IoT Edge, and Google Cloud IoT Edge extend the IoT platform services to the edge. But these services are tightly coupled with their respective cloud platform services. There is a need for cloud-agnostic, platform-agnostic edge computing platforms that customers can deploy on-prem.
Project Flogo from TIBCO is a lightweight edge computing platform that is not tied to any specific public cloud platform. It’s an open source project developed with portability in mind. Since it is primarily written in Golang, the runtime can be deployed across a variety of environments. Project Flogo can run in a data center dominated by x86 servers running Kubernetes or a miniature Raspberry Pi Zero based on an ARM CORTEX processor.
Unlike other edge computing platforms, Project Flogo enjoys an extremely compact footprint. It is up to 20 to 50 times lighter than Node.js and Java Dropwizard runtimes. The binary required to execute Project Flogo applications is only 3.3Mb.
TIBCO built Project Flogo based on event-driven and serverless computing models. The platform is seamlessly integrated with mainstream serverless platforms such as AWS Lambda.
A Developer’s View of Project Flogo
Project Flogo is a no-code platform built on the lines of Node-Red. Developers familiar with Node-Red will be able to instantly relate to the tool. But Flogo is fundamentally different from Node-Red in terms of execution environment and runtime. To run Node-Red nodes, the deployment platform should have Node-Red installed. With Flogo, there are absolutely no expectations from the target environment. The binary emitted by Flogo can run like a native x86 or ARM executable with no dependencies whatsoever.
When building the apps on Flogo, developers either deal with the Web UI or CLI. Flogo apps are modeled as flows, which are declarations written in Domain Specific Language (DSL) based on JSON.
Instead of parsing and executing the flows dynamically at run-time, Flogo apps embed the flows within the binaries which are stand-alone. While developers need to compile the binary each time they change the flow, the advantage lies in the compact size of the resulting binary. The compiled binary is stand-alone, portable, and a self-contained entity with no dependencies. This is the biggest benefit of Project Flogo. These lightweight binaries can be easily pushed to the target environments through modern CI/CD tools.
Once a flow is developed and deployed, it can be invoked through a variety of triggers. Triggers in Flogo are wired to inbound and outbound channels such as REST, MQTT, CoAP, Kafka Topics, Cron Jobs, or even parameters sent directly via the CLI.
When a flow is executed, it starts listening for the triggers defined in the declaration. For example, an MQTT trigger will subscribe to an existing topic and waits for the publishers to send a message. Similarly, a REST trigger will synchronously wait on a specific port for an HTTP request to arrive.
So, what happens when a trigger is fired within a flow? A series of actions will take place either in a sequence or in a parallelized fashion. These actions are available as activities in Flogo. Activities do the heavy-lifting by processing the inbound messages came via triggers. For example, an activity might invoke Twilio API to send out a text message. Another activity may load a TensorFlow model to find an anomaly in the sensor telemetry. Project Flogo comes with over a dozen predefined activities that can be instantly included in the flows. Developers can also create custom activities in Golang and wire them with their flows.
Since Project Flogo is an event-driven platform, we can invoke the flows in response to external events. An AWS Lambda activity can be used to invoke existing Lambda functions.
But the serverless capabilities of Project Flogo go beyond the invocation of functions. The flows can target AWS Lambda. With AWS Lambda supporting Golang natively, Project Flogo flows can be packaged and deployed as Lambda functions. The combination of Flogo CLI and AWS CLI can be used to automate the deployment of functions.
Getting Started with Project Flogo
Project Flogo can be accessed either through a web interface or command line. The easiest way to get started is to pull the Docker image of Project Flogo.
Below are the simple steps to access the Flogo web UI.
$ docker run -it -p 3303:3303 flogo/flogo-docker:latest eula-accept
Wait for the image to get pulled and initialization to complete. The terminal will show the below output indicating that the platform is ready.
We are now ready to access the web UI. Hitting http://localhost:3303 will show the console:
Feel free to explore the sample application that comes with a few flows.
You can also install Flogo CLI through three simple steps.
1) Download Golang from https://golang.org and follow the instructions to configure the development environment. Make sure that GOPATH and GOBIN environment variables are correctly set.
2) Install Golang Dep tool to manage the dependency. Run the below command to configure the tool.
$ curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh
3) Finally, install Flogo CLI with the below command:
$ go get -u github.com/TIBCOSoftware/flogo-cli/...
If everything is installed and configured correctly, Flogo CLI should work.
In an upcoming article, I will walk you through steps in building and deploying an end-to-end Flogo application that can run on an edge computing device.
The New Stack is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.