I’ve written a few different blog posts on Project Flogo , so I will not go into detail on what Flogo is, but please feel free to read one (or all) of my earlier posts. However, I do want to emphasize one key point: Flogo is an ultra-lightweight open source process engine specifically designed to target areas where speed, performance, and scalability are required. This includes, but is not limited to, IoT edge gateway devices, as well as IoT edge devices themselves. The lightweight, performant nature of Flogo also enables other key use cases, such as:

• Cloud-native microservice development
• Serverless compute

We’ll cover these scenarios in subsequent blog posts.

In this blog post, I will spend some time analyzing why Flogo is well suited for IoT-focused use cases and why retrofitting existing technologies just won’t work when developing edge applications.

Edge computing

If the past is any indication of where we’re heading, then it has shown that we’re essentially in a technology loop, well, kind of. Let me explain. We go from centralized to decentralized and back again—smart computers to dumb terminals back to smart computers, moving to the cloud for seemingly unbounded compute resources, and we’ve begun the trend toward edge-based computing. There has been plenty of analysis and publications around this topic, including by Peter Levine, General Partner at a16z, on how cloud computing is coming to end. In a nutshell, he outlines how cloud-based computing will be displaced by decentralized computing.

Now, we do have a number of considerations before we jump in head first and it is also worth noting, again, that retrofitting technology is not the answer! We’re not talking about decentralized desktops or laptops; we’re talking about tiny edge devices with a vastly different set of compute resources.

Considerations

Limited compute resources
While edge technology is becoming more powerful from a compute perspective, still the resources available for application execution are limited both in terms of RAM and CPU. Leveraging a technology that has been retrofitted into such an environment is either not possible, due to the compute requirements, or is limiting when embracing edge-native microservices (several, smaller units of work). If you attempt to deploy 10 apps, all requiring 1GB of RAM, it is very likely that you will not be successful, whereas with Flogo, each application footprint is roughly 10-15MB in size (depending on what you’re doing).

Intermittent and expensive network connectivity
This one is simple: If you’ve deployed an edge device to middle of nowhere and you rely on cloud resources to make all decisions, you’re likely left with a solution that doesn’t work or works only part of the time. You need to rely on the edge to provide some level of autonomy.

Flogo to the rescue

Flogo has been built and designed from the ground up with edge-native principals in mind. We’re not “edge-washing” cloud-native technologies and shoehorning their use into an edge-native world as others may be doing. This strategy will typically fail, just as “cloud-washing” had failed in the past.

Embracing limited compute resources
The traditional Java JVM and Node.js, while great, simply are not the best options for devices with limited compute resources. Sure, if your IoT edge gateway is as powerful as my MacBook Pro, then leveraging any technology to accommodate your needs is probably acceptable, however this isn’t usually the case. Typically, technologies are built with the intent that compute resources will become more abundantly available, and while this holds true for the cloud and will hold true for the edge (at some point), we still need to consider the limited resources available.

Flogo was built with this limitation in mind and solves the problem in a few ways:

• Only the required dependencies are built into the application binary. Every binary is purpose-built for your application.
• A single application binary, statically linked at compile time, enables zero OS dependencies. No need to pre-install a run-time environment with hundreds of dependencies you have no intention of using
• By leveraging Golang, native binaries are built, giving improved performance versus interpreted technologies and no need for a framework pre-installed on the target device!

Finally, one last point. Flogo Edge Apps was introduced in June of this year and supports microcontroller deployments. Put another way, a Flogo application can be constructed and compiled down to C to flash a microcontroller. We’ve built a contribution model that enables developers in the open source community to add additional device-specific activities and triggers and even platforms. For more information, refer to my earlier blog post on Flogo Edge Apps.

Restrictive network connectivity? No problem
This particular limitation is simply a byproduct of the edge and quite honestly, the cumulative features and performance of Flogo lends itself to tackle this problem.

Typically IIoT (industrial) solutions are deployed into environments that may not be well connected (think an oil field, etc). In this case, devices need a bit of autonomy. Embracing the concept of edge-microservices allows us to build a number of specific applications and deploy those to these edge devices. Whereby each application has the capability of performing some action at the edge, and only forwarding to cloud-based IoT solutions when required. This saves money and improves efficiency.

Externalizing state and debugging
Sometimes, state is a required component, and embracing stateless, edge-native microservices is not always possible. Rather than rolling your own edge-native state management service, the Flogo team took the liberty of building such a service. The Flogo State Service is capable of externalizing application state but also enables remote debugging capabilities. For example, an admin can interrogate the state service without the potential of harming the runtime application engine.

Updating applications
Flogo includes yet another handy service. This is the Flow Service and can be used to push Flow updates to a running application. As we’re talking edge, you typically can’t perform the standard cloud-native method of updates where you have a number of options (rolling updates, blue/green deployments models, etc.). In the case of edge, you typically have only one service providing capabilities.

We’ve discussed the fact that Flogo was built from the ground up with edge-native design principles in mind. We’ve also discussed a number of edge-native benefits Flogo can bring to the table. However, the benefits and features we discussed above can be leveraged in a much wider set of use cases. We’ll continue to explore all the ways that Flogo, the ultra-lightweight open source process engine, can benefit the edge and beyond. Stay tuned! Discover more about Project Flogo here.

Let’s block ads! (Why?)

The TIBCO Blog