Sign in
 
HomeLibraryWikiLearnGalleryDownloadsSupportForumsBlogs
Resources for IT Professionals >
> 
> 
Managing Compute Time

Con risposta Managing Compute Time

  • Thursday, December 23, 2010 6:09 PM
     
     
    Sign In to Vote
    0

    Just to start things off, I'm not complaining - just confused!

    When I watched the videos in the getting started section at: http://www.microsoft.com/windowsazure/getstarted/default.aspx I had the understanding that I would only be billed for what I 'used'.

    So if I have a web role hosting a WCF service and a worker role executing the stored procedures I have in my database and then thread.sleeping for an amount of time - what constitutes as compute time?

    Does the uptime alone of a single instance constitute as usage?  Somewhere along the line, I guess I had the assumption that if my process was sleeping or not doing anything that I wouldn't be billed compute time for it.  Should I be doing something instead of thread.sleep to prevent compute time usage or is compute time really just system uptime renamed?

    EDIT:

    Some afterthoughts:

    After examining the cost of Azure vs dedicated server hosting - I'm not sure where I necessarily see the cost effectiveness of using Azure.  Maybe my first impressions of pricing are incorrect, but it seems just as easy and cheaper to get a couple of dedicated servers with Windows, IIS and MySQL to do the same thing Azure does without worrying about overages while getting more CPU power, usability and managability.

     

     

All Replies

  • Thursday, December 23, 2010 6:38 PM
    Answerer
     
     Answered
    Sign In to Vote
    0

    what constitutes compute time?

    You are billed for each wallclock hour in which you have an instance DEPLOYED regardless of the run state of the instance. For example, if you deploy an instance at 10:45 and delete it at 11:15 without starting the instance you will be billed for two hours. On the other hand if you deploy at 11:15 and delete at 11:45 you will be billed for only one hour. The only way to prevent being billed for an instance is to delete it - thread.sleep() does not prevent compute time usage.

    • Marked As Answer by three_sixteen Friday, December 24, 2010 7:31 AM
    •  
     
  • Thursday, December 23, 2010 6:40 PM
     
     
    Sign In to Vote
    0
    Ahha
     
  • Thursday, December 23, 2010 8:24 PM
    Answerer
     
     
    Sign In to Vote
    0

    After examining the cost of Azure vs dedicated server hosting - I'm not sure where I necessarily see the cost effectiveness of using Azure.  Maybe my first impressions of pricing are incorrect, but it seems just as easy and cheaper to get a couple of dedicated servers with Windows, IIS and MySQL to do the same thing Azure does without worrying about overages while getting more CPU power, usability and managability.

    The primary financial benefit of using cloud computing, including Windows Azure, arises when you can take advantage of elastic demand to vary the amount of compute resources you use. If you are providing a service which can not take advantage of demand elasticity then you are paying for a feature you can't use. A secondary benefit of using PaaS is the reduction in IT support needed to manage dedicated servers.

    While you may get more CPU power, usability and managibility from a couple of dedicated servers with Windows, IIS and MySQL you get neither horizontal nor vertical scalability but you do get significantly more management responsibility.

     
  • Thursday, December 23, 2010 9:27 PM
     
     Proposed
    Sign In to Vote
    1

    I disagree that you do not get scalability with a dedicated server/hosting provider/colocation. You *do* get horizontal *and* vertical scalability but at the cost of ease of scaling.  You incur differing amounts of management responsibility depending on colocation/hosting but nothing that's too difficult to manage, and not enough responsibility to offset the higher cost of Azure, in my opinion.

    Azure gives you the convenience of not having to install software, edit DNS, muck with load balancers, and transfer data.  When you think about it though, those things aren't all that difficult to do - and I wouldn't be surprised if hosting providers helped you out with those things.  Certainly if you're only doing colocation you will have to do a lot of the work yourself, but still, you can certainly scale your application.

    A dedicated server/hosting provider will promptly handle getting your hardware installed, OS installed, will get DNS taken care of, and probably will take care of load balancing (a question you should ask before going with them), you have to worry about transferring data and making sure everything is talking to each other.  Some things that you don't have to worry about with Azure.

    There's no magic scalability with Azure, if your application can only handle N requests per timeframe you should be able to tell when you're reaching N in ample time to let you scale.  The only exception might be with a spike of interest in your application, where N comes quicker than you expect - this might be where Azure comes in handy provided you're paying attention and can quickly spin up instances as they're necessary.

    Elastic demand is only a buzz word here, you don't scale up to only the resources you need with Azure.  Just like with any other hosting provider you scale to a median level of availability.  Not too much that you overpay, and not too little that your application availability degrades.  The idea of paying only for what you use is lost when you are paying for strictly for system uptime. 

    I could see a benefit if you are truly only paying for spent CPU cycles, but if your application is sleeping/idle - you are paying to power your 1 core VM at a cost that is very close to what it would cost to power a dual quad core+ physical server.  How many applications are running on a server?  Are the cores your application using truly dedicated to your application, or are you possibly sharing them with other people?

    • Proposed As Answer by vtortola Friday, December 31, 2010 2:42 PM
    •  
     
  • Thursday, December 23, 2010 9:53 PM
    Answerer
     
     
    Sign In to Vote
    0

    Elastic demand is only a buzz word here

    Uhm, no. Elastic demand is a very real thing. For example, when Azure was in CTP I would routinely leave test services up for days. Now I deploy for only the time it takes to do the tests.

    Maarteen Balliauw has an interesting post with some charts showing a service he worked on elastically scaling between 1 and 18 instances to meet demand for a weekend event he was organized in. Had he done this at home it would have taken all weekend to unbox the PCs. Who knows what the effect would have been doing this in a hosted environment not designed to deal with this type of elastic demand - perhaps he would just have swagged a need for four servers and spend the weekend handling calls from disgruntled users.

    In a PDC 2009 presentation Dianne O'Brien has a slide describing four optimal workload patterns for the cloud:

    - On and off
    - Growing fast
    - Unpredictable bursting
    - Predictable bursting

    Only one of them does not involve scaling down.

     

     
  • Wednesday, February 02, 2011 1:52 AM
     
     Proposed
    Sign In to Vote
    0
    The thing that is unclear to me is that there is no destinction between Production and Staging so if you have something in staging environment that counts the exact same as something in production in terms of compute instances - yes it might be "taking up space" but it is not conceptually a "by the hour" uptime equivalent to live production.
    • Proposed As Answer by TaunM Wednesday, February 02, 2011 1:54 AM
    •