Slashdot Mirror
Ask Slashdot: Building a Web App Scalable To Hundreds of Thousand of Users?
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."
http://www.codinghorror.com/blog/2010/01/cultivate-teams-not-ideas.html
You've told us way too little for us to really help you. Also, you sound like one of those people who, ah, nevermind.
http://evergreen-ils.org/opensrf.php 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.
http://www.rabbitmq.com/java-client.html
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.
Learn Scala and use any of these great techologies: Play, Akka, Spray, Finagle
They are all high-quality tools designed for scale.
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.
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).
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.
When the only tool you have is a hammer, every problem looks like a nail
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
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.
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.
20 minutes into the future
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/
It's kinda like UNIX.
Good luck.
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.
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.
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.
now we need to go OSS in diesel cars
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).
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, 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.
I know, MT. Gox sucks
But, we are not here to give free advice to those that will take our money later
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.
Do you care about the security of your wireless mouse?
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.
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.
"First they came for the slanderers and i said nothing."
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...
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.
if you were really laughing that hard at tfa, you really need to get out more
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.
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.
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 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.
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
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.
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.
It's BSD-based, and the owner is Canadian, what could possibly go wrong?
We are the Borg.
This is what you want: https://github.com/AppScale/appscale/wiki
Because you can - or because you should?
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.
Snowden and Manning are heroes.
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.
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.
I suggest you look at the CQRS pattern. A good Java implementation is http://www.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.
I like C++, therefore I use Wt 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.
You have no idea what you are talking about: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=java&lang2=php
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?
You're using too many analogies, parables, etc..., and my marketing meter is going off.
Please state your hiring thread as such.
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.
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.
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.
http://saveie6.com/
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.
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.
You can't handle the truth.
My friend, you are 18 and in junior college, right? It shows.
If you want news from today, you have to come back tomorrow.
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.
Java is awesome for contractors and systems engineers since it takes a virtual ass load of machines to run it. Job Security!
Got Code?
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.
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.
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.
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.
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
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.
Julio Henrique Morimoto juliohm@gmail.com
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.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
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.
And what would one who programs do with an idea with no friends who are interested in programming?
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 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.
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.
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.
A fool throws a stone into a well and a thousand sages can not remove it.
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.
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.
Without any actual information on the project, this is my recommendation... MongoDB is designed for clustering and replication of various types of Data.
Node.JS scales fairly well and is pretty light weight.
With Geolocation DNS you can start small in your local area hern add servers in places you need to.
One company I work for (until I found a sweeter place elsewhere) got rid of their entire dev staff except for the top level designers. An offshore dev team gives guarenteed results, low bugs per line count, and actual contracts to say that. As an added bonus, the parking garage doesn't smell like BC bud anymore.
You might give them, or another offshore place a call. They may be able to get what needs done, with little QA, for pennies on the dollar than it costs to hire people locally.
Break your whole project down into little tiny modules, with a configuration file to provide various host names when you start breaking things up onto different hosts. And, where possible, use wrapper functions for things like DB calls.
This way when you move from mysql to postgres to oracle to NextBigDBPlatform you change the one wrapper function, not every part of your code. When you see that Java isn't the best tool for a particular job, re-write the small module in charge of that job in some other language. As long as it gives the same output with the same input, who cares?
Basically, build yourself up an API. Let the individual building blocks pass info back and forth thru either other API calls or platform and language neutral, well established communication protocols like HTTP puts/gets/posts using curl or whatever method you like to use to generate and then deal with the output of such requests.
Don't blame me, I voted for Kodos
IMHO, rejecting Google App Engine at this stage is a bit myopic, but it's your choice. :)
Among the more open-standards-focused cloud offerings, there is Red Hat's OpenShift
- https://www.openshift.com/
- https://www.openshift.com/developers/java
- https://www.openshift.com/developers/pricing
- http://www.jboss.org/openshift.html
Various ramblings
I'm in the middle of porting an Atlassian product.
They are probably some of the best Java apps out there, and this port is a NIGHTMARE.
The easiest ports are PHP.
Start with something that you can write well. If you are good at Java, then use Java. If you are good at PHP, then use PHP. If your seed project sucks, then forget about scaling. It won't be able to leave the crib.
I use PHP, not because it's a good language (it isn't), but because it is probably the single most portable host-executed dynamic language out there. It is the "P" in LAMP.
If I want my system to be portable, extensible, scalable and installable by as many folks as possible, then I use PHP. If I have a completely bespoke server, that I'll never move from, then I have a lot more choices. It is pretty difficult to get decent Java hosting, BTW...
PHP is pretty fast, these days. There are a number of ways that bad coding can will slow it down (for example, using it to build vast MVC frameworks as if it were Java), but a great deal of FaceBook is written in PHP, and they have chosen to make the language faster, as opposed to rewriting their code base. They have done something similar with MySQL.
Oh, my god.
Amazon AWS's Elastic Beanstalk service is perfectly suited to this sort of problem. If you do your homework and design your system properly, it can automatically scale from a single box up to a giant group of servers capable of handling as many users as you can muster. It's pretty magical. We use it for everything we build, just in case.
No, I'm 30-ish and have worked for companies where doing such things is fucking part of business. Go to Linode.com. DONE. Hell, anywhere can solve this problem of hundreds or thousands. It's called fucking load balancing. Get a few Casandra nodes running. USE FUCKING GOOGLE to search for the answer. Look into how OTHER COMPANIES pull it off... Coming to slashdot? For fucking serious? Yeah, I laughed. They fucking made me do it.
I know you stated you weren't interested in GAE but this is exactly the scenario it excels at. You have a large globally distributed intrastructure that can scale massively at your disposal. And as long as you stick to the high level APIs like JPA instead of coding directly to the datastore API, you have an app that you can pull out and host elsewhere if you want.
Now another thing to consider - you said you have experience with GWT, but the trend I've noticed with Google is they're not building much on GWT at all, and I'm not sure what the long term plans for that project are. But I've spent a lot of time battling weird bugs / misconceptions when working with it, so I'd be inclined to use something more mainstream like Ember.js or other solutions. But if you're good with GWT, it's hard to beat the GWT + GAE integration.
Pick up a copy of "How to Build a Porn Site" by Tim O'Reilly, since that is obviously what you are trying to do.
I see a lot of posts around the topic of "Just use PHP/Rails/etc now, worry about scale later." I disagree, it doesn't take THAT much more effort to think about scaling up front, and develop the correct solution now, so that you don't have a (or multiple) panic re-orgs. The key is getting something that scales from small to big somewhat effortlessly. Nothing will scale perfectly. So here's my recommendation:
1. Use RackSpace - I've seen this mentioned before. And I agree, RackSpace or some other OpenStack provider will ease your IT pains as you grow, plus you can start small.
2. Use Nginx - It is as easy to setup as Apache (some say simpler) and can connect to most anything apache can. A micro-sized VM from Rackspace (256MB RAM) is more than enough if this is the only thing running -- and it should be. I actually perfer the OpenRESTY build of Nginx, the extra modules allow for some nice improvements over the vanilla system. For example, off-loading your session management/timeout/login to the webserver so that the backend doesn't have to do it.
3. Use Java - Two reasons, first, use what you know. You are going to be the only programmer to start, so it'll be the fastest way to get to market -- VERY important with your new venture. Second, While the fancy "Java Extensions" like Grails, Scala, etc have some nice features, it's just syntactic sugar in the end. Why add a layer of indirection, also there are more Java developers than Scala developers so your talent pool is larger. If you want a framework to help you get going quickly, use Apache Camel. It's an excellent framework for handling traffic from all sorts of places, they not only support HTTP/REST, but SMS, Message Queue's, Email Systems, IRC, and a lot more.
4. Use Static HTML , JSON, and AJAX. Template languages are soooooo 2008. To get tha tweb 2.0 appeal (and scalability) you cannot have template engines chugging through producing HTML on the server. Use your Nginx to serve static page, call your java servers to get the raw data (in JSON) and use a client framework like jQuery to produce the output on the browser. If you are going to scale to tens-of-millions of users, you are going to need to push as much work to the client as possible. If you MUST use a template language use a light-weight one like HandleBars or Velocity.
5. Use RIAK - I'm making an assumption that your social application is going to need the noSQL/document-oriented type database over the traditional SQL DB, if only for the sheer amount of data you will be storing. RIAK is simple to setup, simple to use in a small environment (1-3 servers) but has massive horizontal and vertical scaling options. We routinely push millions of records a day into it, and use it's built-in map/reduce functions to process the data as we need it. It's a bit memory hungry, I recommend a 4GB RAM VM at a minimum, but it will grow with you without having to re-engineer core parts of the system.
So, in comparison to the LAMP framework of the past, I offer the ONRAC framework (OpenStack, Nginx, RIAK, Apache Camel) Not as catchy of a name, but exactly what you need to scale from a few 1000 users to tens-of-millions.
For your initial launch, write it simply so you can get it done. But plan high level abstraction into the design.
For example, you could write your app with functions like QueryDatabase(sql_command), but that ties you to specific implementations. If you've instead got a function like database.GetPostsWithKeyword(keyword), then you can write your easy MySQL implementation now, and swap it later with Dynamo or whatever else the cool kids are using later, once you've got enough traffic to warrant that.
Do high-level abstraction like this for enough parts of your app, and you can scale it one piece at a time when necessary.
http://www.larryullman.com/2013/04/08/what-is-larry-thinking-68-going-big-macro/ And take a look at bizspark
Google App Engine rocks and supports many languages. You highlighted Java and I do believe Java was one of their first supported languages for App Engine.
Google is open-source with their api and infrastructure. I'm not sure where you feel they are proprietary, but they are the most open-source company I have experienced. In fact, I have recently examined the Google App Engine docs and found them enjoyable and easy-to-use and especially with Google's new Go language support api. Everything about golang is free and open-source. It compiles on your ubuntu box if you have one and then you develop the app locally on the ubuntu box. How much more open-source do you need?
The scaleability is the fact that when you push the app to the google infrastructure all the scalability is handled transparently by Google. It keeps you focused on the problem rather than tripping your feet like you are still deciding what tools to use and what companies to collaborate with.
As someone who has written an application that scales to over 1 billion requests per day, let me offer my thoughts.
Scaling your application should be as trivial as launching more application server nodes. If you can't add/remove application nodes painlessly, you've probably done something wrong like keep state on them (this includes sessions).
Don't worry about scaling your application layer at all (within reason). You can always throw more machines at the application side in a pinch, and for a long while it will be cheaper to add servers than to hire someone. When your application servers are costing you more than a salary, hire someone to find the hotspots in the code and make them faster. Until then it's a waste of your time.
Scaling state, aka your datastores, is where the challenge lies. You need to spend a large amount of time sitting down and analysing every operation you plan to do with your data. SQL is great for a lot of things, but you will eventually run into a point where heavy updates make SQL difficult to scale. Mind you, decent hardware (lots of cores, RAM, and SSD) running MySQL should scale to several thousand active users if your queries are not expensive. The Galera patches to MySQL (incorporated into Percona XtraDB Cluster and MariaDB) can give you true high-availability, but you will still have write-throughput limitations.
I would also highly recommend you look into Cassandra (especially 1.2+, with CQL 3), which was built from the ground up to scale thousands of low end machines that often fail (if you can't tolerate hardware failure, you messed up). Cassandra is more limited in the kinds of queries you can execute, more relaxed with data consistency, and more thought is needed ahead of time. On the other hand, it can also be used for global replication, which is something you are interested in. At the very least, having a good understanding of its data and query model will open your mind to the kinds of tradeoffs that must be made to enabling scaling.
Contrary to what others are saying, you are correct to think about scaling now before you even start! Doing a rewrite is costly and expensive in money and time. Why set yourself up for that? Planning for scale before you start is the best time! If you start with a scalable datastore like Cassandra, and structure all your queries to work within its model, it is no more work than doing things in SQL, and you're way ahead of the game!
The most important part is spending time modeling how you will access your data. Think about how you'll avoid hot spots (which make scaling writes difficult), and think about how to make reads fast by reading as little as possible. Think about caching, and how you'll invalidate the cache of a piece of your data without having to invalidate caches for things that didn't change. (Think about updating on data ingestion instead of running statistics later.) If you can't avoid hot spots, make only small reads, and cache independently, you are not done.
Good luck!
Be relentless!
n/t
OP did not tell us WHAT he needs to scale.
Front-end is a given. But that is relatively simple to handle. What else? Database? Business logic?
Kind of hard to give advice when you don't know what you're giving advice for.
Regarding FB's PHP: You do realize there's a reason why HipHop was written right?
So why was PHP and MySQL chosen for FB? Because that's the only things that The Zuckster knew.
For crying out loud, keep it simple; force the users to not have instantloadtimes nowaitbecauseI'mabraindeadfucktardlol.
Try windows azure. Super easy to build large scale applications.
I am building such a beast myself right now. I'm not using java, but what some of the other kids are using: linux, apache, mariadb, php. For more giggles, there is memcache (that's good for thousands more users), plus common sense stuff relating to how big a hit you put on your system w.r.t. data (big images suck bandwidth). Even clipping an image in several ways means showing part of an image here, another part there, but its only one image, and once down you can use it in dozens of places. The Facebook folk use memcache too, as well as APC, and then they created hiphop-php which is compiled php. So much for slow. Now they don't use a standard SQL database anymore (they are using nosql), but it depends on how big you get.... did you say 1 billion regular users? Personally, I would be happy with 2-3 hundred million. First you need the fancy idea though, right?
It's cool that you're interested in developing to an open standard, but I think it's worth noting that there are two kinds of proprietary platforms.
The first is platforms like Google App Engine or Windows. These platforms lock you in, by forcing you to write your code to a certain API. If you decide you don't want to keep using this platform, it's really hard to move to something else. The bottom layer of the platform forces a lot of implementation details in the upper layers of the system.
Then there are things like EC2 or GCE. EC2 gives you a pretty standard Linux machine (unless you choose another OS) and you run standard Linux applications on it. There isn't much lock-in, and the bottom layer of the stack can more easily be swapped out. There are features of EC2 like auto-scaling that are available to you, but you don't have to modify your application when you move to a different auto-scaling implementation.
It sounds like you're a software guy, and so getting someone else to manager your data center is probably a good idea for your situation. That way, you can focus on the software. You can always move platforms later if you decide Amazon is not doing a good enough job, or if you find a more open platform that is as good.
First things first... Do you have hundreds of thousands of simultaneous users?
I worked at a shop where we did. I've known a lot of others who didn't, but their goal was so lofty. Some actually said "millions of simultaneous....", but only ever managed to get dozens, or even only one dozen at peak times, including themselves and their friends.
Even at the shop where we had hundreds of thousands of simultanious users, they didn't start out like that. It grew into that over several years.
If you have that many users, you should have the financial base to hire developers who already know what they're doing, system/network admins who can do the infrastructure properly.
As you're saying that you're to be the only dev, and you don't have the resources to hire any more, stay simple, and let it grow.
No big site ever designed for their final need. It grows over time. Just keep an eye on your current need and growth projections.
Serious? Seriousness is well above my pay grade.
Yes, the JVM kicks PHP and other scripting languages' asses.
The misunderstanding comes from the fact that nobody writes Java programs like they write PHP scripts. Of course, you could just create a JSP file and start writing PHP-style code. It would be faster & better than PHP and actually have sane, non-buggy libraries.
But Java programmers love their abstractions and frameworks, and some of those frameworks are slow. For simplistic use-cases, PHP will seem like it's "faster".
"Here is a high performance well coded php mvc framework if you do decide to go that route: http://www.yiiframework.com/ [yiiframework.com]"
It's 6:30am here; please don't make me laugh so hard this early in the morning.
high performance, php in the same sentence *chuckle* *gafwah*
As the lead dev for a major startup, I can tell you app engine is a dead-end. I inherited app engine from one of the founders who is a decent, but not amazing coder and I can tell you it is a nightmare in so many ways, mostly because of app engine itself.
If you are getting funding and personnel like Khan Academy, I am sure App Engine can work fine for you. Otherwise, there are many problems including:
1. Despite being "open source," Google takes forever to fix some critical issues and isn't very fast accepting any community patches. The encoding issues with multi-part forms for example are still not fixed years later. Finally a few weeks ago after years, they release a patch and the issue is still broken with post. Read the issues carefully and you will see other examples.
2. The cost is also deceptive. Although your site will handle traffic spikes and you can cap the quota, you will probably start coding in fear of the pricing model. What I mean by that is you will make decisions not based on the best architecture, but based on avoiding excessive app engine costs. For instance, many app engine devs write blog posts about circumventing write or reads on the datastore because of cost, not performance.
3. App Engine is a black box. Once the thing is deployed, you have no great way of debugging it or doing extensive performance analysis without largely rolling out your own toys. If something goes wrong, it is very difficult and time consuming to fix for many reasons. First, the dev environment merely simulates the production environment and many features do not work the same or at all in the dev environment. The dev environment is also single-threaded which makes life miserable when doing any sort of call/response web service interactions.
Second, many libraries are just pitiful on app engine or there is no support. You cannot use anything that calls c-modules in python. Not a big deal maybe at first, but you end up with weird things happening sometimes in libraries you don't expect. For instance, we were having SSL errors with rackspace, and it turns out that you cannot catch the SSL exceptions from Rackspace's library since the exceptions come from a c-module.
Thirdly, many bugs only appear in production and not dev, or vice-versa. You cannot easily patch some of the lower-level portions of the infrastructure on the server without google first fixing. The best you can do sometimes is upload your own version of a python package and hope that it lets you override the app engine settings (example webobb). Again, Google is extremely slow fixing these issues and because they own the infrastructure including the server software, you are at their mercy.
4. Outages. Despite the notion Google = Uptime, it's simply not true. Go back and start looking at the stats. I can also tell you they lie on the global stats because many times our servers have gone down and they haven't logged any global issue even though it was more than just us. To Google's credit, in many of these circumstances they credited us with the lost time, but on the other hand a few dollars doesn't make up for hours of lost business and user activity.
5. Performance. App Engine data store performs and queries pathetically compared to other similar alternatives such as Cassandra or even Hadoop. We've spent tons of time optimizing our site and although it works better than before, we've had to get creative in ways I don't have to with other technologies. I ask sometimes what is the point of a data store that can scale huge that I can't query, read, or write to without huge concerns. App Engine data store is not on par with Google's own secret sauce, sorry.
6. Framework support. Unless you want to roll your own, you'll have to modify or pick from a pathetic stack of frameworks. Most good Python or Java frameworks that are good stand-alone are half-baked when it comes to their app engine versions. For example, a lot of people want to use Django and thus the natural choice seems like Django non-rel. What you will
.NET, of course.
On a serious note, I would recommend looking into heroku. Not excluding all the great input already posted in this thread.
Here is a ... well coded php mvc framework
That's an oxymoron.
Stuff like this doesn't come free. Hire people who know what they're doing if you don't. It's insulting to people who actually know what they're doing that the OP expects to "just get a few pointers" and go off and build this sort of system. And before you get started, the OP is not asking for some advice to start learning the process of what needs to be done here. He or she just wants a solution now now now.
How would writing majors feel if we asked them "I'd like to write a best selling novel. I've done some creative writing and I'm comfortable writing short essays, but I can't afford a ghost writer who's actually good at what they do. What should I do to get started?" It's not that simple.
You might want to have a look at Command Query Responsibility Segregation (CQRS) as a concept.
If we're doing work for you, how much do we get?
Vote monkeys into Congress. They are cheaper and more trustworthy.
Things I've noticed as a sysadmin, for 'scalable' apps:
* Java? Do not use it. Sorry. Just don't. It's shit and nobody seems to be able to write it worth half a damn to scale out.
* That goes double for Java running on Tomcat.
* That Java framework you know? It's expounded shit and will consume all available system resources with only a handful of users.
* It doesn't matter how good a developer you are if you're a Java developer: your application will be CPU and memory intensive. (See the first three points.)
* Whatever you do should use heavy use of in-browser processing via javascript.
* Use MVC, or preferably, MVP concepts in development.
Aside from a front-heavy application, your concerns will be database access. Design the database so that it will scale broadly; preferably pull someone in who knows a thing or two more about normalization than you do to do this, if only to have a second set of eyes.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
http://www.google.com/search?q=scaling%20mysql%20slideshare%20presentation
http://www.google.com/search?q=scaling%20webapps%20slideshare%20sharding
http://www.google.com/search?q=scaling%20master%20slideshare%20slave%20cluster
http://www.google.com/search?q=scaling%20slideshare%20tumblr%20flickr
1st Rule on scaling: If you have a scaling problem, you don't have a problem.
Wrong approach. Yes, many have said it and I'll say it again and it will remain true for all eternity.
If you think you've got the next Google or Facebook up your sleve - well so be it.
Build your app, use regular common sense when doing it and the rest just happens. I've handled upwards of 20 Million active users with user tracking and billing with a few thousand hits per second per product in an internet gaming company and I can tell you that when scaling with a product has to happen - it will, and if server duplication is done with Perl magic by a handfull of admins, cloning one drive to the next using a checklist on a wiki.
The thing you will need most when you have to scale is money. The time building the perfect scaling system from scratch from the get-go is a million times more worth if it is spent on building business contacts and getting VCs and Angels with good contacts and/or cash to invest on board. If your app isn't a total mess of spagetti code and ignores the most basic of architectual rules your better set for scaling than most large apps out there. For example: Click around Ebay for a few moments and try to imagine what's going on beind the scenes there, and think of how it grew and how and when Ebay started out. I'm currently working on a financial app for a *very* large international bank. The apps foundation is 8 year old copy-pasted & slightly modified grey goo of Dreamweaver HTML/JS and anti-object oriented PHP 4, an app so bizare it defies any description - and yet it is the key product of the shop and beats the competing Java app in terms of usability and flexibility.
Anybody here will tell you that scaling a PHP app to a billion users won't work and you should forget PHP right away. And yet Facebook is here and they're scaling pretty well as far as I can tell. They even got a few devs working on a PHP JIT compiler (HipHop) the last few years. Again, as you see: Scaling problems are *exactly* the kind of problems you want to have.
Bottom line:
Make it work, make it beautifull and worry about scaling when it happens. All else is nonsense.
P.S.: ... My 2 cents.
Premature scaling worries aside, in terms of technology today I'd go for Nginx and JavaScript in the Front and Back, using Node.js as the server-side technology. It seems stable enough to build something serious with it and you've got one PL for both server and client. It's like in the good old days of Netscape Webserver.
Good luck.
We suffer more in our imagination than in reality. - Seneca
Just as Linus put it. Focus on your stuctures and algorithms ("architecture") to ensure good scalability upfront.
Then work out details (SQL queries and whatnot) for your platform/technology and try to find static vs dynamic parts and separate them properly. Static parts can be cached 100% LATER with some servers upfront which will give you almost infinite scalability there. Your basic setup should cover around 90% of your dream setup, as the last 10% are for versions 2 and 3 of your application, and these are really hard.
Then start working and focus on clean structure and code right now than premature optimization; with a clean structure optimization can be added later. If you're doing Java code please do not generate lots of short-lived objects.
Now you should be good to go.
PS: I really don't understand the mind set of 99% of the answers here. They need to hand in their geek cards...
> Java is slow*
As others have noted, this is completely wrong. Java bytecode, over a JVM in server config, after the JIT warmed up (which is the case for web apps), is very close to C++ in performance.
> Google/Youtube use python
Only for select portions of the site that see regular updates or have little logic (uploads, the labs potions etc). For the rest, they use a lot of Java, along with C and now Go.
Python and PHP web sites can be quite scalable. This is not because Python and PHP are themselves fast (they are 5-20 times slower than Java when run pure), but because most of the work is in fact done over C extensions (Python regex is actually a tad faster than Java regex because it uses a native module). If most of the CPU time is spent applying templates rather than any per-page logic, simply switching to a native templating engine works wonders. This is fine. I don't care where my code is run as long as I don't need to write managed code and I use Python a lot for scientific code without speed problems.
To query a database, run an XPath query, call a scientific extension or apply a template with native cheetah template engine, Python won't be much slower than C. But logic in Python itself is SLOW and it shows in a tight loop (not something web sites do much of anyway). So Python makes it easy to write C extensions without getting hands dirty (Cython, Shedskin etc). Put in another way, Python is a slow language (implementation, really) that does not let the slowness get in the way, most of the time. Same goes for PHP.
> * 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.
Many Java web frameworks do a lot more stuff than typical PHP setups. For example, I use ZK. It maintains the entire client UI model on the server. This is definitely not meant to scale. But the abstractions save me a lot of work for what I want to do.
Here are some recent benchmarks on how Java and PHP perform under load, especially when straight Servlets are used. No comparison.
http://www.techempower.com/blog/2013/03/28/framework-benchmarks/
http://www.techempower.com/blog/2013/04/05/frameworks-round-2/
> Disclosure: I run a high traffic website that get's millions of page views a day. Uses Yii php framework
But what does your site mostly do? Just serve static content for most part? with the pages filled with some straight-forward queried content? Yii framework looks like a basic MVC framework with few additional abstractions. It should not matter what language you use for something like this. I suspect that the same would be true for the OP. I don't disagree with your conclusions, just not for the same reasons.
The final advice to OP: Start with whatever takes the least capital. There are frameworks that have plugins for most of the common web stuff (Rails, Grails etc) and these are the right places to get started quickly. Hundreds of thousands of visitors/day is not much for modern machines. Even if the site is 20 times slow, clustering to 20 servers is cheaper if the slower, but more productive technology saves one developer year of work. A little optimization later will probably give you a lot of mileage later. Switching to a scalable architecture, using technology built for scalability like Go, Hadoop and NoSQL/HBase won't need to be concern until one is rolling in cash. They need more expensive devs. Premature optimization and all that.
You mentioned wanting to stick with open standards.
I would point out that if this is ultimately to run as a business, you need to make decisions based on what's best for the business. Which may or may not be something based around open standards.
Making a decision early on and sticking to it dogmatically even when there is no business benefit in doing so - and refusing to even contemplate alternatives simply because they're "not open" sounds dangerously close to operating a religion rather than a business.
Hi,
My suggestion is for you to look into the Agile Platform, from OutSystems (www.outsystems.com). .net stack.
I came across it, some years ago, and once you ramp-up on it's usage, you'll be able to much more proficiently deploy web apps.
It has a free edition, which I think that can only run in Windows. However the paid version you can choose between java ou
Hope you find what you're looking for,
cheers,
"Anonymous Coward"
Unless you have the money and management experience to start a company, hire developers, etc, then the technology that you'd hypothetically use is irrelevant. OTOH if you do have the money to hire developers with the right skills then the problem will solve itself.
The notion of not having the money or management skills but somehow bootstrapping yourself up from nothing is almost certainly not going to happen. Even those who did start major companies without venture capital did so by borrowing significant money from family and friends, and only succeeded because they also happened to have the management skills.
Creating a successful start-up is more (or ALL) about having the right people than the right idea. In fact, the various start-up incubators are happy to fund the right people even if they don't have an idea, and many/most start-ups, if eventually successful, don't end up with the same company/product idea they originally started out with. You man think you know what the world needs, but the world will tell you if your right or not, and you'll only be successful if you adapt.
If you have the right stiff to create a startup then I think your best bet is to apply to a start-up incubator that will finance you and hook you up with the right people, but they are mostly looking for teams rather than individuals.
About an eco system to address your expectations i would suggest open-stack infra-structure with Juju, and Cloud Foundry.
For the Java Developments i found Wavemaker a great tool that generates java standard code projects, and can be easily opened by the Eclipse IDE.
For the web servers Tomcat or Jetty.
Links related to this techmologies here:
Juju for OpenStack - http://www.slideshare.net/fasgoncalves/juju-on-ubuntu-cloud
Cloud Foundry - http://www.slideshare.net/fasgoncalves/cloud-foundry-and-openstackcloud
WaveMaker - http://www.wavemaker.com
Also look at Ubuntu Cloud : http://www.slideshare.net/fasgoncalves/ubuntu-cloud-infrastructures
FranciscoG.
Oracle sucks balls.
Just some things I've learned over the years while working on high and low volume websites:
* Spend your energy coming up with the product and figuring out your customers needs. Chances are you won't run into scaling problems until later. Your first goal is to get that far.
* What you think will be the bottleneck when you start out will probably not be it. The ugly part is that you won't know what it is until it hits you
* Read through some of Brad Fitzpatrick's presentations at http://danga.com/words/ (They're mostly variations on the same theme, pick one of the later ones). Yes it's 6 years old at this point, but little has changed. OK, maybe schemaless datastores. But look at what livejournal did on commodity technology.
* Don't fall into the temptation of using sexy technology because it solves a problem you don't have yet. You can do a heck of a lot with MySQL and Postgres.
* Your choice of technology isn't as important as your development practices. Automate your testing. Automate your deploys. Automate your testing. Stick with the languages you know.
* Measure. Something like New Relic will help you spot your problems and fix them.
MySpace v1: Java
Facebook: PHP
nuff said
Not sure this is right for you, but it was once upon a time designed to match some of your buzzwords.
http://sourceforge.net/apps/trac/reddwarf/
While I agree with everyone that says build small to start and scale up later as needed, the one caveat I'd give is whatever technology you use, design with the THOUGHT of clustering from the start. I've seen many designs fall down when scaled because, for example, the app used session too liberally and now session replication across clustered nodes is a serious problem.
There's nothing that says you must use clustering later, there's other approaches, but if your app inherently can't be clustered because your design doesn't allow for it the it can turn into a real headache quickly.
If you design as statelessly as possible then you're likely to be fine when you go to scale, whether vertically or horizontally. That's a simplistic answer, but it will be correct, to a reasonable approximation of "correct" :)
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa
Can you use Google to learn how not to be a fucking douchebag?
It's a proven technology that scales very well, and is very easy to learn and maintain. Even Indian H-1B programmers like it. Why do you think the U.S. government runs smoother than a baby's butt?
PERL. Learn it. Love it. Live it.
Definitely start small, but make sure you measure the response time and load from the beginning, as close to the user as possible.
The load will tell you how many users you're gaining, albeit in computer terms, and the response time will tell you if the system is starting to annoy people by slowing down. If you plot RT against load, you'll get the curve you need for capacity planning when and if the program becomes popular. report
--dave
davecb@spamcop.net
An 18 year old in a 30 year old body. Grow up.
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.
In my experience, Java has basically two areas where performance is an issue: initial startup, and certain graphics operations. Once Java is running, and so long as you're not doing any sort of 3D graphics or such, Java is as fast as anything, including compiled C code.
Neither of those apply to web apps. You'll only have to bring your server up once in a blue moon, and you'll just be answering HTTP requests, not driving a FPS. Java KILLS at that kind of stuff.
And yes, lots of huge websites (Amazon, Ebay, Facebook) use it.
This reminds me of the old days when I was going to write the next great game on the ZX Spectrum. You had to first make the coolest intro screen before writing an inch of code, that's normally all you got out the door.
I'm a big fan of using Django on top of Google App Engine. You get Google App Engine's awesome infrastructure as well as Django's standard interface and community.
Fast Federal Court and I.T.C. updates
Whilst there's lots of good advice about scaling out hardware & infrastructure on here no one has mentioned Performance Testing. Which I would have to say is probably going to be vital for a web app. Also don't forget to security test it properly too or you'll do a Linkedin on us.
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
Remember also that once you release your killer app and get even a handful of clients, someone out there is going to copy what you've done and one-up you in some way. Then you're going to find out how competitive the software industry really is. You might consider registering a provisional patent first. I think that gives you a year to file an actual application. It's cheap insurance.
I have two sites one using Couchdb and the other chicagoboss+mongodb both scale well over for 500K users so far. The best part of it is that they both run on very cheap. chicagoboss on a bunch of m1.small spot instances and mongodb on a reserved m1.large While couchdb a group of spot instances and reserved m1.smalls. Erlang based web apps really scale well. http://www.ostinelli.net/a-comparison-between-misultin-mochiweb-cowboy-nodejs-and-tornadoweb/