At SingleStore, we have a culture of internships — and every year we have several interns during the summer. For interns to have an idea of the work we do, we like to give them a full project (even if smaller) so they get to see it through from start to finish.
During summer 2023, we assigned the Workspace Auto Suspension project to Filipe Silva. Before his internship started, I worked on the spec for this project and mentored Filipe during his internship.
What is Workspace Auto Suspend?
Workspaces can already be suspended, allowing users to save credits while they’re not using them. However the user needs to manually suspend the workspace, either through the UI or the management API. As the name implies, this feature allows the user to program their workspaces to suspend automatically.
We provide two types of auto suspension:
- Idle. Suspend the workspace after it has been idle for a certain amount of time.
- Scheduled. Suspend the workspace after a certain amount of time, whether there's activity on it or not.
Scheduled suspend is only available to users with a paying subscription, but idle suspend is available to everyone. This is great for trial users since they can save credits while their workspaces are not being used.
When a user creates a workspace, they can set their preferred auto suspend settings. For trial users, we enable it to 20 minutes by default, but leave it disabled for standard users:
After the workspace is created, users can also change the settings in the workspace settings UI:
To get the workspace active again, it just needs to be resumed. Users can choose to keep or reset the previous auto suspend settings:
Users can also perform these actions with the management API:
- Create workspace with auto suspend
- Edit auto suspend settings
- Keep/reset auto suspend settings on resume
Implementation
During the three months of his internship, Filipe worked mostly on this feature. This includes the backend queries and mutations for auto suspend, recurring tasks that suspended the workspaces and the frontend UI. The only thing missing was the management API endpoints, which I finished later.
After all the code changes were made, we sent the feature to QA to test. The issues found varied in complexity to fix: some were simple UI bugs; others revealed some issues in our logic to auto suspend the workspaces, which were not as straightforward to fix. This delayed the initial release of the feature, since after fixing everything we sent it again to QA to make sure the previous issues were resolved.
Statistics
We set up a couple of dashboards that track user usage of the auto suspend feature, separating the user groups into “Trial Users” and “Paid Org Members”.
When users create a new workspace, most of the trial users enable auto suspend. This correlates to our setting auto suspend enabled by default in the Create Workspace form — meaning most of the users don’t change the default values provided.
On the workspace settings flyout, users usually update the auto suspend type to “Idle”. We were expecting this result when building the feature, since idle auto suspend would be more relevant for customers and scheduled suspend is not available to trial users.
As for the values users typically use for auto suspend, we see a lot of users setting values around one hour. This is interesting, since the default value we set on the workspace creation form is 10 minutes — so users are changing this afterward to longer durations.
After release
After we released the auto suspend feature, we found the recurring task that was suspending the workspaces wasn’t very efficient. Our initial approach was to create a recurring task per workspace group responsible for suspending its workspaces that had auto suspend settings, and conditions to suspend were met.
At the time, we didn’t see an issue with this approach. Only after release did we realize a lot of tasks were being created in our system — most of which were not doing any actual work — since most of the groups didn’t have workspaces with auto suspend enabled. At some point we had almost 300 tasks, where only six of them actually suspended any workspaces.
This was causing a strain in the system so we refactored the approach, making sure we wouldn’t break the auto suspend task for existing workspaces. The recurring task is now at the workspace level and is only active if the workspace has auto suspend settings enabled. This way, existing tasks are expected to do actual work.
Lessons learned
The initial estimation for the project duration wasn’t accurate. Initially, we assumed there would be time for Filipe to finish the project in his three-month internship — but he ended up not being able to complete the management API part of the project, as well as passing through QA.
Next time, we should take a better approach of dividing the whole project into tasks and estimating the time each task takes to complete, including time for feature stabilization (QA rounds of testing and fixing issues).
We also learned the default values we use in our forms are very important. Users rarely change these values, so they end up using what the form has initially set. We should consider carefully what values we want our users to use by default.
Finally, there’s always room for improvement. The initial version of the recurring task wasn’t as efficient as we would like, so, even after the project was completed and GA’d, we were able to successfully improve it.
