zok3102

Good to know that Pulsar is on your roadmap. Also, kudos to see user-land tooling around a common painpoint for teams doing any event processing at scale.

Reminds me of that time when database vendors were overreaching to be message queues/brokers - OracleAQ, MSMQ, etc.

True.. if your last interaction with TIBCO was c. 2005. Back then consistency issues were a real challenge with VMs, “ESB” was a real software category with transactional messaging as a pattern (I make it a practice to not judge customer preference on how they use our tools)

Today you will find even our traditional brokered messaging products like EMS lifted and shifted on AWS/Azure infra.

OTOH, if you are building new apps - you‘re likely to deploy TIBCO’s integration or stream apps / pipelines using Flogo/Pulsar/Kafka on k8s-lambda-gcr or on a fully managed service on cloud.tibco.com.

(Source / Disclaimer: I do product stuff over at TIBCO Software. Happy to chat if there are further qns: rkozhikk<remove-this-at>tibco<dot>com)

IMO, there is no “TIBCO-like approach” to application integration c. 2020 any more than there is say an Oracle or AWS or Google approach to databases. It’s multi-paradigm, multi-usecase and polyglot. TIBCO as a vendor supports approaches and patterns ranging from event-driven functions to data streams and stateful orchestration to stateless mediation to choreography. The “runtimes” are built on anything from Golang, Python & Node to Java, Scala & .NET.

What you‘re referring to sounds like the legacy version of BusinessWorks 5.x that was launched back in 2001. The current generation of BusinessWorks 6.x provides Eclipse-based tooling just like closest alternatives like Talend, Mule, Fuse, etc. and deploys to 18+ PaaSes (k8s, swarm, GKE, AKS, etc.) or its own managed iPaaS aka TIBCO Cloud Integration. It’s aimed at Enterprise Integration specialists at a Global 2000 or F500.

If you‘re an app developer at a large bank/telco/retailer/airline building integration logic or stream processing or event-driven data pipelines, you‘re likely to use Project Flogo (flogo.io) It’s 3-clause BSD FLOSS and has commercial support and optionally commercial extensions available. Oh and you’re likely going to use Flogo apps with Apache Pulsar or Apache Kafka messaging. Both Pulsar and Kafka are available as commercially supported software from TIBCO (Rendezvous or EMS are our traditional proprietary messaging products). Flogo apps can deploy to TIBCO Cloud, dozen+ flavors of k8s, AWS Lambda, Google Cloud Run or as a binary on an edge device.

(Disclaimer: Product at TIBCO. Used to work on BW 6.0 back when the only PaaS was good ol’ Heroku)

AFAICS this still requires a Java broker. Only the client is in go.

I work on product at TIBCO. Mashery plays in the broader API Management space, but we haven’t traditionally targeted banking/govt/heavily-regulated verticals. From Day 0, Mashery has been a multi-tenant SaaS with locally deployable federated gateway and many buyers in these verticals get jittery about SaaS, multi-tenancy, etc.

However, that SaaS-led model is changing fast and we’d love to hear about your pain with single-tenant, on-prem solutions available today. Would you be open to a no-strings-attached chat? mashery-pm<at>tibco<dot>com

We havent seen a whole lot of real world demand yet, but something that could likely end as a trigger or activity in Flogo.

lol. This goes up on my review deck with execs. But yes, a (new) TIBCO & a new TIBCO project :)

(Disclaimer: TIBCO PM working on Project Flogo)

Fair point, we just chose a common Java REST or microservices fraemwork. Is there any particular Java IoT Integration framework you would like to compare or contrast Flogo with? Some OSGI framework like Kura perhaps?

Flogo's problem domain is broadly speaking, IoT integration. Using Flogo you can build integration apps/services/microservices that are lightweight enough to run dozens of these edge apps on IoT edge gateways & devices. Specifically, these edge integration services can be built as flows & triggers (yes, a visual flow modeler is coming soon!). Hope that clarifies - but we'll take your feedback to improve the docs.

(Disclaimer: I'm a TIBCO PM working on Project Flogo)

Except the daemon part, I think you got the gist of it right - thank you!

The one thing I would like to add is that flogo-lib is a full-fledged process engine which means you can craft (or soon enough visually model!) rather expressive flow definitions unlike a request-reply pipeline or HTTP middleware.

(Disclaimer: I'm a PM working on Project Flogo at TIBCO)

12 hours off HN & your project gets posted! Phew :)

I'm the PM on Project Flogo and welcome your questions + feedback. As some have noted on the interweb, it's a pretty big step for an enterprise sw vendor like us, to open up a core piece of our technology, so your constructive feedback gets a lot of attention around here and shapes it!

Couple of quick clarifications:

- All the repos (CLI, Library, Contrib and Services) except the top-level repo are BSD-licensed. The top-level repo is docs+samples, so we have put it under a free-beer license. However, we are in principle open to putting it out under BSD or a CC license as well.

- At its core, Flogo is a process engine that executes flow definitions consisting of activities. These flows are triggered by events happening in the real world. Triggers could be HTTP, MQTT, CoAP, etc. & activities could be AWS IoT, Log, HTTP, Send MQTT, etc. There is a fairly simple SDK to build your own activity or trigger and bring those along.

- We are actively working on a Web UI to model the flows instead of handcrafting the json DSLs or writing code.

- The runtime footprint comparison is for apps with equivalent functionality (Think a flow like MQTT Trigger -> Log Message -> HTTP Request -> Send MQTT). We just chose 2 common frameworks to showcase the difference in runtime footprint. We love Node & Java - it's just that for Edge integration microservices we chose Golang - and the runtime footprint was a key decision factor among others.