Checkout flogo.io - specifically Flogo Flow action https://github.com/project-flogo/flow for orchestration. You can use a Web UI, Golang SDK or a hand-edit the JSON DSL to build your orchestration flows. Deploy as binaries/containers/functions or on a cloud service like TIBCO Cloud Integration.
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.
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)
You may also want to look at Project Flogo (flogo.io) - in particular, the Flogo Flow action. It's a process engine in Golang that can be used to implement service orchestration, event-driven choreography integration patterns.
Flogo has been focused more on stateless service choreography running in Serverless FaaS or Edge devices - however the underlying process engine can be used to implement a long running orchestration process with fully externalized state for resilience and scale. It's 3-clause BSD including the modeling UI with hundreds of triggers and activity extensions in the community. We have a fairly active gitter channel in case you have questions for the core team (https://gitter.im/project-flogo/Lobby)
Disclaimer: I work at TIBCO & we provide commercial support for Project Flogo as well as use it in our commercial products.
We’re looking to grow this further with a model serving service so that its more controlled and better abstracted from processing logic - A/B, champion/challenger, etc. Core devs hang out on gitter in case you have qns or feedback.
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
Good point - yes, we have M0-3 class target platforms on our roadmap. IoT Gateway devices was where the need was most pressing for our customers and we just went there first.
Now, we will likely end up doing a whole lot less functionality on an M0 profile, compared to a typical Flogo flow app on an IoT gateway, but the idea is to offload the right level & kind of edge compute onto lower power nodes.
One point worth mentioning is that pretty much any framework can run on a Pi, but running dozens of these Edge apps - "12-factor" style[1], that is where Flogo's advantage shines through.
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.
As someone working on TIBCO BusinessWorks, a competitor/alternative to webMethods, this sounds all too familiar. We have had major challenge ourselves in bridging this gap - semantic diff/merge on process/flow engines like BW, WM, etc. with visual tooling.
Typically developers care about this, business buyers don't and they direct budgets and in many ways, product prioritization. To a large extent the proprietary or obscure nature of integration DSLs never helped bootstrap any meaningful tooling for users.
That's changing though with developer-power driving prioritization and investment. In our case, we hope to make good progress with an upcoming project called Flogo. Currently in stealth and soon to be OSS.
Yes, Rendezvous is still going strong. Tonnes of deployments in FSI, Telco, Fabs, etc. That said its showing its age in the cloud among couple of other areas. We typically point users who need low latency data distribution to RV's successor called FTL. Similar peer to peer architecture like RV, but new capabilities like multi-transport (tcp/mcast/rdma/shared mem), content-selectors, pub-sub/req-reply semantics. And wicked fast on commodity hardware.
I haven't looked at Iris but the problem of abstracting physical from logical topology in distributed systems has been a major influence on RV and FTL architecture. Real world problem once you move beyond speeds and feeds and "looks ma, sockets!" semantics.
Stoked to see Trivandrum on the list, but you are way off the mark (by~10-15x) re: cost of living, arent you? Technopark has decent infrastructure but attracts mostly BPO/IT Services. Kazhakkoottam/Sreekaryam are rapidly getting gentrified too :(
(Source: Born in Tvm, studied there till undergrad, friends and family there)
Disclaimer: I work at TIBCO