geomagilles

Indeed. Using a streaming platform makes sense only if you need messages durability (and sometimes reusability). When implementing a request/reply pattern on top of such a platform (Infinitic does that btw), it necessarily adds some latency due to multiple persistence operations.

The idea is that each business process can be implemented through its own service. So a microservice architecture is still very relevant from an organisational point of view. The team in charge of this business process must know the interfaces of the services it uses. But they are the only ones. There is actually less coupling in this organisation, not more.

Thank you for your comment. Highlighting the need for a descriptive format to orchestrate services implemented in multiple languages is a valid point. While Infinitic currently uses Java's interfaces, adopting a more generic and language-agnostic solution like Protobuf is a sensible approach that could promote better interoperability across different tech stacks. Then we need a DSL. Again, Infintic is using Java/Kotlin, but I'm thinking to the ideal solution as a new simple language in which Protobuf object are first-class citizen and that can be resumable (i.e whose internal state can be safely stored to be resume later). It's not as easy as it sounds as a lot of legit issues arise regarding versioning.

hmm, that's strange - it's a special "friend" url and I can access it myself from an incognito window using this url (I have a Medium banner to subscribe but I can close it).

Indeed. And you are raising another good point: the testability of such architecture is quite poor. Without a way to represent the architecture as runnable and testable code, it is problematic to ensure the correctness and reliability of the system. While documentation helps, it does not provide the same level of assurance as testable code.

Thanks - I did not intend to hide anything. Sorry if it was not clear that I was the original creator of Infinitic.

Can you access through this url? https://gillesbarbier.medium.com/the-way-we-are-building-eve...

In this article, I express that the prevalent approach to building event-driven applications using the choreography pattern is misguided and can lead to significant technical debt. As an alternative, I introduce the Infinitic framework as a way to enable teams to implement event driven processes without the pain and complexity of building and managing an event-driven system themselves.

Infinitic and Cadence / Temporal share similar vision / objectives, but we have quite different infrastructure and architecture.

Our use of Apache Pulsar gives us an efficient foundation that is proven, scalable, and is evolving rapidly thanks to the wider community to which we belong. We have been able to inherit features such as geo-replication, horizontal scaling, transactions, tiered storage, tooling, connectors with other technologies, etc.

One of the main benefits of using Pulsar is that we can achieve high-performance, low-latency throughput with small cost infrastructure. Using Infinitic provides similar benefits than Cadence / Temporal without needing its adhoc/additional infrastructure.

Hi, Zenaton cofounder and Infinitic creator here. It's more than a renaming, it's a complete rewriting. In many ways, Infinitic is better than Zenaton. And yes you can deploy on your own :)

Hi Andrew, I'm Zenaton's cofounder and you are right Temporal and Zenaton follow the same "workflow as code" pattern. I've written an article recently about it (https://medium.com/swlh/code-is-the-best-dsl-for-building-wo...) - Note that Zenaton is closed now (not enough commercial traction) and I'm working on a new open-source (well Common clauses) implementation of a workflow-as-code engine - similar to Temporal - but with different technical choices (cf. https://medium.com/@gillesbarbier/building-an-event-driven-o...)

Thx. I totally understand your concerns. We work hard to make developer life much more easy. That's also why the solution is hosted. So you do not have to install, maintain, scale your own system. Just to clarify (if needed): your tasks are executed on your servers, we handle only the orchestration itself. Pricing is a work in progress, but we will probably offer a large free usage.

Indeed - but I do not think it's related to the question. The question here is: how do I - as a developer - implement a workflow? Still there are numerous BPM solutions, but often overly sophisticated. You have AWS SWF, but complicated to use, Airflow but in Python only, your own implementation using queues, database, etc... Look at the diversity of answers: there is no obvious answer right now.

There is no obvious solution right now. That's why we are building Zenaton (I'm cofounder). It's in closed beta by now, but you can have a look at the documentation (https://zenaton.com/documentation) and also read some use cases (https://medium.com/zenaton). Zenaton provides a very simple way (in your own programming language) to orchestrate background jobs