Skip to main content

Azure Cloud Services (Day 22 of 31)

List of all posts from this series:

Short Description 
Imagine a world where everything is managed by cloud (from network, to load balancer or operating system). Using Azure Cloud Services we are a step closer to this dream, companies can focus on their product and less on infrastructure. We only need to develop our system and deployed it (more or less :-)).
A definition that I really it from the pricing web page of Azure Cloud Services:
Azure Cloud Services eliminates the need to manage server infrastructure and helps you quickly build, deploy and manage modern applications.
In general a system contains one or more layers divided on different nodes. Nowadays a system contain one or more web sites and a group of system for backend processing – multi tier application. Azure Cloud Services manage everything that is under our Web Roles and Worker Roles. We only need to create the deployment packages of our web&worker roles. The rest will be managed by cloud.

Main Features 
System Upgrades without interruption
As long as we have at least two instances for each node (web/worker role), Azure is able to upgrade the system and execute maintaining actions without service interruption.
Software and Hardware recovery
As above, as long as we have two instances for each node, Azure system can recover from failures without service interruptions.
99.95 Uptime
(3rd time) As as above, as long we have two instances for each node we have a SLA for uptime for our services of 99.95%.
Multiple environments
For each Azure Cloud Service we have two environments available

  • Staging 
  • Production

This two environments are in two different sandbox, having their own configuration. Switching between them can be made in real time, without affecting our service availability.
Azure Diagnostics
Azure Cloud Services allow us to use Azure Diagnostics to collect diagnostic information from applications that are running in cloud.
Support different technologies
Don’t expect to be able to use only C# to write applications. You can write your application in almost any language, from Java and Node.js to PHP and Ruby.
Auto scale
We have auto scale support that allow us to scale up and down the number of instance that we need for each service very easily.
Scaling to 1000 instances in one minute
Using Azure Cloud Services we can deploy 1K instances in 1 minute.
Load Balancer
An out of the box load balancing system distribute the load on our system.
Reserved IP
If needed, you are allowed to reserve a static IP that will be used by your deployment.
Different machine configuration
You can use any kind of machine configuration from A series, that are for general use to D series, like a D14 that has 16 CPU Cores and 112 GB RAM.

We cannot add Virtual Machines under Azure Cloud Services, but in the end we should not need them. Azure Cloud is focused on applications not on infrastructure.

Applicable Use Cases 
Below you can find some use cases when I would use Azure Cloud Services.
e-Commerce Application
I would use Azure Cloud Services in an e-Commerce application that contains multiple nodes, entities with different states and so on. I don’t want in a system that needs uptime greater than 99.9% to start to manage the infrastructure by my own. On top of this staging can be very helpful, not only for testing but also when we need to rollback to an older version of the product – using Azure Cloud Services this can be done very fast.
Document Converter
If you have a web application that converts files from one type to another than Azure Cloud Service is the best solution for you. Why? Uptimes SLAs + auto scaling that can reduce not only the cost but also can improve the happiness of your clients.
Online Archive System
A company that offers a service like this needs a lot of CPU power. This power is not required all the time. Because of this, in the moment when the load increase, we need a system that can scale from 2 instances to 1.000 instances very fast. A system like Azure Cloud Services can be very useful.

Code Sample 

Pros and Cons 

  • Can scale from 2 to 1.000 instances in 1 minute
  • Auto scaling 
  • 99.95% uptime by SLA 

In combination with other cloud services like messaging system or storage, the overall application uptime decrease. But this is a general problem for all systems that use different external services (also on-premises we have the same problem).

The pricing is based on what kind of ‘horse’ (machine) you need (more CPU, more RAM), but when you calculate the costs you should take into account the following:

  • Number of instances
  • Type of each machine used to run the application node
  • Outbound traffic

Azure Cloud Services can be useful when you need good SLA for your application. Having such SLAs even for deployment for 1.000 instances is a great think.


Popular posts from this blog

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Entity Framework (EF) TransactionScope vs Database.BeginTransaction

In today blog post we will talk a little about a new feature that is available on EF6+ related to Transactions.
Until now, when we had to use transaction we used ‘TransactionScope’. It works great and I would say that is something that is now in our blood.
using (var scope = new TransactionScope(TransactionScopeOption.Required)) { using (SqlConnection conn = new SqlConnection("...")) { conn.Open(); SqlCommand sqlCommand = new SqlCommand(); sqlCommand.Connection = conn; sqlCommand.CommandText = ... sqlCommand.ExecuteNonQuery(); ... } scope.Complete(); } Starting with EF6.0 we have a new way to work with transactions. The new approach is based on Database.BeginTransaction(), Database.Rollback(), Database.Commit(). Yes, no more TransactionScope.
In the followi…

GET call of REST API that contains '/'-slash character in the value of a parameter

Let’s assume that we have the following scenario: I have a public HTTP endpoint and I need to post some content using GET command. One of the parameters contains special characters like “\” and “/”. If the endpoint is an ApiController than you may have problems if you encode the parameter using the http encoder.
using (var httpClient = new HttpClient()) { httpClient.BaseAddress = baseUrl; Task<HttpResponseMessage> response = httpClient.GetAsync(string.Format("api/foo/{0}", "qwert/qwerqwer"))); response.Wait(); response.Result.EnsureSuccessStatusCode(); } One possible solution would be to encode the query parameter using UrlTokenEncode method of HttpServerUtility class and GetBytes method ofUTF8. In this way you would get the array of bytes of the parameter and encode them as a url token.
The following code show to you how you could write the encode and decode methods.