locked
Batch useful today? What features to expect RRS feed

  • Question

  • I can't see any benefit in the Azure Batch service. Running a batch of VMs in Azure can easily be achieved via the Azure API? So why adding an additional layer? Also the logging stuff isn't that much work.

    As far as I can see is that I only loose control over the OS in the VMs? 

    Each VM in Batch Service must be provisioned as it is in Azure which takes much time. So what is the intention of this service?

    The real thing would be having preprovisioned and running VMs so that only the Application Image has to be transfered and the Job can start nearly immediately! Of course the customer should only be charged for the use. The benefit of the cloud is having huge computation power for a short time in a matter of seconds. Running long jobs I can use conventional services!

    Batch Service today is provisioning big OS-Images on hundreds of VMs when a job is started. This is such a waste of time for the user! This can be done before!



    • Edited by doczoidberg Saturday, December 6, 2014 1:57 PM
    Saturday, December 6, 2014 1:40 PM

Answers

  • Case A:

    In the TechEd OCR demo processing each image takes 1-5 minutes.  It does take 5-10 minutes to start the VM's.  The key thing to note is that the VM's are not being provisioned just for processing 1 image; the idea is that there are images being submitted for processing on an ongoing basis or there are way more images that there are VM's; in either case multiple tasks are processed on a VM and the task processing time far outweighs the time to provision VM's.

    Case B:

    For video transcoding, where tasks may take hours, Batch works really well.  If there are a few hours of encoding per day, then the cost of starting up the VM's is not significant and you have the advantage of only paying for the compute used, then releasing the VM's when finished.

    Maybe there is an ongoing transcoding load, with peaks and troughs; in this case Batch allows you to scale up and down the number of VM's easily so that you can ensure your VM's stay highly utilized and you pay-for-use.

    It can be difficult to keep dedicated servers 100% utilized and we see that customers want to use Azure because it provides flexibility - get compute VM's when they are needed, increase or decrease capacity as needed, hand back VM's when not needed.

    Friday, December 12, 2014 10:52 PM

All replies

  • Azure Batch makes it much easier, more reliable, and cost effective to run parallel, compute-intensive applications at large scale in Azure.  For example, performing hundreds of thousands of video transcodes a day that require hundreds of VM's.

    Azure Batch provides high-level functionality that makes it easy to obtain and manage hundreds or thousands of VM's on which the work will be performed.  It installs applications and data on the VM's from Azure Storage; it provides the ability to auto-scale the number of VM's up or down depending on various metrics according to load.  Our main goals are to help you increase utilization and leverage the elasticity of the cloud.

    As the user of Batch, you can choose to pre-provision the VM's so your job can start immediately or provision the VM's when a job starts.

    Job scheduling is the other main area of focus - make it easy to actually perform work on those VM's - submit jobs and tasks - find free VM's on which to run each tasks, queue tasks until VM's are free, re-queue failed tasks, detect and terminate frozen tasks, etc.

    With Batch Apps we enable non-Azure developers to cloud-enable and run applications in Azure, as well as providing richer end-user UI for end-users and administrators - provide an end-to-end solution, in addition to catering for developers building a service.

    You could absolutely build Batch functionality yourself on top of Azure compute, but it is a significant amount of infrastructure and work that is not core to most peoples business.  Batch provides a rich set of capabilities as a full-managed service that is highly scalable and robust.

    Hopefully that helps clarify capabilities and value.  I would also recommend viewing a talk I gave a TechEd Europe which should provide more info and shows a number of demos - http://channel9.msdn.com/Events/TechEd/Europe/2014/DBI-B216

    Regards, Mark

    Tuesday, December 9, 2014 4:07 PM
  • Simple calculation:

    case A:

    Running a task like the OCR example in the video takes around 1 minute.
    Starting/provisioning the VMs takes around 5 minutes.


    case B:

    Running longer tasks like daily video transcoding.
    This thing does not to be executed very fast so that dedicated servers are much cheaper for that.


    • Edited by doczoidberg Friday, December 12, 2014 11:06 AM
    Thursday, December 11, 2014 11:12 AM
  • Case A:

    In the TechEd OCR demo processing each image takes 1-5 minutes.  It does take 5-10 minutes to start the VM's.  The key thing to note is that the VM's are not being provisioned just for processing 1 image; the idea is that there are images being submitted for processing on an ongoing basis or there are way more images that there are VM's; in either case multiple tasks are processed on a VM and the task processing time far outweighs the time to provision VM's.

    Case B:

    For video transcoding, where tasks may take hours, Batch works really well.  If there are a few hours of encoding per day, then the cost of starting up the VM's is not significant and you have the advantage of only paying for the compute used, then releasing the VM's when finished.

    Maybe there is an ongoing transcoding load, with peaks and troughs; in this case Batch allows you to scale up and down the number of VM's easily so that you can ensure your VM's stay highly utilized and you pay-for-use.

    It can be difficult to keep dedicated servers 100% utilized and we see that customers want to use Azure because it provides flexibility - get compute VM's when they are needed, increase or decrease capacity as needed, hand back VM's when not needed.

    Friday, December 12, 2014 10:52 PM