Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Building a Web App Scalable To Hundreds of Thousand of Users?

Soulskill posted about a year ago | from the get-up-in-that-there-cloud dept.

Java 274

AleX122 writes "I have an idea for a web app. Things I know: I am not the first person with a brilliant idea. Many others 'inventors' failed and it may happen to me, but without trying the outcome will always be failure. That said, the project will be huge if successful. However, I currently do not have money needed to hire developers. I have pretty solid experience in Java, GWT, HTML, Hibernate/Eclipselink, SQL/PLSQL/Oracle. The downside is project nature. All applications I've developed to date were hosted on single server or in small cluster (2 tomcats with fail-over). The application, if I succeed, will have to serve thousands of users simultaneously. The userbase will come from all over the world. (Consider infrastructure requirements similar to a social network.) My questions: What technologies should I use now to ensure easy scaling for a future traffic increase? I need distributed processing and data storage. I would like to stick to open standards, so Google App Engine or a similar proprietary cloud solution isn't acceptable. Since I do not have the resources to hire a team of developers and I will be the first coder, it would be nice if technology used is Java related. However, when you have a hammer, everything looks like a nail, so I am open to technologies unrelated to Java."

cancel ×

274 comments

Sorry! There are no comments related to the filter you selected.

Cultivate Teams, Not Ideas (2, Insightful)

Anonymous Coward | about a year ago | (#43442743)

http://www.codinghorror.com/blog/2010/01/cultivate-teams-not-ideas.html

Re:Cultivate Teams, Not Ideas (1)

K. S. Kyosuke (729550) | about a year ago | (#43442767)

...unless you actually want to make any qualitative breakthrough. That would depend on ideas and individuals. But, yes, this is not likely to be a case for such approach.

Re:Cultivate Teams, Not Ideas (5, Funny)

crutchy (1949900) | about a year ago | (#43442955)

teams are much better at solving problems than individuals

even this slashdot forum could be thought of as a sort of team, in that many people are coming together to address a problem

ok there is no leadership and its full of trolls, shills and idiots... maybe it's not really a team... more like a committee... ok so you're probably doomed

Re:Cultivate Teams, Not Ideas (4, Funny)

phantomfive (622387) | about a year ago | (#43443145)

even this slashdot forum could be thought of as a sort of team, in that many people are coming together to address a problem

Good point. That's best argument against teams I've ever seen!

Re:Cultivate Teams, Not Ideas (1)

crutchy (1949900) | about a year ago | (#43443525)

you missed the next line

maybe it's not really a team... more like a committee

anyone who thinks highly of a committee needs their head examined

Re:Cultivate Teams, Not Ideas (4, Insightful)

MightyYar (622222) | about a year ago | (#43443077)

Yup, his best bet is to find a good dick-head business type to partner up with and spilt 50/50 (or less if necessary). Edison died famous and rich. Much smarter men have died penniless and frustrated. Find an Edison and be his Tesla - but be smart enough to stake your claim in black and white.

need more disclosure (0)

Anonymous Coward | about a year ago | (#43442769)

You've told us way too little for us to really help you. Also, you sound like one of those people who, ah, nevermind.

Re:need more disclosure (1)

jimmetry (1801872) | about a year ago | (#43443315)

people who what? PEOPLE WHO WHAT?! i need more disclosure *twitches*

Check out the Evergreen ILS's Opensrf project (2)

thirdpoliceman (1350013) | about a year ago | (#43442771)

http://evergreen-ils.org/opensrf.php [evergreen-ils.org] I do not know much about it. Here is Dan Scott's first paragraph form his 'Easing Gently into OpenSrf' article: OpenSRF is a message routing network that offers scalability and failover support for individual services and entire servers with minimal development and deployment overhead. You can use OpenSRF to build loosely-coupled applications that can be deployed on a single server or on clusters of geographically distributed servers using the same code and minimal configuration changes.

this will help (0)

Anonymous Coward | about a year ago | (#43442777)

http://www.rabbitmq.com/java-client.html

Re:this will help (2, Funny)

Anonymous Coward | about a year ago | (#43443475)

and vector graphics because they scale like a leprotic fish.

HAHA Ha ha ha haha. (-1, Flamebait)

VortexCortex (1117377) | about a year ago | (#43442779)

Oh, you're serious? Allow me to Laugh HARDER! HAHAHAHAHAHA!

Re:HAHA Ha ha ha haha. (0)

Anonymous Coward | about a year ago | (#43442907)

I know! He can fire up a Kickstarter page and jump right to "Profit!" without having to do a thing. Well, depends on how fast he runs...

Re:HAHA Ha ha ha haha. (1)

crutchy (1949900) | about a year ago | (#43442977)

if you were really laughing that hard at tfa, you really need to get out more

Re:HAHA Ha ha ha haha. (0, Troll)

Frosty Piss (770223) | about a year ago | (#43443337)

My friend, you are 18 and in junior college, right? It shows.

How can we help? (1)

Anonymous Coward | about a year ago | (#43442785)

Unfortunately I do not understand the requirements of your application. Scaling to thousands of users tells me nothing about where your bottlenecks are in terms of performance. What is your I/O requirements. How many users can you handle per server? Would a sharded database model work or how about an eventually consistent nosql database like Cassandra? Posting this here is honestly an exercise in futility.

Re:How can we help? (1)

Anonymous Coward | about a year ago | (#43442893)

Or, it's not an exercise in futility. I think AleX122 will quickly figure out that instead of trying to code this huge and wonderful project up by himself, try to find actual qualified coders to help for just a promise of a windfall, etc, his best bet may simply be to design it all and see what kind of patent protection he can get.

Besides, he will (or definitely should) design it all up before he starts coding. If he creates the design, he has something to protect, to show others to recruit, etc. One thing for certain is that posting that he has a nebulous idea and asking how he can realize step 4) Profit! is not going to get him very far on here.

I'd like to establish a moon base. I wonder where I can get engineers who will donate their time or work on a promise of greatness should we succeed?

Scala (1)

Anonymous Coward | about a year ago | (#43442787)

Learn Scala and use any of these great techologies: Play, Akka, Spray, Finagle

They are all high-quality tools designed for scale.

Re:Scala (0)

Anonymous Coward | about a year ago | (#43443123)

Right, because learning a bunch of new technologies guarantees you won't use them poorly!

Heroku (4, Insightful)

Anonymous Coward | about a year ago | (#43442791)

Just use Heroku. Honestly you DO NOT need to worry about this problem. If you don't make enough money by the time you get 10,000 users to hire someone to solve this problem for you then your idea is not as great as you think it is.

Re:Heroku (5, Informative)

Baby Duck (176251) | about a year ago | (#43442909)

OpenStack. You can start with a hosting provider like Rackspace that has as a faithful implementation of it. I know they were recently pinged for some incompatibility, but they have vowed to fix that. If you still can't stomach it, choose a different OpenStack provider. OpenStack is the key.

When you get really big, then you can work on running your own datacenter or paying someone to host the hardware for you (again, Rackspace, DreamHost, etc.). Then you can put your own implementation of OpenStack on the hardware with all the customization specific to your needs. This will naturally build on top of your years of investment with the vanilla OpenStack when you were smaller. The progression path is laid out for you.

I'm replying to this parent because Heroku is also an excellent choice for scaling where you pay as you grow. I'm just not sure if you can later fork Heroku to suit your needs with the datacenter supplier of your choice.

Re:Heroku (2)

gabereiser (1662967) | about a year ago | (#43443739)

I was gonna mention that worrying about scaling before the app is built is a waste of time. Build the app. Get to your capacity. Modify app. Grow some more. Iterate that several hundred times and you build as you grow, you bill as you grow, and you scale as you grow. Don't fret worrying about how to serve to millions before you've served to thousands.

Show me the users! (5, Insightful)

Anonymous Coward | about a year ago | (#43442793)

Before going all-out to reinvent the wheel on yet-another-next-big-thing web app, why not roll out a proof-of-principle version letting someone else competent do the "heavy lifting" back-end work. Use an existing cloud/hosting service like Amazon EC2 (they'll do a lot better on the basic back-end stuff than your "I'm incompetent but building a cloud app anyway" approach). After you get your first hundred thousand users, and have investment rolling in by the gazillions, then you hire your own crack team of cloud experts to design your own custom back-end solution (or just sell out for a couple hundred million to whatever group of suckers thinks your zero-dollar-per-user profit model will start paying off once they hit the million-user mark).

Re:Show me the users! (-1)

Anonymous Coward | about a year ago | (#43442837)

True words of a cynic who was born before 1999 ;-)

Re:Show me the users! (0)

Anonymous Coward | about a year ago | (#43443075)

So...hire 14-year-olds?

OT: "why not" (1)

Anonymous Coward | about a year ago | (#43443039)

Just a little advice for you, take it or leave it: when offering ideas try to state them in a positive constructive manner and stay away from negative phrases that put people on the defensive, like "why not." Anecdotal: when I was young and my managers called me a prodigy programmer half my colleagues absolutely hated my guts, that is until someone pointed out to me that I always "told people 'why not do this' and 'why not do that'." So I trained myself in avoiding those phrases and presto, I became a much-liked prodigy.

Re:OT: "why not" (3, Funny)

berashith (222128) | about a year ago | (#43443229)

Great advice. I see they helped you remain humble also

Re:OT: "why not" (5, Funny)

Anonymous Coward | about a year ago | (#43443407)

This. I have found it's best to avoid phrases like "why not shut the fuck up," "why not eat shit and die," and "why not stick your unsolicited advice up your ass." People do not react to these phrases as positive suggestions as intended, and they immediately go on the defensive. Instead, try sarcasm.

Re:Show me the users! (1)

buybuydandavis (644487) | about a year ago | (#43443245)

Sounds right to me. Protoype quickly. Don't worry about scaling. Get it out there and see if it works. If it does, then you worry about scalability.

Re:Show me the users! (5, Interesting)

ATMAvatar (648864) | about a year ago | (#43443429)

This. The submitter has made an assumption that there will be hundreds of thousands of users. There might not. The only sure thing is that if he spends all his time trying to build a platform capable of serving hundreds of thousands of users right out of the gate, the project will probably fail before a single user sees it.

Remember: not even Facebook, Twitter, or eBay started off with platforms capable of handling their current load. They all started with something quick and built things out as their respective user bases grew.

Re:Show me the users! (0)

Anonymous Coward | about a year ago | (#43443705)

"whatever group of suckers thinks your zero-dollar-per-user profit model will start paying off once they hit the million-user mark"

Excellent!

Scalability (2)

t00le (136364) | about a year ago | (#43442803)

I would likely build a front-end using a couple HAProxy load balancers hitting an Apache cluster running opencluster. Use red-black trees with mySQL and cluster a few databases across multiple locations. I would build the front-end with Python and html5, as well as using iphython for cluster controls and other fun stuff.

In my case I have a rack of HP p-class blade servers that use an Amazon EC2 Centos box to route inside/outside of EC2. When we test something out we use my cluster at home, then when we roll an app or website out we keep it at my house. If the load gets high, then we simply modify the cluster to bring up slave web servers, cache servers, etc. In our case we build the backend first and can roll out an app or web service for very little money or resources, but if we have success with something we just leave it on EC2 since it can likely pay its own bills.

nope (1)

Frosty-B-Bad (259317) | about a year ago | (#43442805)

You either use a cloud service like Microsoft's or Amazons so you can scale quickly to meet demands, or go all hax0r and build your own farm out and 'stick to open standards' blah blah, which you'll most likely get so side tracked administering your servers your project will slip into the background. Who cares if your code is some type of 'open standard' when it doesn't exist. If this bazinga idea will be used 'world wide' and make buckets of money, make the money and then open all your stuff up like all those other corporations do

Re:nope (0)

Anonymous Coward | about a year ago | (#43442897)

Correct you need to utilize the work done by others much smarter than you (no offense). I think amazons framework will let you deploy almost anything. App engine has its own libraries for data management and just about everything else under the sun but they are working on their maven plugin to allow jax-rs project to deploy, hopefully as bundled archive files. I don't know about azure but im sure its similar. The moral is, get to making Content and not trying to manage terabytes of data and hadoop clusters

Silly priorities (5, Interesting)

Anonymous Coward | about a year ago | (#43442809)

Youtube was a lame app with basic mysql setup. Same with Facebook. When it took off, they hired gold people and fixed the scalability issues. Twitter didn't exactly put scalability first either.

So get real. Don't worry about "hundred of thousands of users", but about getting something decent out there for users to try. If users come, you'll get scalablity sorted out.

Re:Silly priorities (2)

phantomfive (622387) | about a year ago | (#43443161)

Twitter didn't exactly put scalability first either.

Which is strange to me, because Twitter seems like such a simple website, and yet they had massive scaleability problems. Even today, sometimes. I've wondered what is so difficult about their website that has caused them such problems?

Re:Silly priorities (3, Informative)

the eric conspiracy (20178) | about a year ago | (#43443227)

It wasn't the website, it was the backend that had problems.

I remember they had started with Ruby on Rails which is notorious for being able to get you up fast and then failing to scale.

They then offloaded parts of the infrastructure to Scala of all things.

http://blog.redfin.com/devblog/2010/05/how_and_why_twitter_uses_scala.html [redfin.com]

Scala is interesting and has some good paradigms built in to the language for the things Twitter needs to do. Not sure if it is really fundamentally better than Java though - after all it runs on the same JVM.

Anyway if I was starting something like this out and I already knew Java I would go with Java. There are enough large sites running it, and there are a lot of people out there who know it so I would feel some confidence that I could do what I needed to do.

Plus I like static typing.

Re:Silly priorities (1)

Anonymous Coward | about a year ago | (#43443495)

If you like static typing and buy into the current craze over functional programming, Scala is awesome. Even if you just translate a Java program into Scala class by class, the Scala equivalent code will let you cut the code size in half. If you start using some of Scala's better features, like easier higher-order-functions and case statements on steroids, you will cut the code size even further. And you can still use Java libraries and Maven, run your applications with Netty or Glassfish, Run them on Heroku, etc...

Re: Silly priorities (0)

Anonymous Coward | about a year ago | (#43443519)

It's cause they used a toy of a framework (Ruby on Rails). When they ditched that garbage and went to an ecosystem designed, built and proven for scale (Java - after a brief detour being dazzled by the latests trends [Scala]) the fail whale went largely extinct

Start smaller (5, Insightful)

bfandreas (603438) | about a year ago | (#43442815)

Do not plan for hundreds of millions of concurrent users at once right off the bat. That's the very common error a lot of startups make. You do not have such a large userbase. It will take some time until you have.
Think smaller and scale up when your idea takes off. Set yourself concurrent user milestones when you rethink your architecture. You will also have to rethink the iron your stuff runs on and that may dictate what kind of technology you use when you reached your hundreds of millions goal.

Technology is interchangeable. It's a tool and you choose the best tool for the job and at the moment you have no users and might as well start off with the usual suspects. JSP/Struts, JSF, whatever you are most comfortable with. If in the long run you do find that this is not sustainable and you need to shift to another technology then you can hopefully afford to hire people who know it.

You really, really should set yourself userbase milestones, plan ahead for reaching them and be prepared when you reach them. For that you need a lot of information. Log how much time users spend on what functionality you offer because this also has an impact on your UI design when you go big. It also has impact on what technology(-ies) you use.


I usually bill big when I give advice such as this and help setting up a plan when to do what. Your problem is less one of technology but a business one. Think like a businessman first and like a techie second.

Plan9 from outer space. (1, Informative)

SampleFish (2769857) | about a year ago | (#43442821)

It would be cool if you could get Plan 9 working. It's an OS that was designed around distributed computing from the ground up. So much so that the API is hardware agnostic. It doesn't matter what hardware you are running or where it exists. All resources in the cluster are shared automagically. You would need some distributed rackspace in strategic global locations.

Step one is making a small lab with junk computers.
Step two is testing your application in this environment.

If you can get the backend running on Plan 9 then you can start renting servers, installing Plan 9 and adding these servers to your existing cluster. At some point you will be able to turn off the computers at your house and the app will keep running on the remaining cloud servers. It's a pretty sweet idea.

http://plan9.bell-labs.com/plan9/ [bell-labs.com]

It's kinda like UNIX.

Good luck.

Re: Plan9 from outer space. (0)

Anonymous Coward | about a year ago | (#43443533)

Yea good luck with that. I hear Mars needs Women too

The scalable app skeleton; Java flavored (2)

jwkane (180726) | about a year ago | (#43442829)

Java... ok, why not. I would take a look at Cassandra and Zookeeper to get the ball rolling. You'll need a good load balancer; nginx or haproxy since I don't know of a good one in Java. I assume a bunch of tomcat servers for the actual app. I suppose jboss messaging to keep with the java theme.

You can get all that on one machine for development, then for deployment you can flexibly adjust the number of db servers, queue servers, load balancers and app servers based on anticipated load. If you're extra-cool you can deloy to a cloud and dynamically allocate servers as-needed.

Been there, done that. Got the t-shirt. It's fun. Enjoy it.

Spend an extra day or two thinking about exactly how you're going to handle logging. It will be worth it.

The hammer you know... (1)

Anonymous Coward | about a year ago | (#43442833)

Is far better than anything else.

If you are serious then don't waste time and effort staying pure. Get the job done as fast as possible with the best tools you already know how to use.

Amazon (AWS), Java (dropwizard is simple container) and mysql (or whatever).

If you luck out and actually do get 100K users then i suspect you wont care about purity so much. You'll have and actual business to run.

Not trying means certain failure (1)

Skapare (16644) | about a year ago | (#43442845)

OTOH, it could mean success in another idea. The problem is you will never know unless you try everything, and resources usually limit that. You have to decide.

You may be able to do proof of concept with a couple cheap servers. But if it succeeds, time will be extremely short to go to full scale. So you need to think scale up front, but in a way that works downscaled as well. Do everything agile so every component can work all on one server, or separated on many. Use a distinct hostname for everything and let DNS figure where you put it. Use a distinct IP address for every service component, even if on the same machine, so you can separate them tomorrow without having to renumber. Use highly scalable front ends even if the fronts and backs share the same machine for now. Yes, a single interface can have many IP addresses on BSD or Linux.

Consider a no-SQL option for you data, if it can fit that.

Re:Not trying means certain failure (0)

Anonymous Coward | about a year ago | (#43443203)

Holy christ, did you just toss a bunch of vague generalities sprinkled with buzzwords, and call it advice?

"Do everything agile so every component can work..." -- what does that even mean?

Use a distinct hostname - chances are, he'll want a load balancer & pools of components.

Use a distinct IP address - stupid. Once again, he'll probably want a load balancer & pools of service components.

Yes, a single interface can have many IP addresses -- you seem not to understand what an "IP address" is.

"Consider a no-SQL option" - this is meaningless, since we have no idea what his data will look like, and is so vague that, even if we DID know what his data will look like, it would be useless anyway.

Get Partners then Figure it Out (2)

Kagato (116051) | about a year ago | (#43442847)

Can't do it yourself, then get partners. Set up an equity agreement.

As far as tech this is no longer new territory. Create server images for a cloud host such as AWS or Rackspace. Bring them up or down with Chef. Concerned about Database? Figure out if you really need a relational database. If not look at a high performance NoQL DB or something that is more or less always in Memory (such as Mongo).

Re:Get Partners then Figure it Out (0)

Anonymous Coward | about a year ago | (#43443299)

Having built large scale ( tens of millions ) applications in the cloud this is a terrible idea. Specifically AWS and Mongo. If you want scalability headaches go that route.

VPS + OpenStack? (1)

DeeEff (2370332) | about a year ago | (#43442859)

Sounds like you may want to check out hosting your stuff over a VPS, maybe with Hawkhost (http://www.hawkhost.com/vps-hosting) or some similar provider?

I guess the general idea is that you'd want to install / set up your own OpenStack (cloud) solution, and then scall VPS coverage if you need it, without having to install / clone over multiple machines. Check out Openstack and Java integration. As far as I know there's an SDK available: https://github.com/woorea/openstack-java-sdk [github.com] , but I'm not sure how complete it is, what features it offers, or even how you would go about setting up your project, considering how vague you were in TFA.

In any case, this may be a good starting point for you to look. Alternatively you could host everything out of your own house on your own servers, but that scales terribly if you need to buy 50 more servers, so I wouldn't recommend it.

Re:VPS + OpenStack? (0)

Anonymous Coward | about a year ago | (#43442967)

Someone asks about how to sculpt and the first thing you do is whore some advert about a random chiseling tool. He has no idea how to design his app to make it scalable. Who the fuck cares which VPS provider he's using?

I'm not sure how complete it is, what features it offers, or even how you would go about setting up your project

Alternatively you could host everything out of your own house on your own servers, but that scales terribly if you need to buy 50 more servers, so I wouldn't recommend it.

Got any other retarded alibi "advice", Sherlock? Seriously, why the fuck do you even post?

Bitcoin Exchange? (0)

Anonymous Coward | about a year ago | (#43442869)

I know, MT. Gox sucks

But, we are not here to give free advice to those that will take our money later

Re:Bitcoin Exchange? (0)

Anonymous Coward | about a year ago | (#43443043)

I'm pretty sure you're on the money here. Unfortunately, with the competence displayed by OP I don't think it'll ever take off and entertain me by crashing and burning like all the other half arsed exchanges that have come and gone.

Premature optimization (4, Insightful)

kasperd (592156) | about a year ago | (#43442871)

This sounds very much like premature optimization. You may end up designing a very scalable application and have the project fail due to too few users. If the actual number of users turn out to be an order of magnitude less than what you can handle on a single host, then all that scalability work was wasted. I think you have better chance of success with a quick proof of concept, which isn't very scalable.

It is ok to think about scalability before you have the users. But don't waste time implementing the scalable solution for a non-existing user-base.

Re:Premature optimization (4, Insightful)

Kjella (173770) | about a year ago | (#43443259)

Not to mention scalable is also relative, if you are a smash hit and need to upgrade fast you can get a 10G link to the backbone with an 8-socket Xeon E7-8870 server, a ton of memory and a RAID array of SSDs as a pretty damn good stop-gap, which I assume you can't afford now since you can't afford to hire developers. There's probably a bunch of other optimizations you can do too in order to offload parts to other machines when you get that far. This is like asking "Will the wind resistance of my afro keep me from breaking the world record on 100 meter dash?", start caring about that when you get below 10 seconds not when you're considering a running career and don't count getting a haircut as the first step of the way.

Re:Premature optimization (5, Interesting)

UnknownSoldier (67820) | about a year ago | (#43443339)

Agreed. This guy doesn't really understand scalability.

The OP needs to read how Plenty of Fish started off:
http://highscalability.com/plentyoffish-architecture [highscalability.com]

* PlentyOfFish (POF) gets 1.2 billion page views/month, and 500,000 average unique logins per day. The peak season is January, when it will grow 30 percent.
POF has one single employee: the founder and CEO Markus Frind.
* 30+ Million Hits a Day (500 - 600 pages per second).
* 1.1 billion page views and 45 million visitors a month.
* Has 5-10 times the click through rate of Facebook.
* 2 load balanced web servers with 2 Quad Core Intel Xeon X5355 @ 2.66Ghz), 8 Gigs of RAM (using about 800 MBs), 2 hard drives, runs Windows x64 Server 2003.

And also about NginX:
http://www.aosabook.org/en/nginx.html [aosabook.org]

If you "need" multiple servers when you are first _starting_ out you're probably focusing on solving the wrong problems.

Re:Premature optimization (2)

loneDreamer (1502073) | about a year ago | (#43443381)

It may be worth it to spend a little time thinking in peculiarities of you data that may greatly reduce scalability problems. For instance:

1.- If your data or user base can be easily partitioned
2.- If you can get away with low consistency semantics

If you can find a nice architectural design that has any of these characteristics, many bottlenecks can be removed and scaling up in the future may prove easy. In those cases, there are abundant technology solutions that you could pick up in the future.

So don't try to solve the whole issue before it is actually an issue, but at the same time try to future-proof your architecture. It is true that many well-known companies started small and did a full transformation later on, when they had more resources, but then again they did pay a steep cost for doing so.

Start simple (2)

joshv (13017) | about a year ago | (#43442873)

Probably the worst thing you can do is start with some complex clustered architectural design.

Just start on a single server with technologies that are scalable, and design with future scalability in mind. Also design in the ability to capture detailed performance metrics of every tier. When, and if your application usage grows, scale the parts of it that need scaling.

The biggest issue with scaling is usually the database, and for applications where you are just using the database as a simple persistence store for user settings and simple small data sets, you are probably best to go with one of the many scalable "NoSQL" type solutions such as MongoDB, as they've got scalability baked in for free. If you're trying to run heavy duty analytics that join and aggregate massive datasets, there are single DB clustering solutions, but they aren't cheap. You can always scale out SQL databases horizontally, but then you've got issues cloning and replicating, though there are a lot of products in that space, both free and commercial. A cheap place to start would be with PostgreSQL, which appears to have multiple open source replication products.

I don't think there is anything inherently limiting to sticking with Java. It's what you know, and the toolsets are deep and rich. No, it's not the hot new thing, but sometimes that can be a good thing.

Re:Start simple (2)

Ash-Fox (726320) | about a year ago | (#43443431)

The biggest issue with scaling is usually the database, and for applications where you are just using the database as a simple persistence store for user settings and simple small data sets, you are probably best to go with one of the many scalable "NoSQL" type solutions such as MongoDB, as they've got scalability baked in for free.

Are you a troll, malicious or just plain not knowledgeable?

Re:Start simple (1)

sourcerror (1718066) | about a year ago | (#43443661)

But but but it's webscale!

PHP (2)

phantomfive (622387) | about a year ago | (#43442879)

Facebook did it on PHP. I sure wouldn't have used that, but it shows you can do more with basic technologies than you would expect.

The Java environment was built for that kind of thing, Spring, Hybernate, etc, so if you build in that, you can be reasonably sure your system will be scaleable.

Keeping session state in RAM will make your life harder.

Even with a 'slow' technology, you can always add more servers. The difficult bottleneck is the database, and that can be an intractable problem depending what your goal is.

Do it first, do it "right" later (3, Insightful)

Anubis IV (1279820) | about a year ago | (#43442947)

If you're aiming for as many users as you say, then it'll take awhile to get there and you'll have plenty of time to hire folks along the way. At that point, you can go ahead and worry about re-architecting everything. First things first though, especially if you're by yourself: get it up and running with whatever technologies you do know. Once it starts to take off, you can hire people to rewrite it and redesign it around best practices.

It's not the simplest path, but without bringing in outside investors who'll have the capital to allow you to hire the team it sounds like you need, I don't see what choice you have.

Re:Do it first, do it "right" later (3, Insightful)

TCM (130219) | about a year ago | (#43443239)

You mixed up your wording.

Do it right the first time, optimize for speed later. You don't want to find out you're unable to optimize because the design is flawed.

Algorithms matter more than languages (2)

chrylis (262281) | about a year ago | (#43442995)

While there are a number of good tools out there for working with scalability, more important than any particular tool is building your application in such a manner that it's easily parallelizable. In a Web app, a core principle to keep in mind is that the more stateful the application server-side, the more difficult it is to scale, and so designing your application tiers in such a way as to decouple requests is key. Limit the amount of session state the server has to keep track of, and you'll be able to load-balance request handling smoothly.

Some research material (5, Insightful)

leonardop (532098) | about a year ago | (#43442997)

I salute you for your ambition and determination. I hope you get to realize your vision.

Now, as I read your question, I remembered an interview I saw a few days ago with Ben Kamens, one of the engineers working at Khan Academy, talking about scalability and things like how they manage their operation and the spikes of growth they have experienced in the past. It's a little light in technical details, but you may find it interesting: Root Access: How to Scale your Startup to Millions of Users [youtube.com] .

One thing I'd like to mention is that when you hear someone else talk about the things they've done and how they have done it, it's easy to see it as an advertisement for a particular technology platform (AppEngine and other Google machinery in the previous video, for example), but that's not the thing to focus on. Whatever choices other people have made, the good thing is that their advice can be useful no matter what choices you end up taking. I know this seems like such a trivial thing to say, but evidence suggests that a number of people miss this basic concept, and then discussions quickly degenerate into pointless noise about concrete technologies, instead of the ideas.

I'd also recommend that you pay a visit to Google Developers youtube channel [youtube.com] and type something like "scale" or "scalability" in the little channel search box. You might learn a few things from some really smart people who have confronted very real situations regarding scalability.

Best of luck to you, my friend.

Focus on your idea, your businesss!!! (0)

Anonymous Coward | about a year ago | (#43443007)

Dont focus on your millions of users, you probably will never get there.
If you start out spending a coule of years writing intricate frameworks
for scaling and performance.

Make an MVP, show it around, see if you can get any interest in it.
Get your idea out there as soon as possible.

If it takes off, if you get good growth, you should be abel to raise
money and create the ultimo implementation

one book that may help (0)

Anonymous Coward | about a year ago | (#43443031)

I recommend the book "Scalability Rules: 50 Principles for Scaling Web Sites" by Martin L. Abbott and Michael T. Fisher. It isn't specific to any platform, but I found it quite useful when I first started designing for scalability.

Use ScaleEngine (0)

Anonymous Coward | about a year ago | (#43443041)

It's BSD-based [scaleengine.com] , and the owner is Canadian, what could possibly go wrong?

Resistance is futile. (0)

Anonymous Coward | about a year ago | (#43443055)

We are the Borg.

make it work first (1)

Lehk228 (705449) | about a year ago | (#43443067)

make it work first, unless what you build the first time around is really an unholy mess you will be able to scale and upgrade as you grow much better than you can predict future hotspots on a system that isn't even running yet.

Easy scaling (1)

jbolden (176878) | about a year ago | (#43443083)

You haven't said anything about the problem. If you want ease of scaling go with a pure functional language. Functional languages will force you to isolate state issues. Isolate state and you can operate in total parallel. But... generally you have shared objects which are mutable across the users. So you'd end up with very little meaningfully isolated. Those shared mutable objects are what is creating the scaling complexity. The language or technology doesn't solve that, though it can make the solution easier to implement or harder. You're going to need to architect around passing them around and verifying.

But at least it will get you thinking about the problem the right way.

Lean Startup (0)

Anonymous Coward | about a year ago | (#43443093)

It ain't what you don't know but what you know that ain't so. Lean Startup may help with how to scale based on actual user needs and desires as well as ways to help figure out what those really are for paying customers.

Try the CQRS design pattern (2)

Lairdsville (600242) | about a year ago | (#43443109)

I suggest you look at the CQRS pattern. A good Java implementation is http://www.axonframework.org/ [axonframework.org] . The advantage is the CQRS pattern that it is fairly simple, but highly scalable. So you can start small and simple with the confidence that you can tweak and optimise in the future to scale as required. There are good tutorials and support too. My team is using it for an industrial application and we have found that it has been very robust. It might take a bit of work to get your head around the concepts, but it is worthwhile in the end.

Java is SLOW (-1, Troll)

cstdenis (1118589) | about a year ago | (#43443119)

Java is slow*, don't go that route if you are planning a large userbase. There is a reason huge traffic site's don't use it. Facebook, Yahoo, and wikipedia use php, Google/Youtube use python (and strait C).

If you actually want something that will scale well to huge numbers of concurrent visitors the answer really is you're going to have to go with php, Perl (and slashdot's page load times don't give me much confidence in Perl), Ruby (has had serious scaling issues, but I think they may be largely fixed now), or python.

Here is a high performance well coded php mvc framework if you do decide to go that route: http://www.yiiframework.com/ [yiiframework.com]

For database MySQL/MariaDB can be an option, but it's quality has been going down in recent years (don't know how much MariaDB has fixed that) and it's not very feature rich in terms of things like stored procedures, custom datatypes, views, etc. If you want something more powerful like you may be used to with Oracle go with Postgresql.

You are also going to want to keep in mind when designing the structure that you will want to make use of something like memcache in the future to increase performance and reduce server load.

Disclosure: I run a high traffic website that get's millions of page views a day. Uses Yii php framework and Postgresql as the database backend. There are about 1,250 people browsing it at this moment (based on active tcp connection count to port 80)

* Yes, I know *in theory* in a certain very limited set of circumstances Java can be faster than compiled code, but the theory doesn't actually match the practical reality of the situation.

Re:Java is SLOW (0)

Anonymous Coward | about a year ago | (#43443205)

You have no idea what you are talking about: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=java&lang2=php

Re:Java is SLOW (0)

Anonymous Coward | about a year ago | (#43443255)

Java is slow*, don't go that route if you are planning a large userbase. There is a reason huge traffic site's don't use it. Facebook, Yahoo, and wikipedia use php, Google/Youtube use python (and strait C).

Stop right there. This is is just wrong on so many levels.
And besides, the programming language does not matter at all for scalability. Architecture does.

Re:Java is not slow for webscale (1)

Billly Gates (198444) | about a year ago | (#43443283)

In a web app the bottleneck is the I/O and latency speed of your SQL Database. Not the execution speed hogging the CPU.

If this were an issue then how did PHP become so popular? Unlike Java is it is fully interpreted with the exception of some mods running in the web server engine.

For this you need a platform that has tons of mods and apis to build upon, frameworks, and great interconnectivity to RDBMS and NoSQL engines, and awesome threading support. While webapps are not CPU bound compared to graphics rendering they are highly threaded where you can have well into the thousands different threads and processes all using small tiny bursts of CPU activity all at different times.

Thus, Linux is insanely popular for this reason as you can move things to other servers easily like hits in a cluster or switch and Java is an excellent enterprise language to do something big and expandable for that reason. Maybe a little much for something small but works for something big. If you know anything about high traffic you would no your performance is not on the cpu at 100% but rather the load on the machine.

Re:Java is SLOW (0)

Anonymous Coward | about a year ago | (#43443285)

This is wrong wrong wrong.

Google uses Java. Apple uses Java. Amazon uses Java. Yahoo uses Java.

You have absolutely no idea what you're talking about.

Re:Java is Awesome (0)

codepunk (167897) | about a year ago | (#43443347)

Java is awesome for contractors and systems engineers since it takes a virtual ass load of machines to run it. Job Security!

Re:Java is SLOW (3, Informative)

the eric conspiracy (20178) | about a year ago | (#43443351)

Many sites with very very large userbases use Java extensively in their stack. Including eBay, PayPal, Amazon, Tumblr, LinkedIn and Google.

Millions of page views a day is a small to medium e-commerce site. I was doing a million with Perl back in 2002 on a two CPU 1U machine.

Tumblr gets something close to a billion, as does anyone in the top 100.

Re:Java is SLOW (1)

Frankie70 (803801) | about a year ago | (#43443617)

Yes, one should chose PHP, Ruby, Perl and Python over Java because Java is not compiled code. I think you are a moron. PHP, Ruby, Perl and Python aren't compiled code either.

Re:Java is SLOW (1)

tgetzoya (827201) | about a year ago | (#43443665)

You are very wrong.

Compared to PHP, Java is much faster when it comes to business logic. A combination of PHP for user-facing material and Java for business logic and database interactivity is the best of both worlds solution.

Facebook uses HipHop (http://en.wikipedia.org/wiki/HipHop_for_PHP) to convert PHP to C++ to gain some speed advantages. Also, they use a database back-end called HBase (http://hbase.apache.org/) which is written in Java.

Your 1200 users are not the hundreds of thousands the poster is looking at/for. For this, I recommend Java with Cassandra or HBase in the back end. Cassandra (http://cassandra.apache.org/) and HBase are both NoSQL and are limited only by disk space availability. Postgres/MySQL/*SQL can also be used when relational information is mandatory. At work we did some research and found that for large data sets, NoSQL write speeds were an order of magnitude faster than Postgres/*SQL. Those writes included encrypting the data before writing to the database. Read speeds were on par with each other.

Wt (1)

paugq (443696) | about a year ago | (#43443157)

I like C++, therefore I use Wt [webtoolkit.eu] for webapps. Great performance and scalability, great for embedded systems, great for huge systems, great when using third-party libraries (you can use any C or C++ library), etc.

Idea for web app - idea for business model? (0)

Anonymous Coward | about a year ago | (#43443217)

Just wondering, do you also an idea for a business model? Is there anything that prevents others from doing just the same?
I mean, having an idea for a web app is great, tinkering with scalable architecture is fun, but do you have a plan how to actually make money?

Danger, Will...danger...son? (0)

Anonymous Coward | about a year ago | (#43443243)

You're using too many analogies, parables, etc..., and my marketing meter is going off.

Please state your hiring thread as such.

Azure (1, Interesting)

akb (39826) | about a year ago | (#43443261)

Sounds like you want a PaaS provider that doesn't lock you in to a platform. I have a similar problem to you (PHP not Java) and I rejected AppEngine for the same reason as you. To my surprise I am leaning towards Azure, Microsoft's cloud offering. Their website service allows you to write your web app in a few different frameworks without having to customize it for their platform and then only pay for what resources you use. Management is as simple as manipulating sliders to how many resources you are willing to devote to your app and are willing to pay for.

I have no interest in configuring VMs, configuring memcached, handling load balancing etc. My needs are simple, very basic PHP and Mysql. Traffic will probably start small but hopefully will spike big, but maybe it won't. Azure lets me handle this situation with a minimum of effort and expense. If they raise their prices or start to suck I can easily move my app since its simple PHP.

do everything very simply (1)

roman_mir (125474) | about a year ago | (#43443291)

Don't overdo anything, don't overuse any frameworks.

Actually if your idea is good and takes off and attracts investors, you'll be able to change your technology as you go, that's what everybody goes through anyway.

Do a simple set up, as simple as possible, don't try go figure out how to parametrise everything and create nice administration interfaces, actually hardcode a bunch of stuff because that's the fastest way to do something and you will have a LOT of stuff to do if you are starting from scratch.

As you go you will be able to replace components, just ensure that you actually have components. Ensure that you have layers and components by standardising your approach. Common tasks go into common layers, components are boxes, that are fit together with APIs.

Start by making it as simple as possible and that will also allow you to keep it relatively fast. Keep as much data as possible in memory so that your database executions are minimised.

Without knowing anything specific about your idea, that's the general advice that can be given, there isn't any information on whether transactions are important or not, whether it's supposed to serve huge amounts of static data or whether it allows users to communicate with each other in real time or whatever, so if you want better answers you should ask more detailed questions.

Scaling (1)

LordThyGod (1465887) | about a year ago | (#43443345)

Any of the cloud providers are great for this. You can start with a free micro image from Amazon maybe during development phase if you have to start dirt cheap, and go up from there. Any of the cloud providers will let you scale as far as you need. That part is a no brainer. "Thousands of users" is a little vague. Depends totally on how many of them are active at the same time and intensive is what they are doing. I would think potentially something like a small 1 gig image might handle this in the low end scenario (not everybody interacting simultaneously). That does not sound scary. What ever development stack you are most comfortable with should work. I don't see why Java would be a bad choice. Its probably not the first choice of many.

Touch the ground right now: 3 things (0)

Anonymous Coward | about a year ago | (#43443387)

1. Such things is what the clouds are for. If you cannot scale it at least initially using clouds (for the parts that scale beyond reach) at per-user cost significantly below per-user income it's not a brilliant idea at all. Might still be workable but it is not brilliant in the way you think.

2. Do you have a working implementation? If not it might be brilliant but it's just an idea. Most ideas, brilliant or not, stop being interesting once they meet the realities of implementation, even the very best ones. This is both the beauty of dirty hacks and why code usually only barely works.

3. If 1 and 2 leaves you dismayed then look at what you have and prioritize. This might mean that you prioritize the idea away completely and do something else that does fulfil 1 and 2.

Real hardware (0)

Anonymous Coward | about a year ago | (#43443395)

Unfortunately you can't _really_ know how much demand "thousands" of users will impose on a real set of hardware until you've at least partially implemented it.

Make sure your design is sufficiently decentralized (peer nodes or a master/slave design) and that the nodes are able to communicate across physical nodes (whether by normal network communication, MPI, a common network-accessible database, network filesystem, etc), at least when you approach your limits you have the option of throwing more hardware at it for a while, before you have to worry about major rearchitecting of the software.

Counting bytes (0)

Anonymous Coward | about a year ago | (#43443403)

I work for a big international company and the key factor we discovered to achieve high performance in Java is reducing the total number of bytes allocated and garbage collected per request. As long is that number is south of 2 MB, you can manage to cater for 1000+ concurrent users per server instance.

kiss (4, Insightful)

crutchy (1949900) | about a year ago | (#43443437)

keep it simple stupid

the more complex you make the app, the bigger the load on your infrastructure and bandwidth

if you follow google's lead, they developed everything in house. same with pixar, which develops software to handle very high end graphics performance, and even linux started off by taking a problem and solving it with a home grown solution

if you want a specialized application to handle that many users without running into software performance issues (nevermind server infrastructure and bandwidth, which can probably be gradually improved), you want to make it efficient... so you will probably need to develop it yourself

if you use off the shelf packages like wordpress and the like, they are full of all sorts of features that you might not need but will still pay for performance-wise

many people will try to tell you that there is no point reinventing the wheel and that existing wheels will always be better than anything you can come up with, but they are full of shit. if everyone stuck with that ideal we would all have wooden wheels on our cars. there is a lot of merit in reinventing wheels, not only to make better wheels, but in understanding wheels to learn how to better use them. be a little selective about where you want to start customizing from... i wouldn't recommend reinventing the operating system, although google did (based on the linux kernel) and they are reaping the rewards of a more efficient search platform than might otherwise have been possible.

if you're handy with microcontroller programming you might be able to make a pretty efficient microcontroller-based server cluster, sort of similar to what HP is doing with their new SOC blade technology. microcontrollers and SOC are the future, so if you want to get involved in future tech today, pay attention to what is going on with ucs... a simple example is sheevaplugs and its derivatives. this is also where linux probably has a major leg up on windows because microsoft has been so focused on the x86 platform that (even with the recent release of WIndows RT) they are lagging a ways behind linux in multi-architecture support (have to wonder how much of the linux kernel has been plagiarized in WinRT).

other things that affect scalability and performance include the efficiency of algorithms... if you haven't done a CS degree, go onto youtube and watch lectures on data structures and algorithm optimization. there are free CS lecture series from MIT and UNSW that I know of. Richard Buckland of UNSW also makes the lectures a little less boring with his antics.

how you develop your app will also depend on your goal to get 100,000+ users on the site...

security is probably the hardest and most significant hurdle you'll face... if you fuck security up (either the app isn't secure enough or it's a pain in the ass for users to authenticate) then your app will be a flop

you also need to think like a user, not like a developer... this is probably where having a small team will help at some point (a few eyes with different perspectives)

many developers fall into the trap of developing software that is easy for the programmer and thinking that the user will get used to it... which is fine if you have a monopoly. unfortunately by the time you have 10,000 users, your idea will be copied to create competition, and if they do a better job with the user experience you're dead in the water.

make sure you are standards compliant. use the HTML 5 and CSS 3 validators, but i would recommend avoiding features that aren't also in HTML 4.01 and CSS 2.1 until HTML 5 and CSS 3 become fully implemented and debugged. the exception would be that if you want a feature that would otherwise require flash or java, use html5 instead of flash. if you want 100,000+ users, don't use flash or java!

i would use a linux distro such as debian with all the fat trimmed. it should be obvious, but don't use a WISA stack.

keep your service clear of advertising, 3rd party cookies and any 1x1 hidden iframes. don't try to trap or trick the user. keep your interface lean and elegant. if you haven't already study what not to do on a website (giyf) such as frames, animated gifs, stupid color contrasts, how the human reads a web page (text layout) etc. make your site site engine friendly (site map, minimal set of meta tags, etc) but ignore those SEO tips that try to trick search engines... those that discover loopholes will be able to take advantage for a short window, but those windows will be closed long before you get a chance.

keep updating your site look to keep up with the times, (selectively) add requested functionality and ALWAYS eliminate bugs in a timely manner. if you built a website in the 90's and hadn't changed the layout since, it probably isn't very popular. cyan backgrounds may have been cool once, but thankfully not any more.

project management is also a difficult area. i've had a lot of project ideas (as i'm sure everyone has) and have started them enthusiastically, but eventually the honeymoon period wears off and you need external motivation sources. this is where a team can help. if you're trying to stick it out on your own the likelihood of success is very small. i've been plugging away on one project where the honeymoon period finished some time ago and it is hard to keep going... my external source of motivation is that i use the app for work and my colleagues also use it, so i'm encouraged by them. my employer also supports me and i have been rewarded with a decent payrise and bonus, so without those incentives and support the project would have been much more limited than what it currently is. even if you are the only programmer, you will need a team to help you not only with development, idea vetting, user experience feedback and testing, code auditing, and motivation etc.

also, don't use waterfall... waterfall sucks dick. use extreme programming, but do it properly (with unit testing). richard buckland from UNSW has a really good lecture on extreme programming that can be found here: http://www.youtube.com/watch?v=XP4o0ArkP4s [youtube.com]

good luck, and remember...

"People who say it cannot be done should not interrupt those who are doing it."

"The best way to predict the future is to invent it."

Consider using an external indexing engine (2)

juliohm (665784) | about a year ago | (#43443543)

Regardless of which language or platform you use, a common bottleneck for web applications is the database resource. Most developers don't take large scalability into consideration when building the service architecture. If you plan to scale large in the future, I recommend you stop thinking of the database as the main source for all queries in your system. The basic idea is that costly and complex queries/searches can be given to an external scalable service. Take for instance, the Solr project (http://lucene.apache.org/solr/) which is a third party indexing tool that can be easily integrated with any other platform. You can design your system's database with the basic table relationships with primary keys, foreign keys and the occasional index. Any more complex table relationship, queries and searches can be delegated to this external indexing service. It will index whatever data you give it, in whatever manner you need, and return a list of results for you to easily find primary keys for direct access to your system objects. Think of it as your own personal Google indexing service... Solr is an Apache open source implementation. Once you understand this concept, you can keep you application's internal database very lean and simple, with just enough indexes and primary keys to get instant access to entities.

GAE - not all bad (1)

sootman (158191) | about a year ago | (#43443553)

Google App Engine apps can be written in Python 2.5, 2.7, Java, or Go. If you ever want to move it to something else, I think you can just change the way it communicates to the new database -- the rest should be pretty portable.

One suggestion... (1)

djbckr (673156) | about a year ago | (#43443573)

You have a lot of good comments so far, but none particularly directed to your specific question. I have recently come to a framework that I *really* like, coming from a similar background to yours.

node.js (server, business logic)
nginx (web server, proxy to node for business logic)
postgres (For relational/transactional data. There's a nice node.js driver for postgres)
mongodb (For larger datasets that don't need the transactional stability or quite so structured data)
Angular/Bootstrap with some jquery for good measure on the front-end

This is a lean-mean server tech that blows away any Java (JEE) framework. It took me a bit to get up to speed on node and the way you program with it, but I love it now. It scales so much more on fewer machines than JEE can even dream of. For what it's worth, you should look into it.

The Odd One Out (0)

Anonymous Coward | about a year ago | (#43443599)

And what would one who programs do with an idea with no friends who are interested in programming?

Don't worry about scaling at first (0)

Anonymous Coward | about a year ago | (#43443601)

Like lots of others have already told you. Build it first and worry about scaling later. Having said that I thing the Udacity lecture series Growing Reddit is pretty interesting but don't let it distract you from getting something up quick. http://www.youtube.com/playlist?list=PL7761FCF889E7D36D

Based on experience (2)

blkmajik (3321) | about a year ago | (#43443607)

Based on my experience at a fortune 100 company with a heavy interest in Java. Don't use Java. Use PHP or LUA as a cgi. Your sysadmins who have to keep your application up will thank you.

  • Do not use java. To make it work rigth you have to go against everything the community says you should do.
  • Do not use NFS
  • For file storage use something like MogileFS. It is not likely the best, but it's a proper example of what you will want
  • If you use a database you MUST understand and use the relational aspects of things. If you use the database as just a key:value store I will personally beat the ever living shit out of you.
  • Use loose coupling and sharding of your data. Multiple databases on multiple replicated servers is happy. Isolate each aspect of your product into separate databases.
  • On a related note it's likely that only accounts need to be replicated between databases. It's not hard and will allow you to scale very large
  • If you use memcached do not store individual bits of data. Store complete rendered data only
  • Use cgi. Mod_* and Java are a bitch to debug. Php and lua work well for this. If you have something that is multi-tenant multi-version this applies even more.
  • Do not use web session affinity.
  • Do not use full text search in a database
  • Do not use stored procedures
  • Do not use large frameworks. If you must use a framework use small ones dedicated to a small subset of functionality. No framework you use should use a database.

API first (3, Informative)

foniksonik (573572) | about a year ago | (#43443625)

Write your public and private Apis first. Then implement them quick and dirty. Get feedback. Get users. Keep working on the API to make improvements. As you get more traffic hire good people to reimplement those same APIs on a better tech stack. Runs and repeat. You can even mix and match platforms, just use a smart routing proxy like HAProxy to send requests to the appropriate places. Static files go to a CDN, logins can go to something small but secure, high volume requests can go to a big cluster or IaaS like Amazon or Google for on demand scaling.

API first.

my advice: (0)

buddyglass (925859) | about a year ago | (#43443717)

Swallow your pride and go with App Engine. Here's my thinking:

1. GAE eliminates a lot of otherwise time-consuming setup work. You're just one guy. If you want to ever get this thing finished you need to spend your time coding and not setting up servers, mucking around with database settings, etc.
2. GAE is scalable w/ little to no extra effort on your part, assuming you code your app correctly.
3. GAE solves the problem of serving a user base that's geographically distributed all over the world.
4. GAE lets you keep coding in Java.
5. GAE is pay-as-you-go. If nobody visits your site you're not out a lot of money.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>