Blog Posts Process Management

Project Flogo: Humble Beginnings

Blog: The Tibco Blog

What is Project Flogo?

Last year, Project Flogo—designed specifically as an application integration framework for IoT—was introduced to the world as an Open Source Software (OSS) project. The idea is simple: You write a lightweight app via Flogo WebUI (or your favorite IDE), then build and push the single executable to an edge device. No other system dependencies involved.

But while Flogo was designed for IoT, the same lightweight and performant characteristics also benefit cloud-based microservice deployment models. Its robust extension framework supports use cases like service discovery, circuit breaker, and other cloud-native microservice patterns―and even ‘nanoservices’ for serverless computing.

Over the next few months I’ll be sharing Project Flogo updates, revisiting some of its core use cases, and introducing new topics and use cases that its suited for. But first, the origins of Flogo:

Long, long ago…

The world was in chaos. Not a single, lightweight integration framework to be found. There were plenty of heavyweight solutions built on top of Java and Node.js, but nothing ideally suited for resource restrictive environments like edge computing… OK it was not that long ago, roughly a year, something like 10 in computer years.

The point: fog/edge computing is on the rise. There are more and more solutions moving from public or private cloud environments to the edge for a number of reasons, such as but not limited to:

—The desire for additional logic, such as on-device aggregation and filtering to enable more intelligence, regardless of network availability
—The desire to reduce network dependencies for all intelligent operations on cloud back-ends

Edge computing is different than the cloud. There are hundreds, thousands, even millions of devices deployed across several environments. Some devices are well connected, such as many commercial IoT/edge offerings; However, others are not so well connected, and commonly, those are in industrial settings (an oil field, for example).

As an enterprise deployment model, you hear various fog/edge computing platforms referred to as animals. Odd, right? On-premises is “the pet,” cloud is “a herd of cattle,” and edge devices are “a swarm of bees.” Overly simplistic, but a good way to think of it.

Now imagine you have a swarm of bees in a field, hundreds of miles away from any reliable network (or internet) connection. You’re forced to rely on satellite or mobile network connectivity. This can be latent and costly, especially if you’re streaming mass amounts of data.

In such a scenario, it becomes ideal to move integration and processing logic to the edge, either via a centralized IoT gateway aggregating the data from hundreds or thousands of devices, or perhaps, deploy logic to the device/microcontroller itself. This device deployment model enables the “bees” to be more self-sufficient and reduces voluminous and costly traffic.

The problem with cloud deployments

Before you close your browser tab and curse my name, let me qualify the section title. There really are no problems with the cloud or various cloud deployment models; However, we’ve taken for granted their seemingly limitless computing platform resources—and for edge and IoT device microservices, resources are much more restrictive. You can’t simply add another VM to your platform cluster (or EC2 instance) and continue scaling out your larger footprint apps.

For edge computing, two principles apply:

Performance is key. Applications need to be optimized for the resource restrictive environments they run in.
Lightweight (double-digitl MBs, not GBs!) is needed. A single, self-contained executable runs your application without third-party OS dependencies. (No JARs or JVM versions need apply.)

These principles are also driving microservice app dev when targeting cloud deployments. After all, just because you might have (seemingly) limitless compute resources, there’s no reason to consume more than you need!

Imagine deploying a 15MB Docker image of your app! We’re talking incredibly fast deployments where (truly) failing fast and restarting containers is a much quicker affair. Another important point to highlight is that increased speed and performance does not mean you need to give up functionality, quite the contrary with Flogo, as previously noted.

(Re)Introducing Project Flogo

Enough level setting! Let me introduce you to Flynn, the Project Flogo mascot! Flynn is a hummingbird, he is lightweight (about 2.5 grams, to be exact), fast, and incredibly agile (in fact, one of the few species that can fly backwards) and I think he is rather cool, as well!

Ideally suited use cases

As we’ve already established, Flogo began as an IoT integration engine and it will continue to evolve around IoT. We’ll also start to see more and more solutions built specifically for deployment to microcontrollers. In this scenario, we’re talking about app package sizes in the KBs not MBs. We’ll also see additional functionality around machine learning, all with the the following principles front and center:

I also want to bring attention to one very important point: This is not something that’s being done in a closet, this is something we’re building together with people just like YOU. Flogo is an OSS project and will continue to evolve with the community. Contribute, participate and get involved!

WE NEED YOU! figure pointing with finger to you

Some additional use cases, as discussed above include:

—IoT, gateway and microcontroller deployment
—Microservices via containerized platforms (AWS ECS, Kubernetes, and other PaaS)
—FaaS (Function as a Service – Lambda and others)

We’ve discussed a lot of different concepts, but the primary takeaway should be that Flogo, while designed for IoT, is also suited for a number of other microservice dev tasks and deployment models.  Finally, my opinion and thoughts aren’t the only ones that matter. Let us know what you think by commenting below, trolling me on social media, contributing to the repo, etc.

Try Flogo for yourself here.

Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples