Major Architecture Update: Simplified LlamaDeploy

[masci]

We're excited to announce a significant architectural change in LlamaDeploy that dramatically simplifies how workflows are deployed and executed. This change represents our commitment to making LlamaDeploy more accessible while maintaining its core Workflow orchestration capabilities. The new architecture prioritizes simplicity and performance over distributed scaling, making it ideal for most deployment scenarios.

♻️ What Changed

We've removed the control plane and message queue concepts from LlamaDeploy, moving from a distributed microservices architecture to a streamlined single-process execution model.

Before

• Complex multi-component architecture with separate control plane server
• Message queue infrastructure (Redis, RabbitMQ, Kafka) for service communication
• Workflows deployed as network services with orchestration overhead

After

• Direct workflow execution within the API server process
• Workflows loaded as Python modules and executed in-process
• No external message queue dependencies required

💆 Benefits

• 🚀 Simplified Deployment: No more configuring message queues or control planes
• ⚡ Better Performance: Direct execution without network communication overhead
• 🛠️ Easier Development: Streamlined debugging and testing experience
• 💾 Lower Resource Usage: Single-process architecture reduces memory and CPU requirements

🛑 Breaking Changes

• Message queue examples and integrations no longer supported
• Service-based workflow communication patterns deprecated
• Custom message queue implementations no longer extensible
• Deployment configs: remove control-plane and message-queue sections (now ignored)

✈️ Migration path

The update will be rolled out with a major release 1.0 to reduce the impact on existing installations of LlamaDeploy, but given the size and impact of the breaking changes we cannot guarantee a clear migration path. In general:

• If you are only relying on the API Server component, with no manual orchestration of the internal components:
  • If you are using the SimpleMessageQueue then nothing changes, your project can be upgraded to 1.0
  • If you are using a specific message queue, your project should run fine after the update but expect differences at runtime depending on your environment and workload
• If you are orchestrating the different components manually, or you have customized any of them, the project cannot be ported and you should pin the llama_deploy requirement in your dependencies as <1.0

[robbyfrt]

When are you planning to release v1.0.0? Any estimate would be appreciated.
I've just updated to v0.9.1 after some hiccups but have my core functionality running again.

So v0.9.1 is currently missing a few things such as

• get_sessions only returning ids, not the complete SessionDefinitions
• redis message queue handling - at least i could not get it working again without additional documentation.

I assume these things will be back in the upcoming major release? Very much looking forward to it :).