The Dream Stack - Is This A Joke?(dobbscodetalk.com)
dobbscodetalk.com
The Dream Stack - Is This A Joke?
http://dobbscodetalk.com/index.php?option=com_myblog&show=The-Dream-Stack-For-Developing-And-Deploying-Web-Applications.html&Itemid=29
9 comments
This isn't a literal request for advice. It's "suggest your favourite web stack and how it performs along particular criteria".
For instance: Hybrid car
- Pretty fast relative to other transport
- Not bad safety but not the best
- Pretty affordable relatively
- Has a radio etc.
- It does better ecologically than most.
It's not going to be a perfect answer, but having those 5 questions you just posted lets me know a) what's important to you (I might not care about ecological qualities for instance) and b) lets me evaluate why I might choose a particular method.
For instance: Hybrid car
- Pretty fast relative to other transport
- Not bad safety but not the best
- Pretty affordable relatively
- Has a radio etc.
- It does better ecologically than most.
It's not going to be a perfect answer, but having those 5 questions you just posted lets me know a) what's important to you (I might not care about ecological qualities for instance) and b) lets me evaluate why I might choose a particular method.
I think of this kind of tool wank as "Guitar Center development" - the conviction that choosing the perfect combination of web framework, revision control system, programming language, data store, templating engine and web server is a prerequisite to building an awesome app.
It's exactly analagous to the idea that you can't truly shred until you've assembled the right set of effects pedals, preamps, niobium-plated strings, vintage depleted-uranium core wound pickups and ocelot-tooth guitar pick.
Just play the damn thing.
It's exactly analagous to the idea that you can't truly shred until you've assembled the right set of effects pedals, preamps, niobium-plated strings, vintage depleted-uranium core wound pickups and ocelot-tooth guitar pick.
Just play the damn thing.
This is one of the few times I wish I could upvote someone more than once.
The painful truth about web services is that it doesn't matter what tools you use; at least initially. If it does something useful and you are getting revenue you can and will rearchitect and rework the solution as it grows. And as a system grows it tends to become heterogeneous, an all php shop will suddenly sprout a java based search engine, an ASP.NET shop will throw a linux box in front of it's app servers to act as a reverse-proxy filter/load balancer, and so on. The really good thing about the current state of the art is that you have a multitude of tools available to solve any given problem. The issue is you need to have people who have experience with more than one toolset to make sensible decisions and be able to pick the right solution for the task at hand.
The painful truth about web services is that it doesn't matter what tools you use; at least initially. If it does something useful and you are getting revenue you can and will rearchitect and rework the solution as it grows. And as a system grows it tends to become heterogeneous, an all php shop will suddenly sprout a java based search engine, an ASP.NET shop will throw a linux box in front of it's app servers to act as a reverse-proxy filter/load balancer, and so on. The really good thing about the current state of the art is that you have a multitude of tools available to solve any given problem. The issue is you need to have people who have experience with more than one toolset to make sensible decisions and be able to pick the right solution for the task at hand.
yep spot on. Pick the technology that you have the available skills for right now. As the problems present themselves (and you normally can't predict them because you don't know how your service is going to be used and what strange usage patterns the users will come up with) then solve them.
Its better being adaptable and rolling with the demands than being stuck with a problem you didn't predict that you can't solve without major surgery because everything else is so strictly defined.
Its better being adaptable and rolling with the demands than being stuck with a problem you didn't predict that you can't solve without major surgery because everything else is so strictly defined.
Definitely true.
But we each still like to think about that perfect Gibson Les Paul Custom we would have if we were a rockstar..
But we each still like to think about that perfect Gibson Les Paul Custom we would have if we were a rockstar..
Note the byline: "Senior Analyst, Forrester Research".
To non-programmers like the author, this sort of article is reasonable. Programming is not a creative art, it's just about buying some tools that you read about in the trade magazine.
To non-programmers like the author, this sort of article is reasonable. Programming is not a creative art, it's just about buying some tools that you read about in the trade magazine.
Unfortunately the reality is that some poor coders will be lumbered with whatever the CIO read about in a Forrester report. The article itself counts as "research".
While I agree with your sentiment I'm not sure if that's definitely the case.
First, when you have an average level of programmer (as the sort of corporations that would hire a senior analyst tend to), selecting the right tools is where you can innovate against your competition.
Second, if this wasn't written by a non-programmer, but instead was an Ask-YC "What stack would you use to build the next Google/Facebook/Amazon etc." I don't think this same criticism would be levelled at the author.
First, when you have an average level of programmer (as the sort of corporations that would hire a senior analyst tend to), selecting the right tools is where you can innovate against your competition.
Second, if this wasn't written by a non-programmer, but instead was an Ask-YC "What stack would you use to build the next Google/Facebook/Amazon etc." I don't think this same criticism would be levelled at the author.
Wouldn't you want to hire a senior programmer to make programming decisions?
I'm not sure I get your point in relation to mine, can you elaborate?
I thought you were suggesting hiring analysts to fix the problems that the amateur programmers created. But now that I re-read your post, it seems like you are just observing how the industry works.
Honestly, I think we should feed "analysts" as much bad data as possible so that the companies that rely on analysts are killed off. The analysts will then die too :) (Have you ever poisoned someone to cure their cold? This would be like that. Kill the host, then the virus dies :)
Honestly, I think we should feed "analysts" as much bad data as possible so that the companies that rely on analysts are killed off. The analysts will then die too :) (Have you ever poisoned someone to cure their cold? This would be like that. Kill the host, then the virus dies :)
I have to admit I've never poisoned someone to cure their cold.
It's 100% effective!
I want to develop a Web application - a really good Web app. The kind of Web app that will make me so rich that I can buy an $9.4 million co-op over looking Central Park, a Yacht registered in Monaco, and hire an architect to build my dream-house west of Boston that is a combo of Buckminster Fuller, FLW, and MTV cribs. Throw in a vintage sweet ride like Don Draper's Cadillac and lifetime membership to the Boston Sports Club. I'm set.
I had to re-read the article (and the above paragraph) several times, and check other articles on the site to make sure I wasn't reading a parody site.
I had to re-read the article (and the above paragraph) several times, and check other articles on the site to make sure I wasn't reading a parody site.
I stopped reading after he mentioned "pwn-some Web app". Jesus wept.
Is anyone else tempted to start giving them some ridiculous suggestions, give plausible-to-non-coder explanations and see if they can successfully refute them?
No; it's just written in a language that an enterprise dev's VP would understand.
yeah seriously...it totally depends on the app...how can you define the perfect tools for the job when you explicitly state you don't know what the job is yet?
They give requirements.
Requirements that are uselessly vague. "Architected to never go down"? That's not a requirement, that's wishful thinking. It's as useful a requirement as "Must be attractive to Unicorns."
Engineering a web scale service for robustness is a series of tradeoffs, increasingly expensive tradeoffs as you make the system proof against bigger threats. Geographical redundancy alone more than doubles your costs, and (if you're doing it right) only adds a third or fourth 9 to your availability numbers.
But "Architected to never go down." does not guide the implementer, it doesn't communicate anything they need to know about what the limits of system are; and most importantly it ignores the reality principle.
Engineering a web scale service for robustness is a series of tradeoffs, increasingly expensive tradeoffs as you make the system proof against bigger threats. Geographical redundancy alone more than doubles your costs, and (if you're doing it right) only adds a third or fourth 9 to your availability numbers.
But "Architected to never go down." does not guide the implementer, it doesn't communicate anything they need to know about what the limits of system are; and most importantly it ignores the reality principle.
You're missing the point. This isn't a job ad, it's a question about what would you pick to use if you had to develop a web app. "Architected to never go down" should be read as "Stability is important". No web stack will satisfy everything the author asks for, but they are bringing up all the different factors (or at least most of the broad ones) that need to be considered when making an architecture decision. How would your favourite web stack match up against the different evaluative dimensions?
The fact that you are already bringing up all your expertise on redundancy shows that you can think about this better than others and probably give an answer that fits this requirement well.
The fact that you are already bringing up all your expertise on redundancy shows that you can think about this better than others and probably give an answer that fits this requirement well.
The fact that you are already bringing up all your expertise on redundancy shows that you can think about this better than others and probably give an answer that fits this requirement well.
Unless we completely reinterpret the requirements (as per your suggestion), (s)he really can't. It is impossible to meet the requirement "Architected never to go down."
What actually confuses me more than anything is how wildly the strength of the writer's connection to reality varies. I mean, two of the "requirements" are:
Eh, I dunno.
Unless we completely reinterpret the requirements (as per your suggestion), (s)he really can't. It is impossible to meet the requirement "Architected never to go down."
What actually confuses me more than anything is how wildly the strength of the writer's connection to reality varies. I mean, two of the "requirements" are:
# Architected to never go down
# Employs security features
Eh, I dunno.
I think that you are taking this as a programmer (i.e. too literally).
If I asked you to recommend a car that is fast and safe you wouldn't reply "all cars are fast" and "no car can be perfectly safe", you would suggest a car that maximises those requirements.
Similarly, the author is looking for what frameworks/stacks maximise (among other things) reliability and security.
If I asked you to recommend a car that is fast and safe you wouldn't reply "all cars are fast" and "no car can be perfectly safe", you would suggest a car that maximises those requirements.
Similarly, the author is looking for what frameworks/stacks maximise (among other things) reliability and security.
How is this a joke? The author has given a set of requirements and asked what you think are the best choices to meet those requirements. If you are ever considering a web startup this is a perfect question to ask and one you should know the answer to.
Incidentally I'm a fan of the ASP.NET MVC stack (using MS SQL) for web development, but I don't think it's the most scalable and is unlikely to have a large pool of good developers to source from (you would probably want a good C# or non-MS-hating RoR developer).
Incidentally I'm a fan of the ASP.NET MVC stack (using MS SQL) for web development, but I don't think it's the most scalable and is unlikely to have a large pool of good developers to source from (you would probably want a good C# or non-MS-hating RoR developer).
Scalability shouldn't be a problem. Stack Overflow uses ASP.NET MVC with a SQL server backend, and they're doing over a million hits a day.
No offense but a million hits/day doesn't have much to do with scalability. That comes down to 11 hits/sec - a single midrange server will deal that without breaking a sweat.
Add one or two orders of magnitude, then you're talking about scalability.
Add one or two orders of magnitude, then you're talking about scalability.
In theory and on average, a million hits per day will come down to 11 hits per second. What you're more likely to see in practice though is huge peaks and troughs in load. The average might be 11 hits per second. But the peak load could be 100 hits per second around lunch and the minimum load could be 2 hits per second at 4 AM.
Moreover, a hit is a rather arbitrary unit of measure. 11 hits per second to the Twitter API is a lot different than 11 hits per second to a static site like example.com.
Moreover, a hit is a rather arbitrary unit of measure. 11 hits per second to the Twitter API is a lot different than 11 hits per second to a static site like example.com.
Yes, I ignored the bell curve due to the nature of the site - should have made that clear.
There's not much point even taking that into account for a read-only affair like SO at such a small scale because the cache is doing the work here and that won't sweat even under 100 or 500 reqs/sec.
Anyways, you point out correctly that discussing scaling-issues is rather fruitless without taking all variables into account. I was just trying to say that "SO (in particular) is handling 1mio reqs/day" does not tell much about the performance of the underlying stack.
There's not much point even taking that into account for a read-only affair like SO at such a small scale because the cache is doing the work here and that won't sweat even under 100 or 500 reqs/sec.
Anyways, you point out correctly that discussing scaling-issues is rather fruitless without taking all variables into account. I was just trying to say that "SO (in particular) is handling 1mio reqs/day" does not tell much about the performance of the underlying stack.
Yeah that is true and plentyoffish.com uses ASP.NET too. I'm just thinking like Amazon/Google/Facebook big and whether that would become an issue.
I'm just thinking like Amazon/Google/Facebook big and whether that would become an issue.
Yeah, why solve problems that you actually have when you can fantasize about solving problems you don't have instead?
Yeah, why solve problems that you actually have when you can fantasize about solving problems you don't have instead?
Good point.
However, the whole topic of this thread is fantasising about the perfect stack for that massive site. Besides which, 30 seconds now could save one year in the future (just think if Netscape had thought ahead).
However, the whole topic of this thread is fantasising about the perfect stack for that massive site. Besides which, 30 seconds now could save one year in the future (just think if Netscape had thought ahead).
Myspace was originally written in Coldfusion, they ported to ASP.NET and the current system handles 1.5 Billion page views per day and up to 2.3 million concurrent users (source: MIX Conference 2006 http://www.andreas-kraus.net/blog/handling-15-billion-page-v...)
Thanks!
* It must be really fast
* It must be really safe
* It must be really cheap
* I must be able to do other activities while using it
* It must be ecological - no pollution whatsoever!
I can't tell you where I'm going (next door or to the other side of the world), but I certainly intend to move from my chair at some point, so I think it's really important that I do so in the best way possible. I might take some other people with me as well, please bear that in mind in your recommendation.
So? Anyone? Hello?