By Michael Woloszynowicz

By Michael Woloszynowicz

Thursday, November 4, 2010

A Startup's Guide to Application Scaling

A common concern among startup founders and application architects is "when do I start worrying about scalability?". Is it something that you need to start worrying about right away, or can you put it off for a bit? It's surely a question that every VC will ask you during a pitch presentation so you better have a good answer right? The fact is that writing a highly scalable application takes considerably longer than one that runs off a single application server, otherwise there would be no debate, just make it scalable from the outset. The greatest problem is that as a startup you don't how successful your product will be so why spend your precious time and money with scalability when you could be releasing a product quickly and testing for market acceptance. After all, scalability only has value if someone is actually using your product. The lean startup methodology suggests that we build a minimum viable product (MVP) to test for problem-solution and product-market fit and since we include the term "minimum" it is certainly implied that we not dedicate too much time to scalability. As I've noted in my previous post, the MVP doesn't even have to be a functioning product so let's look specifically at a working prototype. Once again it would be presumptuous to assume a need for scalability at the prototype stage, but is there a middle ground that we can take? What if your MVP's validate your hypothesis and confirm a strong market need for your offering, should you spend longer developing a scalable initial product or should you get it to market ASAP? I will return to these question in a moment, but first a brief digression.

The first thing to consider is the type of application your are building, or more spacifically the revenue model for your application. Will it be a viral application where revenue is generated by ad sales from a growth in your user base, or do you follow a traditional paid subscription model? Regardless of the model your application will still need to scale at some point, but if it is of the viral sort then you may have a lot less time to react. As we know, viral applications follow a hockey stick curve and once the user base starts growing it will do so at a rapid rate. When this happens you better be able to scale quickly or at least have a very endearing fail whale to placate your users. On the flip side, since viral applications are typically free, users are a little more tolerant of downtime (unless you provide a critical service like GMAIL), while paid subscription users expect a good degree of stability for their monthly fee.

So how do you handle scalability when you don't know if you'll ever need it. The answer lies in the fundamental principles of application programming. You needn't build a distributed system from the outset but what you should do is make it as easy as possible to implement scalability when the time comes. To achieve this your programmers should adhere to the following:
  • A Model-View-Controller (MVC) architecture
  • A well defined service level (this is one of the most important elements)
  • Object oriented design patterns such as Facades, Adapters, Factories, Abstraction, and Proxies
  • Loose coupling of application components (e.g. a Mediator design pattern)
Although these principles should be followed across your entire application, they are particularly crucial for services that are resource intensive, or those that access a shared resource. Resource intensive operations become excellent candidates for distributed computing as they can be offloaded to a separate web or cloud server quite easily to regain precious computing resources needed to host the remainder of your application. Shared resources on the other hand pose a problem once you decide to scale horizontally and load balance your web servers as the resource may have to be duplicated on each server if it is not decoupled. The best example of this is user file storage in a web application. If your application stores files on the same server that hosts your application, you would have to replicate these files in real-time if you wanted to run your application off two or more servers. By using the above rules you ensure that you can easily offload file storage to another server or a cloud service such as Amazon S3. At this point all that is needed is for your factory method to return a new IO class that communicates with a web service rather than the native file system. 

Once you have a strong application architecture you have to make metrics your religion. Monitor as much as you can and plot these metrics against your user growth. Estimate how many users your current architecture can support and combine it with your growth rate to see how much time you have. As you gain more traction your proposition to investors will become that much more appealing. If they ask you how your application scales you can at least tell them that it's been designed with scalability in mind and that the funding they provide will in part go towards handling your rapidly expanding user base. Your short term solution is always a faster server, a separate database server (if you don't already have one), or clustered DB servers which are easy to setup and generally don't require many application code changes (provided you have a good data access layer).

Regardless of the steps you take in scalability, an important thing to keep in mind is that application scaling cannot happen in a silo. It should be a holistic process that involves cross-functional teams throughout your organization. You may be able to scale your application but if your support or IT staff cannot then you still have a point of failure. If marketing decides to make a major sales initiative and your application isn't ready to handle the impending inflow of customers then you've not only wasted your advertising dollars but also risk loosing existing clients. The Flipboard launch was a classic example of technical and business units being completely out of sync. If you expect Ashton Kutcher to champion your product, you had better be able to scale from the outset. For those of us who aren't so lucky, a middle ground is usually enough. It's generally best to get your product into your customers hands as quickly as possible, but don't leave scalability as a complete afterthought. Invest a bit of extra time and make provisions for it from the outset so that when it is needed you can respond quickly without having to rewrite your entire application. If nothing else you'll have a well designed and robust application that you can maintain for years to come.

If you liked this post please follow me on Twitter for more

No comments:

Post a Comment