Big News: FounderDating is joining OneVest to build the largest community for entrepreneurs. Details here
Latest Notifications
You have no recent recommendations.
Name
Title
 
MiniBio
FOLLOW
Title
 Followers
FOLLOW TOPIC

Question goes here

1,300 Followers

  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur

Approximating compute costs for a mobile app

I am working on a location driven mobile app. I am trying to approximate the costs of running such a thing on top of AWS or Rackspace and clearly there are very many guesswork parameters involved with respect to adoption, usage, geographies etc. Does anyone have a high-high level, back of the envelope, off the top of your head, way to approximate how much money you'd need to set aside to "assure" that your mobile app doesn't run out of compute power in year 1 ? Underlying assumptions: (1) low I/O rates (2) decent non-greedy design (3) supporting 1M users by the end of that time frame (optimism is key =)
Thanks!
Ori

24 Replies

Michael Barnathan
2
0
Michael Barnathan Entrepreneur • Advisor
Co-Founder of The Mountaintop Program, Google Alum
The answer is "it all depends on the app". A properly configured dedicated nginx/Apache web server can typically serve 5k-10k concurrent requests for static content with acceptable (second-range) latencies. That's likely to be an optimal case - dynamic content (e.g. app backends) will tax systems more. I've also noticed that many PaaS services such as Heroku and AppEngine have far less concurrency per worker, probably because they run your server in a single process (whereas a dedicated webserver can spawn workers).

There are a few measures which have become more or less standard practices - offloading your static assets to a CDN is a good low-cost way to eliminate bottlenecking there. Load balancing will become necessary once you grow past a certain point. Aggressive caching where you can do it (via a very fast cache, e.g. Varnish) will help save on the raw number of requests that reach the backend.

My suggestion is to start building the prototype with a design that will be easy to scale (such as REST, which distributes very nicely due to the stateless nature of REST requests). Do some load testing once it reaches prototype phase - there are tools like "ab" which can do quick benchmarks, or more professional ones such as Blitz.io which will simulate geographically distributed load for you. Figure out how many users you can realistically expect, then plan for that.

Don't prematurely scale (it's expensive and risky until you have evidence that you can get the customers), but do try to design your software architecture so that you can scale when necessary without having to rewrite half of your app.
Roger Smith
0
0
Roger Smith Entrepreneur
Chief Technology Officer at RealtyClub Investment Advisors
Why not try running on parse.com.
Andrew Donoho
1
0
Andrew Donoho Entrepreneur • Advisor
President at Donoho Design Group, LLC
Ori,
We implemented the Austin, TX Startup Crawl app on top of Parse.com, http://bit.ly/StartupCrawlApp. As it is/was a one day event, we were not particularly frugal with our location based messages. Frankly, by spending $200/month on Parse, we can say you'l spend $2,400/year. It is really hard to build a 24x7 hosted solution as cheaply as that. If you out grow Parse, then you have the happy problem of migrating to your own infrastructure. But You will have to significantly overload Parse for that to become economically feasible.
Anon,
Andrew
Kyle Giddens
0
0
Kyle Giddens Entrepreneur
CEO at Trendi Guru
Check out cloudyn and they really know their stuff. Tell them Kyle Giddens recommended their services Www.cloudyn.com . Feel free to call or contact me if you have any questions.
Will Koffel
1
0
Will Koffel Entrepreneur • Advisor
Co-Founder at Outlearn
Michael's answer is great, Ori.

One major consideration is the data side of things. Compute resources are relatively cheap, and you can scale them up and down to meet need. So start with a couple of m1.medium instances, perhaps, and see how they fare based on the needs of the application.

I large site I run on AWS uses about 12 m1.large instances running PHP, processing about 1000 API calls per second to mobile apps, just to give you one concrete measure of scale. And I wouldn't say it's particularly optimized, it's doing quite a bit of work per request.

But the database is where things get tricky. Both because you need additional redundancy in a way that you don't with the application servers (essentially two copies of your DB, Multi-AZ RDS, or whatever is equivalent for you). And because the database typically can't scale up and down with traffic. So you'll end up paying a bit more than you need to at the beginning out of fear of not having to shut it down to resize every time you hit a new capacity threshold.

Most small companies (< 1M users) don't do any sort of auto-scaling (meaning, spinning up and down resources during the day, so you have more capacity at peak hours and less over night), but if you really are trying to save cash, you can go that route. Typically, the developer resources to build a stable effective auto-scaling solution aren't worth it, unless you get it "for free" via another platform layer (like parse.com, rightscale, etc.)

But heed what Michael says, don't worry too much about scale early on. Spend more time making sure that your mobile application is flexible, well-behaved, can take behavior hints from the server, has the ability to enable/disable features of the app remotely. That stuff will buy you flexibility to scale server-side as your needs demand.
Praneeth Patlola
1
0
Praneeth Patlola Entrepreneur
CEO at Jobhuk
We recently did something similar to help a founder finish estimation for bplan. It is going to be almost impossible to come up with even a ballpark number with out having the actual app built out, as your tech stack would define what horse power you might need. Eg: How many background tasks or application specific requests to be handled. Your cost would be directly related to how many "concurrent users" you would have on your app, which would need Here is a sample of our exercise: iOS app targeted with API built out in Rails. These number might be more conservative. Below numbers are baselined for AWS and Rackspace would come down to the same numbers. If you have strong Devops/Engineering talent onboard, your can use Linode or Digital ocean to built out most of the below for 20% less cost. You also might want to consider costs for Email delivery (sendgrid) and File store cost (S3). To get more actual numbers, it is highly recommended to do LoadTest to see the scalability work in realtime. No of concurrent Users 100 1000 5000 10000 No of App Servers No of App Servers No of App Servers No of App Servers Webservers 1 10 50 100 App Servers 10 100 500 1000 Caching Server 2 20 100 200 DB Servers 2 20 100 200 LoadBalancer 1 10 50 100 Background Task Servers 1 10 50 100 XXXXXX app specific Processing Servers 2 20 100 200 Total (per month) $1,048.08 $10,480.80 $52,404.00 $1,048,080.00 A good place to start out is here for AWS: http://calculator.s3.amazonaws.com/calc5.html Praneeth Patlola Founder/CEO Jobhuk.com CrowdSourced Hiring Marketplace @praneethpatlola 512 963 3956
Praneeth Patlola
2
0
Praneeth Patlola Entrepreneur
CEO at Jobhuk
Looks like my copy/paste of xls did not work. here is the link to the same just in case, hoping it might be helpful. https://docs.google.com/spreadsheet/ccc?key=0ArIwDV0ArmvQdHRrTElFUVRWZ1ZJcVJFY2JseGZrV1E&usp=sharing
Bill Snapper
0
0
Bill Snapper Entrepreneur
Owner Principal at SammyCO, LLC
Peaneeth, did I read the spreadsheet correctly in that the jump from 5000 to 10,000 concurrent users the cost goes up from approx $50k / month to $1m / month?
Todd Ellermann
1
0
Todd Ellermann Entrepreneur
Experienced I.T. Leader, CTO, and Creative Entrepreneur
Here at VT we have a little over 1 Million registered users, but the real question for load, is how many will log in at a given time.... we run 100-200 concurrent member sessions but most of our load comes from researchers. 5-8 million/month.

I think you should budget an average of 2000/month per 25 concurrent users. BTW 100 concurrent users is generally about 1 million registered users. This may vary widely with application profile, B2C vs B2B etc... Our group mobile photo sharing application has a much higher cost and load because of all the photos we are shipping up and down, but the users only fire it up for a week or two once or twice a year.

Bottom line you aren't going to start with that load. Budget $20,000 in the first year and you will likely have extra to play with. If you don't, you are having success and revenue to cover the difference. :)
-T
Gil Benton
2
0
Gil Benton Entrepreneur
Entrepreneur
Very High Level- AWS will be a good way to go, and yes there are tons of parameters which could affect the cost of the hosting. AWS has a great pricing tool, but there will be some dimensions that you just may not know. I was running a mobile application company and we priced out a HUGE project for the government. We were WAY over estimating, and we couldn't even get our hosting costs above $20k / month. Having said that, you could easily support a simple app for much less. $2500 / month would get you some really substantial power, and the beauty is you can just grow your hosting with your success. Meaning, buy what you can afford in the beginning. As your number of users grow, or your hosting needs grow (I/O, data, backup, disaster recovery, etc), you can just ramp up your AWS services. It is NOT "click of a button" easy, but it is certainly easier than having your own machines, own data center, doing your own monitoring, backup, disaster recovery, etc. I would call AWS support, or go to their online pricing tool, and you can get within a few hundred bucks per month of your needs, even if you don't know the details of what you need. Just over estimate a little to be safe, but the pricing wont change that much. Gil
Join FounderDating to participate in the discussion
Nothing gets posted to LinkedIn and your information will not be shared.

Just a few more details please.

DO: Start a discussion, share a resource, or ask a question related to entrepreneurship.
DON'T: Post about prohibited topics such as recruiting, cofounder wanted, check out my product
or feedback on the FD site (you can send this to us directly info@founderdating.com).
See the Community Code of Conduct for more details.

Title

Give your question or discussion topic a great title, make it catchy and succinct.

Details

Make sure what you're about to say is specific and relevant - you'll get better responses.

Topics

Tag your discussion so you get more relevant responses.

Question goes here

1,300 Followers

  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
Know someone who should answer this question? Enter their email below
Stay current and follow these discussion topics?