Post

Week 3 Update: Function Manager & Streamlined Communication

Week 3 Update: Function Manager & Streamlined Communication

Overview

This week, our focus shifted to the Function Manager, a critical component designed to simplify communication between the serverless compute services and the user-defined execution controller in WRENCH. The Function Manager abstracts the complexities of message passing, allowing users to focus on defining simulation variables and other high-level parameters.

Background

In WRENCH, users primarily implement the execution controller, where they specify simulation parameters and control logic. Given that the underlying architecture relies heavily on message passing between services (e.g., execution controller, compute service, and function manager), it becomes imperative to hide these details from the end user. The Function Manager class achieves this by managing intercommunication and ensuring that users do not have to handle the lower-level messaging directly.

Key Developments in Week 2

1. Function Manager Design

  • Purpose:
    The Function Manager serves as an intermediary that handles:
    • Function Creation:
      Users can define functions using a lambda or callback approach without worrying about the underlying communication protocols.
    • Function Registration:
      It registers functions with one or more serverless compute providers, ensuring that all necessary parameters (e.g., time limits, disk and RAM constraints, ingress/egress limits) are properly set.
    • Function Invocation & Monitoring:
      Provides a clean API for invoking functions and tracking their state (e.g., running, completed, timeout, or failure). It also implements wait mechanisms such as wait_one, wait_any, and wait_all to manage asynchronous executions.

2. Simplification of User Interaction

  • Abstracting Message Passing:
    By encapsulating the messaging logic, the Function Manager lets users concentrate on their simulation and execution logic rather than the intricacies of inter-service communication.
  • Enhanced Usability:
    Users interact with a high-level API that hides the details of message dispatching and response handling, leading to a more streamlined and error-resilient development process.

3. Implementation & Testing

  • Interface Design:
    The Function Manager provides:
    • A simple method for creating functions that include code, image, and output definitions.
    • Methods to register functions with the ServerlessComputeService, effectively linking user functions with backend infrastructure.
    • Invocation methods that handle function execution and state tracking transparently.
  • Testing in a Simulated Environment:
    The initial implementation was tested within a controlled simulation where:
    • The execution controller defines simulation variables.
    • Function registration and invocation workflows were verified for correct behavior.
    • Concurrency and message passing edge cases were carefully handled to ensure robustness.

Next Steps

  • Feature Expansion:
    We plan to enhance the API to support dynamic resource allocation and more sophisticated invocation policies.
  • Improved Monitoring:
    Future iterations will integrate detailed logging and performance monitoring to further improve reliability and ease troubleshooting.
  • User Documentation:
    Comprehensive guides and examples will be developed to help users get started with the Function Manager quickly and effectively.

This week’s progress has significantly improved the usability of our system by isolating the message passing complexities, allowing developers to interact with a simplified yet powerful API. The Function Manager is now a central piece in ensuring that the serverless compute infrastructure in WRENCH remains scalable, user-friendly, and efficient.

This post is licensed under CC BY 4.0 by the author.