Week 8 Update: Scheduler Design & Shared State Management

Overview

This week we moved from brainstorming to actual design work for our user-configurable scheduler. We finalized the architectural approach for how users will implement their own scheduling logic, and introduced a dedicated system state manager to provide both modularity and controlled visibility across components.

Designing the Configurable Scheduler

After weighing different approaches, we landed on a clean and extensible structure based on object-oriented principles:

• Virtual Base Class:
  • The scheduler is defined as a virtual (abstract) class that exposes key methods users can override:
    • manage_images: Responsible for image-related logic, such as triggering downloads or checking availability.
    • schedule_invocation: Determines where to run each incoming function based on current system state.
  • This structured interface allows for deep customization while maintaining core simulation flow consistency.
• Plug-and-Play Architecture:
  • Custom scheduler implementations can be injected at runtime, allowing experimentation without altering the core simulation engine.
  • This also enables future support for switching schedulers mid-simulation if needed.

Shared State Management

To make effective scheduling decisions, the scheduler needs a consistent view of the system’s current state (e.g., available hosts, resource usage, queued invocations). We addressed this by introducing a dedicated state manager:

• Centralized State Class:
  • A new class is responsible for maintaining global system state, including invocation queues, host load, and resource availability.
  • This class abstracts away lower-level details and acts as a single source of truth for system-wide status.
• Controlled Access:
  • The scheduler is given public read-only access to this state, allowing it to make informed decisions without risk of accidental modification.
  • The Compute Service has private mutable access, enabling it to update the system state as invocations are processed, without exposing internals to external components.

This separation improves modularity, reduces tight coupling between components, and sets the stage for future improvements like state snapshots or rollback mechanisms.

Next Steps

• Interface Documentation:
  • Write clear, user-friendly documentation for the scheduler virtual class and the public state access API.
  • Include examples to help users get started with writing their own custom schedulers.
• Testing Integration:
  • Begin writing integration tests that verify scheduler behavior with various simulated workloads and resource constraints.
• Scheduler Examples:
  • Implement a few built-in scheduling policies (e.g., Round-Robin, Least-Loaded) to serve as reference implementations.

---

By formalizing the scheduler structure and isolating system state, we’ve made a big leap toward a modular, extensible, and user-friendly serverless simulation platform. We’re excited to see how this architecture evolves with user contributions and complex scheduling use cases.