Actors vs. RPC - building a new (old) transport layer for Octopus 3.0

In a reflection on the evolution of Octopus Deploy's communication architecture, Paul Stovell discusses the transition from an RPC-based system in Octopus 1.0 to a messaging and actor-based model in Octopus 2.0, highlighting the challenges and limitations encountered. Initially, the RPC style restricted flexibility by requiring Tentacles to be TCP listeners and the Octopus server to be a client, prompting a shift to a more decoupled messaging system that allowed Tentacles to poll the server for commands. While this change offered benefits like improved handling of long-running tasks and support for both polling and listening Tentacles, it also introduced complexities in code navigation, error handling, and actor lifecycle management. Stovell notes that despite the concurrency advantages of the actor model, the specific needs of their domain were better served by the simplicity and readability of the original RPC approach. Consequently, Octopus 3.0 plans to revert to a request/response style, integrating elements of both polling and listening configurations to maintain flexibility while improving code clarity, with an open-source communication stack to be developed further.

No tracked trend matches for this post yet.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.