- Published on
Run sandboxed tasks for AI using Azure Container Jobs
azure- Authors

- Name
- Ndamulelo Nemakhavhani
- @ndamulelonemakh
No no no, read the title again. Not Azure container apps nor container instances!
Azure Container Jobs is a recently launched service in Azure that offers a managed and lightweight solution to run ad-hoc, scheduled, or queue-scaled jobs using containers. With this service, all you need is a container image with your application logic, and the rest of the work such as logging, scheduling, and autoscaling is taken care of for you.
Okay, I think that's enough cloud marketing Mumbo jumbo for now. However, you can also imagine other benefits such as flexible CPU and memory options, cost savings, and the ability to handle spikes in demand etc. etc.
Motivation
Machine learning: You can use jobs to train machine learning models on large datasets. Jobs can be triggered manually or scheduled to run at specific times.
Batch processing: You can use jobs to perform **on-demand **or **scheduled **batch processing tasks such as image or video processing, transcoding, and more!
**Scraping: **If you are running a scraping tool like scrapy with redis, you can use container app jobs as workers to regularly fetch data from target websites
Quick start
Create an Azure Container Job(Preview) to summarize a batch of PDF documents?
(a) This example uses Azure CLI to create an on-demand job to summarize a collection of PDFs
az containerapp job create \\
--name \"my-job\" --resource-group \"my-resource-group\" --environment \"my-environment\" \\
--trigger-type \"Manual\" \\
--replica-timeout 1800 --replica-retry-limit 1 --replica-completion-count 1 --parallelism 1 \\
--image \"mcr.microsoft.com/k8se/quickstart-jobs:latest\" \\
--cpu \"0.25\" --memory \"0.5Gi\"
(b) The above command only creates the job. To start a job execution, use the following command:
az containerapp job start -n my-job -g my-resouce-group
(c) If desired, you can also use Azure ARM or Bicep templates to deploy your jobs
Using Containers in Private Repositories
Your container image can be stored in any docker-compatible registry. Here are some examples for deploying a job from a Private Azure Container Registry:
(1). Azure container registries
(2). Docker
(3). GCP
(4). AWS
More usage examples
If you're still curious about how to use this awesome feature offered by Azure, why not check out some Sample projects on Github. Here are some of my favourites:
(1). Scalable scraping solution with azure and scrappy Redis
(2). Model training
(3). Image
Azure Container Jobs vs Alternatives
You are probably asking yourself, why you would go for this option instead of other on-demand compute services like Azure functions, Azure Batch Jobs, ACI or original Container Apps offering (You do know why I am not including VMs in this list right??).
(1). **Azure Functions, **on the other hand, is a serverless compute service that enables you to run event-driven code without having to worry about infrastructure. It is best suited for scenarios where you need to run small pieces of code in response to events such as HTTP requests, messages arriving in a queue, or changes to data in a database.
(2). Azure Batch Jobs is a service for running large-scale parallel and high-performance computing (HPC) applications efficiently in the cloud. It is best suited for scenarios where you need to run large-scale parallel workloads such as rendering 3D images or performing simulations.
(3). Azure Container Instances (ACI) provides a single pod of Hyper-V isolated containers on demand. It can be considered a lower-level “building block” option compared to Container Apps. Concepts like scale, load balancing, and certificates are not provided with ACI containers. For example, to scale to five container instances, you create five distinct container instances.
Conclusion
Yes, I agree. You could probably exchange container app jobs with any of the alternative services listed above. The best approach, as always, is to review the primary advantages of each service and decide if they coincide best with your use case. If you are still not sure, just pick the one you like the most and start building. You will know when you start requiring too many changes in the default framework workflow that you need a different service. Hopefully, your app won't have a billion users by then...
