31 Jan 2013

Azure Tip: How are Web Sites priced?

No Comments Uncategorized

Azure WebsitesOne of the questions that comes up often related to Azure Websites is: How are Web Sites priced?

To understand how they are priced you have to understand what a Web Site is to Azure. To Azure a Web Site, in its most simple definition, is: A single app pool tied to a single site running in IIS on a virtual machine.

Now that we understand this let’s look at the pricing models. Their are three tiers:

  • Free – You share a virtual machine with many other customers and you have to use as domain name supplied by Azure. Your web sites may or may not be on the same virtual machine with the others.
  • Shared – You share a virtual machine with a few other customers and can use your own domain name. Your web sites may or may not be on the same virtual machine with the others.
  • Reserved – You have a reserved virtual machine that is only for your use and you can use your own domain name. Your web sites will be on the same virtual machine with you others in the same region.

As you know now, the virtual machines and how they are shared is the main deciding factor in what tier you choose and the price you pay.  But lets break it down a little, because the pricing model changes on the tier you choose.

Before we get into the break down of the tiers and how their pricing differs it is good to understand one thing, every tier we talk about is priced per region. As of writing this post there are 5 tiers.

  • West US
  • East US
  • East Asia
  • West Europe
  • North Europe

Free

You can run up to 10 Web Sites per sub-region for free in a multi-tenant environment.  What this means is that each data-center you can run up to 10 web sites for free.

Shared

You can run your production site in a multi-tenant environment with support for custom domain names.  Notice that unlike the free tier that there was no mention of how many web sites you were allowed to have per region.  There is a very good reason for this, that is because you are billed out per website that you setup.  As of writing this the price is $9.36 per website per region per month.

Reserved

You can load balance up to 100 Web Sites across instances dedicated to your apps with support for custom domain names.  Notice that like the free tier there is a limit on the number of web sites you can run, it is 10 times more than the free tier, but there is still a limit.  You may be asking why the difference from the Shared tier, well there is a very good reason for this and it relates back to how the Reserved tier differs from Free and Shared.  In the Reserved tier you are billed per virtual machine instance per region per month.  And Microsoft has determined you shouldn’t have more than 100 web sites per virtual machine.

Now that you know you pay per virtual machine instance per region per month, you have options as to the speed and amount of RAM that your virtual machine has similar to the options the rest of Azure enjoys.  Here is the break down:

  • Small VM (1.6GHz CPU, 1.75 GB RAM) – $57.60 per region per instance per month
  • Medium VM (2 x 1.6GHz CPU, 3.5 GB RAM) – $115.20 per region per instance per month
  • Large VM (4 x 1.6GHz CPU, 7 GB RAM) – $230.40 per region per instance per month

The thing to know and understand is that when you switch the tier from Shared to Reserved or vice versa all your websites are moved at once to the other tier.  Because of how they are priced and the complexity of the different tiers this is the current approach that Microsoft is using.  So in other words, per region you can only have one tier of pricing.  

Conclusion

Unlike other services in Azure, the Web Sites is a rather complex pricing model because of the multiple tiers, and at a certain level of websites or usage it may make sense to move from a Shared tier to a Reserved tier.  So if you have more than 6 web sites or you are blowing through your usage limits it may make sense for you to move up to the reserved tier to keep your web site running and to save money.


Note: Azure is really shaping up to be a fantastic and innovative platform, so I plan on making Azure Tips a weekly feature of my blog, so stay tuned for some more tips in the near future.

24 Jan 2013

Azure Tip: My Management Certificate Is Public What Do I Do?

1 Comment Uncategorized

Yesterday @writeameer posted on twitter a search query, using the new GitHub Code Search, showing that there are a whole lot of users on GitHub that have exposed their management certificates to the public.  If you are not aware a management certificate gives you access to administer your Azure account using the Windows Azure SDK tools.  Which among other things allows you to publish, change, delete, or basically cause total havoc if it fell in to the wrong hands in your Azure account.

 

So what can be done about this?

Nothing can really be done about the old certificate being out in the public, once it is out there assume somebody has a copy of it. Luckily it is pretty easy to remove these certificates and generate new ones. Here is how you do it:

Deleting A Certificate

  1. Go to: https://manage.windowsazure.com
  2. Log in using your account credentails.
  3. Go to the settings tab at the bottom of the left hand side menu.
  4. Click “Management Certificates” right below the word “Settings”.
  5. Select a certificate, by clicking on it.
  6. Click the delete button in the bottom center of the screen.
  7. Repeat 5 and 6 until all certificates are deleted.
  8. You can either upload a new certificate, or just wait, a certificate is usually automatically created when you publish your certain types of projects like Web Roles.

Create New Certificates


Note: Azure is really shaping up to be a fantastic and innovative platform, so I plan on making Azure Tips a weekly feature of my blog, so stay tuned for some more tips in the near future.

15 Jan 2013

Executify’s Vision

No Comments Executify

As I explained about a month ago when I introduced Executify, I have launched a new website that works a lot like Azure Mobile Service Jobs except that you have more control over the jobs and you can create them in the .NET 4.5 Framework.

Since then I have wanted to explain the vision behind it. Executify’s vision is to make cloud code easier and more affordable to develop and execute. Traditionally if you want to execute code in the cloud as a background task, you are left with very few affordable options and you have to pay a monthly fee even if you only use the code a few times a month.

This is why we at Executify have developed cloud code on-demand, where you only pay for the execution time you use each month. No more, no less, and no complicated pricing plans.

What is Cloud Code?

Our mission is to free developers from reinventing the wheel when all they really want to accomplish is a simple coding task in the cloud. We at Executify feel this pain, because we are also developers and we have run into the same problems you have run into when trying to deploy our code jobs to the cloud.

  • Creating our own scheduling algorithm
  • Trying to justify the costs of a cloud worker role to our bosses
  • Constantly making sure the scheduled job has been run and the output has been saved

That is why we invented our Executify Cloud Code service which makes it easy to build and deploy your own on-demand cloud code that you can execute through a REST call or via a scheduled cron job. Our Cloud Code is easy to use because it is built on the same .NET Framework that powers millions of apps worldwide. The only difference is that instead of running it on your own servers, it runs in Executify’s cloud. That lets you rest assured that no matter the circumstances your code will run when you want and how you want.

Where is the Cloud Code run?

The Executify platform is built on top of the Azure cloud. As you develop and deploy your Executify Cloud Code Jobs you can rest assured that you get the scalability and performance that you have come to expect from the Azure cloud.

As an added benefit of being on the Azure platform you are able to access your Azure services without needing to do any customization or create special firewall rules. This is especially useful if you need to do clean up or run custom commands in your database on a scheduled basis.

But lets be clear, this doesn’t rule out you using Executify with Amazon’s AWS Cloud, it is just much easier configuration wise if Azure is your preferred platform.

What does the future hold for Executify?

Over the next couple of weeks, I will be introducing the features and benefits of having your scheduled tasks on Executify, so stay tuned.