We’ve all heard the phrase “highly-scalable” when it comes to web apps. More and more apps are running in the cloud, and as a result scalability is becoming a crucial part of delivering a great experience to your customers, no matter how many there are.
What is a scalable web app?
A scalable web app is one that is able to smoothly handle an ever-increasing user base (or sudden increase in traffic, e.g., “slashdot effect”) without hiccups or performance issues. This growth does not require huge changes to the code or server architecture. If you have any suspicion at all that your cloud-based, SaaS app might gain a large number of users, this should be one of your biggest priorities while designing the architecture of your app.
It is easier than ever to build these kinds of apps because of the availability of cloud services such as Amazon AWS and Microsoft Azure. What’s crucial, however, is that the architecture of the app plays well with the platform you choose. In this article, we’ll look at what it takes to make a highly-scalable Microsoft Azure web app.
Scalable Coding
Unfortunately, scaling an app isn’t as easy as just cranking up the hardware specs on your server or running another instance when the load gets heavy. Increasing the hardware power has its limitations and can also be expensive (not to mention the server downtime that occurs when performing an upgrade).
Adding instances of your server is the way to go, but your server must support running multiple instances to begin with. This involves two important design decisions:
- Stateless Server Technology A “stateless” server is one that is not dependent on any data being stored in memory or even the file system. The best example of this is user login sessions. If a user logs into a server, the server should store a session token in the database and not in memory. If it is stored in memory, then when a second instance is started a user’s data might end up being split between the two instances of the server because of load balancing, and they may suddenly be logged out because the second instance may not be aware that the user is logged in on the first instance.If the session data is stored in the database, both instances of the server can query the database for the session token, so it won’t matter how many instances there are. Likewise, the data should never be stored on the local filesystem of the server (see below for why).
- Unrestricted and Highly Partitioned Databases The problem with using a traditional, locally hosted database for a rapidly growing app is that the database can only grow so far. If the app is heavy on user-uploaded content, this is particularly troublesome.Azure offers a Table Storage solution that entirely resolves this problem. Table Storage frees your mind of the need to worry about managing any instance of the database. The only important part of the integration is that the data is wisely partitioned. Each database entry is supplied a partition key in order to accomplish this.For example, if a web app is being made that allows users to upload photos to share with other people, it would be a great idea to partition the uploaded photos by the userId of the person uploading them. If the app explodes and terabytes of data are being uploaded to the server, Azure will automatically spread your database to multiple servers, but will keep data organized and contained by the partitions you have supplied (in this case, the userId) such that it should take roughly the same response time to fetch two photos uploaded by the same user. Table storage also has great blob storage options, so you can store not only traditional table entries but also unstructured data such as pictures and documents.
Beyond these two architectural decisions (a stateless server utilizing a limitless database), it doesn’t hurt that the server itself is highly asynchronous and able to handle a lot of simultaneous requests. NodeJS is great at this and the integration options with Azure are excellent.
Choosing the Server Platform
After building your app to be stateless and utilizing Azure Table storage for all of your data, the next step is to select the particular Azure cloud platform you wish to use for your app. There are three major options to choose from: Azure VMs, Azure Web Apps, and Azure Cloud Services.
It’s important to note that on top of having a scalable platform with Azure, one of the things you can get for free is an Azure-maintained server. An Azure VM is still an option for scalability, but the VM must be set up and maintained with security updates and patches, much like a physical server running in your garage (or datacenter).
An Azure Cloud Service is one step away from a VM. It is a highly scalable platform which you can still remotely log in to and make changes, but it is maintained by Microsoft and is not a persistent server. In other words, a particular instance might be destroyed and recreated at any point by Azure. This means you should not store any permanent data in the file system. A Cloud Service is a great option if you want to be free from server maintenance tasks but also need to be able to install third party software on your server (these can be installed via scripts that launch when the server is created).
Azure Webs Apps are on the opposite end of the spectrum from Azure VMs. An Azure Web App is a highly scalable environment that is totally managed by Microsoft and which you cannot remote desktop into. Web Apps are the way to go if your app does not utilize additional software that needs to be installed on the server. It can take a mere 5 minutes to create a web app, and one “git push” later, your code is running in the cloud! You can easily enable SSL for testing without having to go through the process of creating and uploading a test certificate, and there’s a great console for viewing server logs.
Say “Goodbye” to Server Downtime
Another benefit of using either an Azure Web App or an Azure Cloud Service is that updates to your app can be made without any server downtime whatsoever. A “staging” and a “production” slot can be designated. The updated code can be applied to the staging slot and, once you are satisfied that the update is stable, simply swap the two slots and traffic will begin to be directed to the staging slot, which has now become “production”. This also applies to scaling: add that extra instance without your customers ever knowing anything’s changed.
Scale It Up!
It’s clear that much work goes into the architecture of an app that is scalable. Design decisions made early on in the development process can directly determine how well your app will perform when the traffic hits the ceiling. Keeping the above tips in mind can help to greatly reduce the challenges that will come with a fast-growing app and let you focus on delivering an excellent, high-performance service to your customers.