Introduction

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.

Would you rather buy or rent a car?

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?

Buy Your Own 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.

Renting a Car

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.

Translating the Analogy to Cloud Computing

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.

Characteristics of Cloud Computing

This summarizes the characteristics of cloud computing.

• On-demand

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.

• Scalable

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.

• Multi-tenant

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.

• Self-service computation and storage resource

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.

• Reliability

Cloud provider should be able to provide customer reliability service, committing to uptimes of their service.

• Utility-based subscription

You will pay the cloud provider as a utility based subscription, just like paying your electricity bill – without any upfront investment.

Cloud Computing Service Model

Cloud Computing consists of several type of service models.

• On-premise Environment
  As you can see, for the first stack from left, you will need to take care of everything from networking all the way up to applications. This is typically what many of us are doing today.

• IaaS (Infrastructure as a Service)
  IaaS helps you to take care of some of the components, starting from networking to provisioning the OS. But you are responsible for the middleware, runtime, data, and application. Sometimes IaaS vendors will just provide the OS but will not manage updates or patches for you. You basically just rent the virtual machine (VM) with the preferred OS installed. They won’t care what you do with the VM.
  Example of IaaS market players: Amazon Web Service, Rackspace, and VMware vCloud.

• PaaS (Platform as a Service)
  Paas is one level up from IaaS, where cloud providers not only take care of the components that IaaS does; but also manage the platform-level components like middleware and runtime. Middleware such as applications / web server (IIS, JBoss, Tomcat, etc.) and runtime (.NET Framework, Java runtime) will be pre-installed. As a customer, you just need to focus on managing application and data.
  Example of PaaS market player: Google AppEngine, Windows Azure Platform, andforce.com.

• SaaS (Software as a Service)
  SaaS is probably the most common one as we may have been using it, unaware that they are actually cloud services. SaaS takes care of all the stacks from networking to application level. You don’t even manage the application and data storage. All you need to do is to use the system.
  Example of SaaS market player: GMail, Office 365, and Google Docs.

Cloud Computing Deployment Model

There are three main cloud deployment models, each on with its own set of customers it’s targeting.

• Public Cloud
  Public cloud provider refers to the cloud platform that targets any types of customers, regardless of whether they’re an independent consumer, enterprise, or even public sector. Normally, public cloud providers are considered prominent players which have invested huge amount of capital. Windows Azure Platform by Microsoft, AWS by Amazon, AppEngine and Gmail by Google, etc. are all examples of public cloud services. Customers who possess sensitive data and application normally do not feel comfortable using public cloud due to privacy, policy, and security concerns. Remember, for public cloud, the application and data will be stored in the provider’s data center.

• Private Cloud
  Private cloud is infrastructure that’s hosted internally, targeting specific customers or sometimes exclusively within an organization. Setting up a private cloud is normally more affordable when compared to a public cloud. As the matter of fact, there are many organizations who have implemented their own private cloud system with product offering from vendors such as IBM, HP, Microsoft, and so on. Customers who possess sensitive data and application feel more comfortable going with this approach since the data and application are hosted privately.

• Hybrid Cloud
  Hybrid cloud is the combination of public and private clouds, or sometimes on-premise services. Customers who look into this solution generally want to utilize the scalability and cost-competitiveness that public cloud providers offer, but also want to retain their sensitive data on-premise or in a private cloud. With the benefits derived from both deployment models, the hybrid model solution has become more popular nowadays.

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.

Background

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.

Transforming App.Config with some trick

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.

Config Transformation in Windows Azure

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).

App.Config in Windows Azure Worker Role

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 .

Using SlowCheetah – XML Transforms

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!

How to?

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=1.0.0.0,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.

12. Verification

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?