In today’s world everyone is building apps, most times those apps are event-driven and react to what happens around them. How do you take those apps to, let’s say, a Kubernetes cluster, or let them communicate between cloud and on-premises, and how can developers and non-developers work together using the same tools? Let’s break down the title a bit…
Does it have to be Open Source #
Let’s be fair, Open Source Software (OSS) powers nearly all of our modern society and economy. It’s not just making the source code of an application or framework available on GitHub, it’s a movement that is driving the innovation in our daily lives!
In fact, looking at a few statistics drives this point home even further:
- 91% of developers use the same OSS tools for work and personal projects
- 98% of developers use OSS tools at work
And these numbers come from a relatively old report from Open Source For U. Just think about all the technologies you’re using on a daily basis that are built as Open Source, like Visual Studio Code, Golang, PostgreSQL, React, Ruby, Kafka, or Flogo
So, does it have to be Open Source? Yes, I think it does!
What is Event-Driven #
The dictionary describes an event as “a thing that happens, especially one of importance.” So, events are rather easy to describe because an event is just that… The thing that will differ from event to event is how you process it. Do you process them in a stream, or one at a time, or something different? The technology you choose should help you with all of those.
Stack #
When you’re building a microservice, do you want to build a few apps that work together? A streaming app that aggregates the events, filters them and sends them off to a separate Rules app to validate them and send them off to a separate Integration app to handle logging, writing to databases and whatnot? Especially in a microservice world, you want to use streams, rules, and integration in a single app to limit overhead and stay within the bounded context of your service.
Devs and non-devs #
I’ll start with a confession… I love writing code! I prefer an editor like Visual Studio Code over a graphical design-time (though I use both in my job), but I realize that everyone has their own preference. There will be developers that enjoy a graphical design-time, there will be developers that rather write apps using a DSL, and there are developers that want to write code. Ideally, the tech you use helps all those developers.
Project Flogo #
At TIBCO’s user conference last week, we’ve shown a ton of new things surrounding Project Flogo. Let’s unpack the title and see how Flogo stacks up (pun intended).
- Open Source: Yes, most certainly. Project Flogo has a BSD-3 license, which is one of the most permissive licenses possible (you’d never have to tell us you’re using it, though I’d prefer it if you did 😄)
- Stack: Most definitely, yes. At TIBCO NOW, we demoed a package that used streaming events and contextual rules to determine where it was and if it hadn’t moved far enough along. These two new capabilities for Project Flogo have been released as Open Source as well, complementing the existing integration flows.
- Devs and non-devs: I think so! Project Flogo has a cool Web UI, a great JSON DSL, and a newly announced Golang API.
Wrapping up #
I think Flogo is an amazing stack to help you build event-driven apps, I’d love to know your thoughts on it! Let me know by dropping me a note. If you have any thoughts on how to make this better, just create a GitHub issue.
Cover image by Pixabay
