I’m aware that there many cloud computing introductory articles or papers out there, so why am I writing another one? As this my first article at A Cloudy Place, I’d like to start at the beginning and take a new approach to explain the cloud.
The analogy that I will be using is very simple and I believe some readers have probably run into it at some point. Have you ever considered buying or renting a car?
Buying a car is a big investment, and there are a lot of important decisions to take into account. Some people like all the different options, and others don’t want to bother with thousands of decisions. When buying a car you have full control over everything, its make and model, cost, interior, etc. Additionally, you’ve got to work about taxes, insurance, inspections, and all sorts of maintenance, you’ve got the control, but it comes with a hassle.
Then how about renting a car? You have fewer and simpler decisions to make. You just need to select a car from what’s available, and you can switch your car if something comes up.
Rent when you need; pay when you use. You don’t have to worry about maintenance costs, tax, and insurance since they are included in your rental fee. On the other hand, there are obviously some disadvantages. You’re limited by what’s available from the rental vendor, you may not be allowed to customize the car, and the car is not dedicated to you all the time.
This simple real life analogy is easily translatable to Cloud Computing.
Buying your own car is similar to setting up your own on-premise data center. You have the flexibility to customize whatever you like, starting from physical infrastructure, the security system, hardware and software, etc. However, you also have to invest a lot of money upfront. And also, you will also need to manage it later when it’s operating.
On the other hand, instead of building your own data center, you can rent computation power and storage from the cloud provider. You can scale in and out when necessary. Just pay when you use. No specific commitment takes place. You can start and stop anytime.
This summarizes the characteristics of cloud computing.
Resources should be always available when you need them, and you have control over turning them on or off to ensure there’s no lack of resource or wastage happen.
You should be able to scale (increase or decrease the resource) when necessary. The cloud providers should have sufficient capacity to meet customer’s needs.
Sometimes you may be sharing the same resource (e.g. hardware) with another tenant. But of course, this is transparent to the customer. Cloud provider shall responsible the security aspect, ensuring that one tenant won’t be able to access other’s data.
Related processes including: billing, resource provisioning, and deployment should be self-service and automated, involving much less manual processing. If a machine where our service is hosted fails, the cloud provider should be able to failover our service immediately.
Cloud provider should be able to provide customer reliability service, committing to uptimes of their service.
You will pay the cloud provider as a utility based subscription, just like paying your electricity bill – without any upfront investment.
Cloud Computing consists of several type of service models.
There are three main cloud deployment models, each on with its own set of customers it’s targeting.
I sincerely hope that, this article would be helpful to you. In my next article, I’ll discuss more about the comparison between IaaS and PaaS.
This post was also published at A Cloud Place blog.
In many cases, we need to have two different set of configuration settings (let say: one for development environment and another one for production environment). What we normally do is to change the setting one by one manually before deploying to production server and change them back again to development. This is very annoying especially when you have many settings.
Web.config transformation is an awesome technique to transform the original web.config into another one with slightly changed of settings.
You could find more detail about how to configure and use it here in common ASP.NET project.
The bad news is the technique is only built-in for web.config for ASP.NET Web Project, not others like Windows Form, Console App, etc.!
The good news is we can do some trick to make it works. The idea is to perform some modifications on its project file as illustrated in this post.
Since SDK 1.5 (if I remember correctly), VS Tools for Windows Azure enables us to select service configuration and build configuration.
Service Configuration is essentially configuration for Windows Azure services. You can have two or more different configurations, let say one for local (ServiceConfiguration.Local.cscfg) and another one for cloud environment (ServiceConfiguration.Cloud.cscfg).
Build configuration is either your web.config (for Web Role) and app.config (for Worker Role). Let say one for debug (Web.Debug.config) and another one for release (Web.Release.config).
For web.config, it certainly works well. Unfortunately, it doesn’t applicable for app.config (Worker Role project) . Although if you try to apply the technique above to your App.config inside your Worker Role, it still won’t work.
That is the reason why I am writing this article .
The idea is utilizing an Visual Studio add-on SlowCheetah – XML Transforms to help us perform xml transformation. This is an awesome tools (not only for Windows Azure project) that can help us add and preview applicable on config. Thanks to JianBo for recommending me this tool!
Let’s see how it will be done …
1. Download and install SlowCheetah – XML Transforms. You might need to restart your Visual Studio after the installation.
2. Prepare your Windows Azure Worker Role project. I named my Windows Azure project: WindowsAzureWorkerConfigDemo and my Worker Role: WorkerRole1.
3. Open the app.config file and add the following value:
<?xml version="1.0" encoding="utf-8" ?> <configuration> <appSettings> <add key="setting1" value="original"/> </appSettings> <system.diagnostics> <trace> <listeners> <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=184.108.40.206,Culture=neutral,PublicKeyToken=31bf3856ad364e35" name="AzureDiagnostics"> <filter type="" /> </add> </listeners> </trace> </system.diagnostics> </configuration>
Remember to save the file after adding that value.
4. Right-click on app.config and select Add Transform. (This Add Transform menu will only appear if you’ve successfully install the SlowCheetah). If Visual Studio prompts you for Add Transform Project Import, click on Yes to proceed.
5. You will then see there are children file (app.Debug.config and app.Release.config) below your app.config.
6. Double-click on the app.Release.config and add the following snippet:
<?xml version="1.0" encoding="utf-8" ?> <!-- For more information on using transformations see the web.config examples at http://go.microsoft.com/fwlink/?LinkId=214134. --> <configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> <appSettings> <add key="setting1" value="new value" xdt:Transform="SetAttributes" xdt:Locator="Match(key)" /> </appSettings> </configuration>
As you could see, I’ve change the value of setting1 into “new value”.
The “xdt:Transform=SetAttributes” indicates that the action that will be perform. In this case, it sets the attribute of the entry.
The “xdt:Locator=”Match(key)” indicates the condition when it will be perform. In this case, when the “key” is matched.
You can refer to this post to see what are the other possible values for xdt:Transform and xdt:Locator.
Remember to save the file after adding the settings.
7. Now, right-click on the app.Release.config and click on Preview Transform. (Again: it will be only appeared if SlowCheetah is properly installed).
8. Now, you can see the comparison between the original app.config and app.Release.config.
9. Right-click your Windows Azure project and click “Unload Project”. Right-click on it again and select Edit [your Windows Azure project].ccproj file.
10. Scroll down to the end of the file and add the following snippet before the closing tag of project.
<Import Project="$(CloudExtensionsDir)Microsoft.WindowsAzure.targets" /> <Target Name="CopyWorkerRoleConfigurations" BeforeTargets="AfterPackageComputeService"> <Copy SourceFiles="..WorkerRole1bin$(Configuration)WorkerRole1.dll.config" DestinationFolder="$(IntermediateOutputPath)WorkerRole1" OverwriteReadOnlyFiles="true" /> </Target> </Project>
What it does is basically performing a task each time before packaging the Windows Azure service. The task is to copy the WorkerRole1.dll.config file to the IntermediateOutputPath.
Save and close the file. Right-click and select Reload Project again on the Windows Azure project.
11. Alright, we should package it now and see if it really works. To do that, right-click on Windows Azure project and select Package. Choose Release for the build configuration. Click on Package to package the file.
When Release is selected, we expect the value of “setting1” would be “new value” as we set inside the app.Release.config.
As the service is successfully packaged, you can see two files as usual (one is ServiceConfiguration.Cloud.cscfg and another one is WindowsAzureWorkerConfigDemo.cspkg).
To verify the correct configuration is included, change the extension of the cspkg file into .zip and unzip it. Inside the directory, look for the biggest size file (start with WorkerRole1, since I name my Worker Role project “WorkerRole1”).
Change its extension to .zip and unzip it again. Navigate inside that directory and look for “approot” directory. You could see the WorkerRole1.dll.config file inside.
13. Open that file and check out if it’s the correct value, set in our “release” build.
Mine is correct, how about yours?