Elastic jobs in Azure
My role: Product designer
Tasks include: Researching users, Planning user tasks and flows, Creating wireframes and prototypes, Testing usability, and Designing user interfaces
Tools used: Figma
Timeline: 3 weeks
The problem with elastic jobs
What is an elastic job?
Elastic jobs provide the ability to run one or more T-SQL scripts in parallel, across a large number of databases, on a schedule, or on-demand. The target can be any tier of Azure SQL Database.
You can run scheduled jobs against any combination of databases: one or more individual databases, all databases on a server, and all databases in an elastic pool, with the added flexibility to include or exclude any specific database.
Jobs can run across multiple servers, multiple pools, and can even run against databases in different subscriptions. Servers and pools are dynamically enumerated at runtime, so jobs run against all databases that exist in the target group at the time of execution.
How to create an elastic job?
Create an Elastic job agent
Create credentials on the Agent database in Azure SQL
Create a target group and members
Create logins on the target master and user database
Create job and job steps
When to use elastic jobs?
Have a task that needs to be run regularly on a schedule, targeting one or more databases.
Have a task that needs to be run once, but across multiple databases.
Need to run jobs against any combination of databases: one or more individual databases, all databases on a server, all databases in an elastic pool, with the added flexibility to include or exclude any specific database.
Jobs can run across multiple servers, multiple pools, and can even run against databases in different subscriptions. Servers and pools are dynamically enumerated at runtime, so jobs run against all databases that exist in the target group at the time of execution.
This is a significant differentiation from SQL Agent, which cannot dynamically enumerate the target databases, especially in SaaS customer scenarios where databases are added/deleted dynamically.
Prototype and Design story
The design story
The purpose of this design was to help users find a way to create, monitor, and manage elastic jobs.
Creating a wizard-like process to create the full process of creating an elastic job. The purpose of the design decision to use a wizard, similar to how we use Turbotax, it is a process that can come off as complicated and can easily be digestible by users using a step by step process.
Each Target group with a job is in a card view where the user is able to monitor and see the status of the job executions.
I worked with a team of engineers and a design PM, we did weekly design sprints where, in each meeting, we discussed design feedback and had weekly design updates.
Designs were done in three (3) weeks with continued support given to engineering after design handoff.
The design decisions
When working with engineers and PMs, there will always be questions about why you chose to take a certain design route to find solutions for your customers. I used the laws of UX below to justify my design decisions and used my analysis of existing products that have similar complex problems and solutions. The most important part is to speak to the users/customers and perform user testing to get better feedback, document the design decision feedback, and constantly try to ideate solutions that will work best for customers.
