Developing for (Windows) Azure
Today we will discuss developing for the Azure platform. I will tell you what you need to start development, something about the local development environment and also a few words about Windows Azure API.
What do you need for developing?
If you want to start exploring Azure, you need several things — prepare your dev box, real Azure account and a lot of time and patience. Let´s take a deeper look at all these things.
Preparation of the development environment
As .NET developers, you should definitely be accustomed to using
Visual Studio and MS SQL Server Management studio every day. The good news is you can still use these great tools when you are developing for Azure. But you need to do some upgrades and install new SDKs.
-
Visual Studio - If you want to use the latest features (SDK 1.3 or newer) you have to use Visual Studio 2010 – express version is good enough.
-
MS SQL Server Management studio – you need to use the latest 2008 R2 version to connect to your SQL Azure database with management studio.
-
Windows Azure SDK – currently the latest version is 1.4 SDK — it is basically a fixing version for 1.3 SDK with some additional features for CDN and Azure Connect. You can download it here. It consists of four things: the local cloud and storage emulator, project templates for Visual Studio, a client library and documentation. You can install the templates separately from the rest of the SDK. One important note — version 1.3 is not backward compatible, so you have to choose if you want to use version 1.2 and older or 1.3 and newer. I strongly recommend choosing the second option (1.3 and newer).
-
Azure AppFabric SDK – If you want to use any Azure AppFabric features, you have to install a special SDK. Two versions currently exist, v1.0 and v2.0, which is in CTP. I recommend starting with v2.0 directly because it´s much more useful and has many more capabilities than v1.0
Now, your development box is ready for use.
Real azure account
If you really want to try the Azure platform, you will need to create a real account. If you don´t have one you can create it
here. Unfortunately, you need to enter your credit card number and you will be charged for using Azure — there is no development mode in which you can test an application in the actual Azure cloud without being charged. But you can use one of the offers, for example if you own MSDN premium, you can run one small instance, three databases and use some space for free.
The portal for managing
Windows Azure can be found at
https://windows.azure.com/. It´s a Silverlight application developed for Internet Explorer and you should respect that. I tried to use this portal with the Firefox browser but the Silverlight plug-in crashed every few minutes. On the portal, you can manage all your services except for Azure AppFabric v2.0. The portal also contains a built-in management studio for SQL Azure, you can run queries there, design you database and so on. This portal is also used to sign up for beta services.
If you want to use Azure AppFabric v2.0 you need to go to
https://portal.appfabriclabs.com. There you can create your account for the desired service. The good news is that you don’t need to enter a credit card number this time — this version of AppFabric is in CTP, so you can run it for free.
Patience
Microsoft usually says that as an experienced .NET developer, you have enough knowledge to start developing on Azure. It is true, yes, but there is still a lot to learn. One thing is that you need to study a new API. Another thing is that Azure development takes more time. In Kentico, we count double times when planning development if it’s some feature on Azure. For example, every time you change one line in your code and want to try it in the local development environment, you have to wait for several minutes. First, the whole solution is built, then copied to the cloud emulator and then finally executed in a browser. In the mean time, you have to wait, read news, eat a biscuit and so on. Microsoft is getting a lot of feedback like this and they are trying to do something about it.
Structure of an Azure project
You already know from my first blog post that
Kentico CMS runs in an ASP.NET web role and this role will also be your choice in most cases. After you deploy an application, the fabric controller adds it as a new application to the IIS server and the application starts. So it basically works the same way most of you run applications now. In the on-premise world, you can decide whether you want to use a web site or web application. On Azure you have to use a web application project. However,
Kentico CMS is distributed as a web site. Fortunately, our CTO Martin Hejtmanek wrote a
blog post on how to convert a web site to a web application. The second good news I have for you is that Kentico 6.0 will support web applications natively — you will decide if you want to install Kentico CMS as a web site or web application.
Also, the structure of an Azure project is different than standard ASP.NET applications. As you can see on screenshot above, the solution contains one additional project (CMSAzure in the screenshot). This project type is called a Windows Azure project and it contains the special Roles folder. You can add or remove roles by right-clicking on this folder. If you want to add an existing web application as a web role, you need to modify the project file of the web application a little bit. Right click on the web application project (KenticoCMS in my case), choose Unload project. Then right click on the unloaded project again and choose Edit. Then, add the following XML tag under the first <PropertyGroup> element:
<RoleType>Web</RoleType>
This tag specifies that the web application will be used as a web role.
New configuration files
This project type also brought two new configuration files into the game. The first file, ServiceDefinition.csdef, is called a service definition file. This file defines what you have in your deployment, what roles you are using, their endpoints and so on. This file is mainly used by the fabric controller when it creates and maintains your cloud environment.
The second file, ServiceConfiguration.cscfg, is called a service configuration file. The main purpose of this file is the configuration of your service. With this file you can specify the number of your instances, change application settings and so on (by the way, Application settings must first be defined in the service definition file and then you can set them up in this file). You now may ask yourself why you should store settings in this file instead of the web.config file. The answer is simple — this file is the only one which you can edit directly on the cloud without redeployment of the whole solution. So saving application settings here is… let’s say convenient :). Of course you can read from this file via Windows Azure API and also write to it directly from the application. Kentico CMS 6.0 will support using the service configuration file for storing application settings and the connection string.
Local development
Now let’s talk for a while about local development. If you are completely unfamiliar with creating Azure applications, check out
this video for a step-by-step tutorial.
Azure SDK contains an emulator of Windows Azure compute and storage services. You can use the compute emulator for running your app on the built-in web server from Visual Studio or IIS. It depends on whether you run the app under Full IIS or under Hosted Web Core (you can set this up in the service definition file — configuration will be the topic of my next post). Anyway, when you press F5 (start debug) in Visual Studio, the project is compiled, the deployment package is created and then the emulator runs your app from the package.
The storage emulator uses a SQL express database as storage for your testing data. When you run the emulator, the first step is that the DSInit utility runs and creates the needed table structure. At this point a problem can occur. Every MS SQL server database has its own instance name. You can set it during the installation process, the express version is named SQLEXPRESS by default and DSInit searches for this name. If the name is not found, an error is shown and the role doesn’t start. So, if you changed the alias during the installation or are using a different edition, you will face this problem. There are three ways to solve this — change your alias, create another one (see for example
this article) or you can run the DSInit tool with the
/sqlInstance=<name> parameter and specify this name explicitly.
Cloud environment
After trying your application in the local environment, you will certainly want to try it in the real cloud. The best way to create a deployment package is to right click your cloud project in Visual Studio and select publish. There are several ways how to get the package to the cloud, the easiest is to use the portal (
https://windows.azure.com). If everything goes well, your role will start and you can enjoy the application in the cloud. But more often something goes wrong. The real cloud is a slightly different environment than the emulator or On-premise server. Three main differences are:
-
No debugging on the cloud – there is no Visual Studio with its debugger, the only thing you can count on is the log. Yes, you can connect to your role via remote desktop but this is still not as comfortable as the emulator.
-
Different trusts – Windows Azure application runs under a specific trust model — see http://msdn.microsoft.com/en-us/library/dd573355.aspx for more info.
-
No changes in the cloud – I have already talked about it and you cannot change any file without redeployment of the whole solution unless it’s a service configuration file.
Windows Azure API
Almost everything on Windows Azure can be handled via API. The basic API is REST. The main advantage of this approach is that you can write applications in almost every programming language. On the other hand, HTTP requests are quite low level and difficult to work with. Microsoft knows about this problem and prepared a client library for the most common service — storage. There are three types of API — service runtime and diagnostics, storage and service management.
Service runtime & diagnostics API – the purpose of this API is to control and get information about the current role, instance, and deployment and also to set up diagnostics. This API can be called only internally from code executed on Azure and that’s why this part is not supported via REST. You can use a managed or unmanaged library.
Storage API – with this API you are able to see or add content to any of the three durable Azure storages. As I mentioned above, you can use REST or a managed library for .NET which is a wrapper over REST. I strongly recommend using the managed library.
Service management API – it is designed for manipulation with the whole deployment. You can create/delete services or deployments, get info about them and so on.
You can find API documentation on
MSDN.
Fine, we are at the end of today’s post, I’m sure I didn’t cover everything that should be said about development for Azure, but this topic could fill up a whole book. I tried to choose the most important and most interesting things from my development experience with the Azure platform. I hope you enjoyed this text, the next post will be focused on configuration capabilities of Windows Azure.