Scheduling tasks onto cloud VMs is a trade-off, not an optimisation: makespan, monetary cost and load balance pull against each other, and improving one usually costs you another. NSGA-II is the standard answer because it returns a Pareto front rather than a single winner, leaving the trade-off explicit.
Its weakness is that crossover and mutation rates are fixed up front, and the right rates change as the search progresses — early generations want exploration, later ones want refinement. Fixed rates are a compromise between two regimes that never coexist.
The approach
A reinforcement learning agent adjusts those operator rates between generations, using population diversity and improvement in hypervolume as its reward signal. The evolutionary algorithm is untouched otherwise; the RL layer is a controller on top of it, not a replacement for it. That was a deliberate design constraint — it keeps the Pareto-optimality guarantees of NSGA-II intact, and it makes the contribution measurable, because the same algorithm with static rates is the obvious control.
monetary cost
load balance
compared against PSO and ACO
baselines in CloudSim Plus
Evaluation runs in CloudSim Plus against particle swarm and ant colony baselines on the same workloads.
Honest limitations
This is simulation, not a real cluster: CloudSim Plus models VM provisioning and task execution but not network contention, noisy neighbours, or the scheduling behaviour of a real hypervisor. Results here indicate that the adaptive-operator idea is worth testing, not that it survives contact with production. The RL agent’s reward is also a proxy — hypervolume improvement is a reasonable stand-in for search quality, but it is not the objective anyone actually cares about.
Built with Python, CloudSim Plus, NSGA-II, reinforcement learning