Scaling from MVP to 10 Million Users
Starting a business is a challenge and it becomes more challenging when whole business just based on an idea with very little resources to build a very popular product. You don’t want to waste your time and money building a product no one will be interested in using or paying for. So the best approach is to build a Minimum Viable Product (MVP) and improve it with the feedback from potential users. Before we step into “How To ….. ” let’s have a bird’s eye view of limitations of startups and the challenges faced by almost each startup.
- High Competition
- Rapid Growth
- Fast Paced Marketing
- Tight Budget
- Time Constraints
- Limited Resources
The best way to meet the challenges with these typical limitations is to
“Fail Forward, Fail Fast and Fail Cheap.”
The cost of failure is the biggest obstacle even for small & medium sized business to experiment new ideas. The cost of failure increases significantly if failure couldn’t be predicted at earlier stages.
Cloud computing is the best platform to start from small and grow over the time with extensive experimentation-testing iterations incorporating the feedback from prospect users. This model is practiced in many technology giants including Amazon Web Services. The pricing model of Cloud Computing allows to keep the cost minimal because you only pay for what you use. Another benefit of using Cloud Computing to build an MVP is that Cloud Computing provides very useful suites of extensively tested Software as a Services which would significantly reduce the development time & cost.
With Cloud providers like Amazon Web Services a tech startup can have MVP ready from an idea withing hours or days by spinning an EC2 instance for single tier architecture using other ready to use services like Route53 & Elastic IP.
By now you have whole application stack including Application, Database and Web-Server on one EC2, providing the connectivity over the internet using Route53 & Elastic IP address. Depending upon application resource utilization you can serve up to 100 users concurrently using micro or small EC2 instances. A 100% identical development and testing stacks cloud be launched from the machine images of EC2, this will remove the configuration hell for different development & delivery phases.
With single tier architecture on AWS, we can achieve followings withing no time.
- Scale vertically (up or down) from micro to large instances
- Experiment application behavior with the different configurations using Optimized EC2 families.
- Identical stacks of publically & privately accessible application
- Rough cost estimations
But at this stage we have everything in the single bucket, without any failover and no redundancy. This architecture is harder to scale beyond certain points and complex to manage in the long run. After having fully tested and successfully running MVP on a single tier architecture its time to introduce the multi-tier architecture to separate database from application and webserver.
We can either run the database on a separate EC2 instance ( I recommend to choose Memory Optimized EC2 instance from R3 family if you want to stick with database installation on EC2 for greater control) or use AWS RDS. The best option in most of the cases is to use AWS Relationational Databases Services (RDS). RDS makes it easy to set up, operate, and scale a relational database in the cloud. It frees you time-consuming database administration tasks, allowing to focus on your applications and business. Amazon RDS provides you six familiar database engines to choose from, including Amazon Aurora, Oracle, Microsoft SQL Server, PostgreSQL, MySQL and MariaDB.
With our EC2-RDS architecture now we can add different levels of security to each layer i.e. putting the database behind private subnets and applying different security policies for each layer. In addition to that we can now scale each layer independently, RDs provide multi-availability zone option for failover.
Now let’s add the failover using AWS Elastic LoadBalancer (ELB). ELB automatically distributes incoming application traffic across multiple Amazon EC2 instances in the cloud. It enables you to achieve greater levels of fault tolerance in your applications, seamlessly providing the required amount of load balancing capacity needed to distribute application traffic.
With AWS ELB in place and automatic load balancing across multiple availability zones, we can server >1000 users based upon application optimization. Now we can add Amazon Auto Scaling for horizontal scalability to add more resources based upon our need. Auto Scaling helps you maintain application availability and allows you to scale your Amazon EC2 capacity up or down automatically according to conditions you define. It can also automatically increase the number of Amazon EC2 instances during demand spikes to maintain performance and decrease capacity during lulls to reduce costs. Auto Scaling is well suited both to applications that have stable demand patterns or that experience hourly, daily, or weekly variability in usage.
Using Amazon auto-scaling with elastic load balancer we can automatically scale as per our load requirements ensuring the high availability through ELB health checks. Using best auto-scaling and load balancing practices we can optimize our cost for highly scalable and highly available architecture and invest those savings to make our application more user-friendly.
At this stage we have highly available, secured and auto-scaling multi-layered architecture which can serve upto 100k users based upon application complexity and performance tuning. In order to achieve better performance let’s refine our simple architecture by adding very robust and fully managed services provided by AWS for web applications.
Let’s reduce the load on EC2 machines by separating web-tier from application tier and serving static contents from AWS Simple Storage Service (S3) and Amazon CloudFront (CDN) for delivery from edge locations near to user. In order to reduce the load on database servers let’s cache frequent queries and sessions on Amazon Elastic Cache.
We are now good to server up to 500k+ users but at this stage our architecture is quite complex to be managed by the small team and without proper monitoring, analyzing and optimization tools incorporation performance and speed issue would bar from moving forward. I would also suggest having good grasp on AWS Deployment and Management services like Elastic Beanstalk, OpsWorks, and CloudFormation.
In order to achieve our 1 million+ users target let’s use old divide and conquer rule to further optimize our application architecture using Service Oriented Architecture (SOA). Move services into their own tier and scale them independently or exploit the robustness of highly scalable Amazon Web Services like AWS SQS, AWS SNS, AWS SES and Amazon CloudSearch or ElasticSearch service. This would yield loosely coupled highly scalable architecture with independent components and black box design providing decoupled interactions. In addition to that we can use NoSQL databases like DynamoDB for document-based or key-value datastore for unstructured data.
In order to reach 5-10 million users requests we can introduce database federation by splitting data among different databases based upon functionality like User database, Product database and client database. Database sharding would also increase our ability to serve more users by splitting dataset into multiple hosts for uniform distribution of load.
Further scalability up to 100+ millions users could be achieved through application fine tuning, custom solutions, more decoupling, load balancing across the regions around the world.
Share This Post
This template supports the unlimited sidebar's widgets.
For adding widgets to Blog sidebar Click Here