Recently, Windows Azure Webjobs were introduced to Windows Azure Web Sites. Webjobs are background tasks that come in 3 different flavors (Manual, Triggered and Continuous). These jobs can be used to execute tasks such as database maintenance, RSS aggregation and queue processing. As new features rollout for Windows Azure Web Sites, it’s reasonable to ask whether Cloud Services are still relevant.
I see Cloud Services as a flexible scale unit, where I can spread compute intensive workloads over an echo-system of Role instances. As always, with great power (flexibility) comes great responsibility (we need to care about details).
Let’s reflect on Webjobs for a moment. Webjobs are background processes that run within the same instances that host your Windows Azure Web Sites. If you scale your Windows Azure Web Site, the Continuous Webjobs will be scaled accordingly. In other words, Webjobs may not be fit for all of your background tasks. Take this for example, if you create a Webjob that’s responsible for cleaning your Database as a continuous Webjob and you scale your Windows Azure Web Site to 2 instances. Both Webjob instances will end up competing for the same Windows Azure SQL Database resources. Results can range from dead locks to being throttled by Windows Azure SQL Database.
If you have multiple Windows Azure Web Sites hosted on the same Standard Virtual Machine instance, running compute or network intensive Webjobs has the potential of affecting the overall performance of your Windows Azure Web Sites. Consequently, it’s important to think about these constraints when you design your Webjob.
In previous blog posts I explored using blob leasing as a way to restrict jobs from executing in parallel. Webjobs makes this easy for us by providing mechanisms that allows us to restrain the execution of our jobs. This can be achieved by using schedules or by using an attribute provided in the Webjobs .NET SDK. If on the other hand you are not using the SDK and wish to control the execution of a Continuous Webjob, it will require extra work. Continuous Webjobs are kept alive by the underlying platform. If a job has stopped running it will be restarted within a reasonable period of time. This is both an opportunity and an obstacle. The obstacle is that it can be hard to design a Continuous Webjob that scales nicely without the .NET SDK. On the other hand, this can also be an opportunity, because you can use blob leasing to determine whether a Continuous Webjob is currently running. If it is, you can exit the process and have an assurance that it will try again in a few seconds. By scaling the Continuous Webjob, you are creating redundancy with the certainty that if the active Webjob fails, a backup instance will kick in.
Coming back to the original question, are Cloud Services still relevant? My answer is yes. They’re still quite relevant because of their nature. Windows Azure Web Sites, when hosted in Standard mode, are regrouped under a common Virtual Machine. Cloud services tend to be distributed over numerous Role instances. Making them perfect candidates for resource intensive jobs. These jobs can get executed by roles of different sizes and configuration. In turn, this gives us better control over spending and isolation of processes. In fact, if a Role is a tad heavy on resources (CPU, ram or network) the other Roles are potentially unaffected.
Webjobs sound great! I highly recommend that you take a look at them for lightweight processing of queues, blobs, table storage and other easily distributable tasks. Use them for maintenance jobs and for reporting, but don’t rule out Cloud Services. They’re still quite relevant because they’re our low level workhorse. You can use them to consolidate compute intensive jobs in order to exploit their full potential. Although Cloud Services are more complex, they’re a very flexible solution.