Skip to main content

Scalability points on Cloud

Cloud - another buzz word that we hear almost every day. For the moment the providers that offer this service are: Amazon, Microsoft (Windows Azure), Google, Rackspace.
When we think about cloud what comes to our mind? One, two or more instances that we keep on the cloud and when we need more resources we can grow very easy the number of instances.
At the moment a cloud provider like Microsoft gives use some scalability points. In this article we will find out how to create a scalable cloud application and how to use the services that Windows Azure provide us.
Content Delivery NetworkLet’s say that we have a web application that has a lot of static content. When we say static content we think about images, CSS, HTML that doesn’t change every second (at every request). Normally when we observe that the loading on our machines is quite high we will try to increase the instance number. This seems to be a good idea for our problem, but in terms of cost it might not be the best.
Even though we try to make some cache at the server content (through IIS or other methods) all the request will still reach to our machines. That’s why for every request they will have to respond and so we consume our available resources.
A solution for this case may be using Content Delivery Network (CDN). Through this service the static content can be cached on different CDN’s depending on the physical location of the client. All the requests for this kind of content will be solved by the CDN’s. Normally a CDN can handle only static content, but newer version of CDN can also handle a dynamic content. This service is also provided by Windows Azure and can be easily integrated in our applications.
By using this kind of content delivery mechanism our machines that host our application will not be hit at every resource request. Automatically the load level will decrease.
Cache
The next place in our application where we can easily introduce a scalability point is the cache. To avoid making numerous requests to external services or to recalculate different parameters, we can use a cache mechanism.
Windows Azure provides this service in different ways. The advantage of using a service to cache dates is in the moment when we need to scale the cache mechanism and we don’t have to buy a machine, licenses or to synchronize this nodes.
Currently when we create machine with Windows Azure we can specify how much RAM to be allocated to the cache. Another caching system is to create some dedicated machines for this where the entire RAM will be allocated for caching. In both cases synchronize data between two and more instances cache instances is natively supported. These settings are made before deploying the solution.
The third option available is to use a dedicated cache service. In this case, we don’t have to manage our instances; these resources are entirely seen as a service. 
Using a caching mechanism of this kind takes off the problems that can occur in traditional caching mechanism.  Problems like synchronization or adding a new cache node disappear.
Video stream
Until now we managed to analyze two classic problems that appear on every web application. But what can we do if we need a video stream? As we all know this thing is extremely costly not only in terms of resources consumed on the server side and the internet band.
Normally we can have machines to handle the video streaming. The moments when we have a lot of active users can cause us some pretty big problems. For this situation Windows Azure helps us with a dedicated service. Windows Media Services handles completely the video streaming starting with the encoding and ending with the encryption and delivering the content (offline and online).
This service frees our instances which would have had to handle the delivering and processing part. Being a dedicated service for this the scalability is ensured from the start.
Web services
Until now we’ve seen three methods where we can scale using different cloud services without the need of increasing the number instances. Depending on the application we can expose different web service that collects various information from the clients.
What can we do if there are times when a big number of clients wants to connect to us? Usually we would try to allocate a bigger number of instances to handle this.
One solution that Windows Azure offers is Service Bus Relay. Through this service we can expose any web service of type “fire and forget”. All requests will be store in the form of message and our service will be able to process them anytime. Even though the number of requests increases greatly, the service will be always available.
Windows Azure Service Bus Relay can be easily integrated in our application. The only change you need to do on your application that uses WCF is altering the configuration file.
Communication between instances
Generally when we have a complex application we will have different types of machines on which will run different components of our application. It will be necessary to ensure a persistent and independent way of communication between this instances.
We can try to implement a communication system through a database or through another instance to handle only this thing. When we will have to scale it will be necessary to think about a way of resolving issues like synchronization between instances.
 Windows Azure comes in our help by providing different ways of sending messages. All this services are accessed using a URL and can be accessed from anywhere on the Internet.
 Most basic service, but also with the lowest cost is the Windows Azure Queues. This queue allows us to distribute messages in a very simple, quick and cheap way. If we have to distribute messages to more consumers, to have support for death-letters or to guaranty the message order than we have to work with Windows Azure Bus Queues and/or Windows Azure Service Bus Topics.
Data transmission
A client-server application could mean a permanent exchange of data. Many times this thing mean exposure of various web services through which our clients can execute queries on a database. In this cases our application will have to contain instances that expose this service and a database (relational or non-relational). Besides keeping this instances we will also have to deal with the maintenance of the web services.
In such cases we imagine our system from another point of view. We can stock and expose dates through Windows Azure Table Storage Service. This non-relational tables allows us to stock hundreds of GB of content without any problems.
When we want to use such a solution we may end up with two questions: what information can access each client and audit. Through some tokens which we can generate for each client we can define what content the customer has access, what kind of operations can perform and how long a token is valid. This functionality is called Shared Access Signature and allows us to eliminate from the equation the instances that should offer data to the customers. These tables should not show how we internally store our data, but the data that we want to offer our customers.
Windows Azure Storage Service natively supports the audit, all we have to do is to activate it and to specify what kind of operation we want to do audit.
Using such a solution we will need to have a component to handle the generation and management of these tokens. We don’t need other components.
Conclusion
We analyzed different ways in which we can make our application scalable. Starting with different cache systems or systems for sending messages, to services that allows us to do video streaming without raising any problems of allocation or security.
The most important thing that we have to do when we think on a cloud application is to try to identify all the points where we need scaling and to look for services that can offer this. If we need features that are not already on the cloud we find it is better to separate them on different instance or at least different processes. If we will need to scale it will be easier for us to increase the number of instances that deal with a specific function.
Today a cloud solution means more than several machines running our application with a load balancer – horizontal scalability. Cloud means a multitude of services that come to our aid to create more complex applications and to scale where we need.

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

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 http://go.microsoft.com/fwlink/?LinkId=260882 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.51 EF 6.0.2 VS2013 It see