September 30, 2016
If Dreams come true…. what would you rather be doing?
Scene 1: Catch a break to let the happiness and relief sink in, and go on to chase bigger goals with renewed enthusiasm.
Scene 2: You are caught unprepared! You struggle to avoid the infrastructure crashing from excessive user load. You have to put everything else on hold and divert your entire team to fire-fighting. You obviously find no time to sit back and savor the moment.
Being prepared is definitely preferable to being caught unawares. For this, app owners must think about scale early on, well before they might actually need it.
Before we set out to build an infinitely scalable application, let’s see what the problem looks like:
Your app currently serves about 10000 users and is running smoothly. But then a key influencer happens to blog/tweet about your app and you start getting a lot more traffic. With so many users accessing the app all at once, it starts to stall and becomes un-responsive. The application is running out of memory, computing power and network bandwidth. So, why can’t you just throw more resources it now? Let’s hear what Mike has to say about it:
Scaling an app is like replacing all the components of a car while driving it at 100mph. And you don’t get to choose when scaling challenges come up – Mike Krieger, Instagram
But adding resources on the go is easier if the app is built to scale from the beginning.
Mobile app development is more complicated when compared to web app development. In web app space, there are only two major Operating Systems (OSes), i.e., Windows and Mac (Linux is where majority of web app are deployed). But, the mobile app space has multiple OSes and device types each with different native hardware and software capabilities. App owners prefer native apps as they deliver a better user experience (UX). The first version of a mobile app is typically build using native development SDK. But this imposes restrictions and additional burdens as the code must be re-written for every new device type and OS (And there are so many of them! – Android, iOS, Blackberry and the list goes on).
Mobile apps also have additional requirements like coding for minimal network usage to optimize app performance. Graphics tend to slow down the app and should be minimized or removed for better performance. Also the amount of data that needs to move back and forth on a page needs to be minimized. Designing to reduce network requirements and lower number of roundtrips between server and device will optimize app performance and help in easy scalability.
Company 1: Follows a phased development model. For example, retailers usually develop for Android first to tap into a much larger customer pool. Likewise, publishing companies may opt only for iPad or android tablet apps as a larger screen lends a better UX. As the app gains popularity it may be extended across other device classes.
The first step towards a scalable mobile app is to define your scaling requirements correctly. The volume of information to be handled, concurrent access and session lengths need to be considered. For instance, displaying static information is vastly different from connecting a million people to exchange information in real-time.
Now let us put forth some key choices and steps that can make your app more scalable.
Scale up (vertically) runs the application on a stronger computer. This option will not require any change in software architecture but is not infinitely scalable. Bigger computers are costlier and eventually you will hit the upper limit on computing and memory power available on a single PC.
Scale out (horizontally) the app runs on several regular computers. If designed properly it can provide infinite scalability at a low cost. But design and development is slightly complicated.
Most startups use single server architecture for their minimum viable product (MVP). Hosting companies provide a replicated server for such plans but this architecture is still a big risk. In single server architecture, one server is hosting all of your code, database and files. Having a single point of failure is risky as you may lose some data. Scaling a single server architecture is not easy because servers with more cores and greater RAM capacity are costlier. Moving to a multi-server architecture isn’t easy either and current code needs to be re-written. The new code needs to allow hosting server(s) to reference files from file servers and database servers which need to be separated.
Multi-server architecture is designed with separate servers for database, code and content files right from beginning and is easier to scale. When there is a spike in users all you have to do is add more servers. Using a load balancer to distribute requests between the servers, distributes load and ensures efficiency is maintained. Load balancers also track traffic to initiate auto-scale and add new servers when traffic increases or CPU utilization crosses a particular threshold.
Startups should take advantage of the Pay-as-you-go model offered by public cloud vendors to keep costs low. Cloud architecture ensures scalability and brings down expenditure on IT provisioning. Additionally, small developer teams in startups can benefit from the managed services provided by cloud vendors.
A new software development paradigm, microservices architecture has gained in popularity in the last few years. It is particularly suited to cases where multiple platforms and devices need to be enabled, because the code can be re-used easily. Some of the globes largest customer-facing companies like Netflix, Amazon, Twitter and Paypal have already adopted this architectural model. Many more companies are moving away from monolithic architectures to microservices architecture.
A scalable application has good database architecture. Few things to keep in mind while designing your database for scaling:
Query Optimization: Check index usage and add new indexes to get better response time on slow-running queries. But maintaining balance is crucial as too many indexes can hurt performance. Look out for queries that place read/write locks on a table in your database. Such queries can slowdown performance.
Caching Servers: If you have queries returning the same data repeatedly then instead of accessing the database each time, it can be programmed to return the cached version from caching server. The caching server can update cached data at pre-set intervals (every 20-40secs). Using caching can reduce load in cases where users are repeating the same query multiple times in a second.
Lastly, if you still need additional capacity use one of these methods to scale your database
(a) Add replica servers (If your application is data-light and doesn’t store a lot of data per user)
(b) Sharding (If your application is data-heavy)
Optimizing your database to keep query response time low and capacity building for higher traffic will ensure database scalability when needed.
To ensure scalability of your server architecture use load balancers to distribute load across multiple servers. Another option is to use proxies like Nginx to distribute load. Your servers should be set up to return data to the client in a compressed format. This can ensure that users with low-bandwidth connections too can access queried information quickly. Luckily, most app servers and proxies are able to return data in a compressed format.
There are a few other important things that enable scalability:
Making your mobile application scalable will add to development costs and time. But, planning ahead and being ready will ensure you are ready for successful scaling.
Download your free eBook: An Introduction to 360 Degree Videos