Skip to main content

Azure Cloud Services (Day 22 of 31)

List of all posts from this series: http://vunvulearadu.blogspot.ro/2014/11/azure-blog-post-marathon-is-ready-to.html

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.

Limitations 
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 
Pros

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

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

Pricing
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


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

Comments

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP