Rodeo: 2 questions
Hi Jerry, I'm still reading about Rodeo and trying to evaluate whether to take the plunge. there are a couple of things I don't quite get: 1. The web apps being served by On-Rev: Rodeo server is a highly-scaleable, secure, n-tier architected cloud solution. So there is no way to author and then serve from our own servers, and that means a minimum $10 a month fee for hosting. What about bandwidth? What if someone creates a wildly popular webapp - can they serve some content from a CDN? Any ideas how you would charge for that? 2. Is there any specific strategy offered by On-Rev in your server set-up that allows true scalability and load balancing across regions etc? Or are we realistically going to be stuck with a single shared or perhaps even private server without the ability to scale that? OK for a the vast majority of apps this won't be an issue - but having the option to scale in the event is still an issue. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Rodeo: 2 questions
Of course it's still early days, but we are very serious about having a scaleable backend service. Since one of us is in Australia, we also want geographic coverage. Every day this sector of our industry gets better. Massively shared servers? No. Deals for dedicated servers? Yes. We want this to be a premium service focused on performance. It will not be free. We are not taking on VC for this. There are no ads to support it. It will be fee supported. Best, Jerry Daniels Create iPad web apps with Rodeo: http://rodeoapps.com On May 20, 2010, at 7:45 AM, David Bovill da...@architex.tv wrote: Hi Jerry, I'm still reading about Rodeo and trying to evaluate whether to take the plunge. there are a couple of things I don't quite get: 1. The web apps being served by On-Rev: Rodeo server is a highly-scaleable, secure, n-tier architected cloud solution. So there is no way to author and then serve from our own servers, and that means a minimum $10 a month fee for hosting. What about bandwidth? What if someone creates a wildly popular webapp - can they serve some content from a CDN? Any ideas how you would charge for that? 2. Is there any specific strategy offered by On-Rev in your server set-up that allows true scalability and load balancing across regions etc? Or are we realistically going to be stuck with a single shared or perhaps even private server without the ability to scale that? OK for a the vast majority of apps this won't be an issue - but having the option to scale in the event is still an issue. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Rodeo: 2 questions
On 20 May 2010 14:27, Jerry Daniels jerry.dani...@me.com wrote: Of course it's still early days, but we are very serious about having a scaleable backend service. Since one of us is in Australia, we also want geographic coverage. Every day this sector of our industry gets better. Massively shared servers? No. Deals for dedicated servers? Yes. We want this to be a premium service focused on performance. It will not be free. We are not taking on VC for this. There are no ads to support it. It will be fee supported. Thanks for the info Jerry - very clear. Please keep us posted with details on your plans for backend scaleability using On-Rev. I'll keep investigating using cloud databases for this as i project I am working on needs it - and I can;t see how I would use On-Rev to deliver easy and affordable scalability. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Rodeo: 2 questions
I've worked on several projects with massive numbers of simultaneous users and hits against data. Did this for Nortel, a broadband wireless company and another small telecom. The trick is to know where to scale the hardware and where to put the data and where to put the logic. Look at it in four tiers: 1. Client machine/software (rev client, let's say) 2. Web server (apache, of course) 3. Web application server (assume revServer CGIs) 4. Data (whatever you like...i prefer to roll my own, but to each his/ her own) The cheapest, most scalable and fastest performing are all the same solution: 1. Client: thin 2. Web server: thin, but round-robin'd the IP addresses to 1 of the 13 app servers 3. Web app server: hefty, almost fat 4. Data: thin and agnostic (NO stored procedures) At Nortel, we had 13 app servers. Cheap high-performance Dells. $2000 each. We had ONE database server (SQL server). Most of the code (logic) was on the app server. We had 30 thousand users logging their hours against 50 thousand projects. We had 5000 simultaneous users ever Friday afternoon. We did have a chron job that ran each night to populate the app server with highly indexed data for project look up. The whole thing ran on a browser. Today I would have used a Rev client app, but I would have kept it very thin. Best, Jerry Daniels Use tRev's buy link during your 7 day free trial to get 20% off: http://reveditor.com/tag/shouldiswitch On May 20, 2010, at 10:38 AM, David Bovill wrote: On 20 May 2010 14:27, Jerry Daniels jerry.dani...@me.com wrote: Of course it's still early days, but we are very serious about having a scaleable backend service. Since one of us is in Australia, we also want geographic coverage. Every day this sector of our industry gets better. Massively shared servers? No. Deals for dedicated servers? Yes. We want this to be a premium service focused on performance. It will not be free. We are not taking on VC for this. There are no ads to support it. It will be fee supported. Thanks for the info Jerry - very clear. Please keep us posted with details on your plans for backend scaleability using On-Rev. I'll keep investigating using cloud databases for this as i project I am working on needs it - and I can;t see how I would use On-Rev to deliver easy and affordable scalability. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Rodeo: 2 questions
On 20 May 2010 16:55, Jerry Daniels jerry.dani...@me.com wrote: The cheapest, most scalable and fastest performing are all the same solution: 1. Client: thin 2. Web server: thin, but round-robin'd the IP addresses to 1 of the 13 app servers 3. Web app server: hefty, almost fat 4. Data: thin and agnostic (NO stored procedures) Hi Jerry this is not the sort of scalability that is needed for some interesting classes of apps. First it is very expensive in terms of set up, and then admin. By very expensive I mean more than $1,000. It is the transition between - give the idea a go and wow it's taken off that I'm interested in addressing. If you can get the costs down on that you can do some interesting things. At the progression from basic hosting to the set up you describe is a big expensive jump. Also it does not scale massively for bursts on unpredictable demand. One application I've been asked to get my head around may have up to 1 million concurrent users or it may flop - a pay as you go service like Amazon or Google App engine helps you cope with that. In the world of webApps, I think we can also consider other scenarios: 1. AJAX embeds / Flash / revLet plugins for blogs, webApps on mobiles 2. Client side processing and web service based data = no need for 2) 3. Cloud based DB such as Google AppEngine or Amazon SimpleDB (effectively combines 3 and 4) People buy the apps, come to a separate web site where they can create customised embeds for their blogs or social networks. They can buy or subscribe and this covers the cost of the Cloud DB as it scales ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Rodeo: 2 questions
David, I don't think you'll reach problems of scalability that easily. Twitter and Facebook have scalability issues, you'll probably be fine for months before reaching scaling issues even if you're really successful. Don't think a single server with a single database is no good for your needs. Can you tell me what is the biggest demand you think of for your product because I tend to believe that you'll do just fine with a simple setup. You need massive access and stuff to approach the limits of mySQL or PostgreSQL. Apache is very robust as well and I don't think you'll reach its limit. You're probably safe on On-Rev or Rodeo or whatever is invented soon. Andre On Thu, May 20, 2010 at 1:25 PM, David Bovill da...@vaudevillecourt.tvwrote: On 20 May 2010 16:55, Jerry Daniels jerry.dani...@me.com wrote: The cheapest, most scalable and fastest performing are all the same solution: 1. Client: thin 2. Web server: thin, but round-robin'd the IP addresses to 1 of the 13 app servers 3. Web app server: hefty, almost fat 4. Data: thin and agnostic (NO stored procedures) Hi Jerry this is not the sort of scalability that is needed for some interesting classes of apps. First it is very expensive in terms of set up, and then admin. By very expensive I mean more than $1,000. It is the transition between - give the idea a go and wow it's taken off that I'm interested in addressing. If you can get the costs down on that you can do some interesting things. At the progression from basic hosting to the set up you describe is a big expensive jump. Also it does not scale massively for bursts on unpredictable demand. One application I've been asked to get my head around may have up to 1 million concurrent users or it may flop - a pay as you go service like Amazon or Google App engine helps you cope with that. In the world of webApps, I think we can also consider other scenarios: 1. AJAX embeds / Flash / revLet plugins for blogs, webApps on mobiles 2. Client side processing and web service based data = no need for 2) 3. Cloud based DB such as Google AppEngine or Amazon SimpleDB (effectively combines 3 and 4) People buy the apps, come to a separate web site where they can create customised embeds for their blogs or social networks. They can buy or subscribe and this covers the cost of the Cloud DB as it scales ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution -- http://www.andregarzia.com All We Do Is Code. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Rodeo: 2 questions
Years ago, i did test an XServe G4 running a Sybase ASE 12.5 and went able to get 1500 web served requests / secs without any server's stress at all. And as anyone should know, OS X Server is lots less responsive than Linux or BSD. 2 cents, Best, Pierre Le 20 mai 2010 à 18:49, Andre Garzia a écrit : David, I don't think you'll reach problems of scalability that easily. Twitter and Facebook have scalability issues, you'll probably be fine for months before reaching scaling issues even if you're really successful. Don't think a single server with a single database is no good for your needs. Can you tell me what is the biggest demand you think of for your product because I tend to believe that you'll do just fine with a simple setup. You need massive access and stuff to approach the limits of mySQL or PostgreSQL. Apache is very robust as well and I don't think you'll reach its limit. You're probably safe on On-Rev or Rodeo or whatever is invented soon. Andre On Thu, May 20, 2010 at 1:25 PM, David Bovill da...@vaudevillecourt.tvwrote: On 20 May 2010 16:55, Jerry Daniels jerry.dani...@me.com wrote: The cheapest, most scalable and fastest performing are all the same solution: 1. Client: thin 2. Web server: thin, but round-robin'd the IP addresses to 1 of the 13 app servers 3. Web app server: hefty, almost fat 4. Data: thin and agnostic (NO stored procedures) Hi Jerry this is not the sort of scalability that is needed for some interesting classes of apps. First it is very expensive in terms of set up, and then admin. By very expensive I mean more than $1,000. It is the transition between - give the idea a go and wow it's taken off that I'm interested in addressing. If you can get the costs down on that you can do some interesting things. At the progression from basic hosting to the set up you describe is a big expensive jump. Also it does not scale massively for bursts on unpredictable demand. One application I've been asked to get my head around may have up to 1 million concurrent users or it may flop - a pay as you go service like Amazon or Google App engine helps you cope with that. In the world of webApps, I think we can also consider other scenarios: 1. AJAX embeds / Flash / revLet plugins for blogs, webApps on mobiles 2. Client side processing and web service based data = no need for 2) 3. Cloud based DB such as Google AppEngine or Amazon SimpleDB (effectively combines 3 and 4) People buy the apps, come to a separate web site where they can create customised embeds for their blogs or social networks. They can buy or subscribe and this covers the cost of the Cloud DB as it scales ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution -- http://www.andregarzia.com All We Do Is Code. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution -- Pierre Sahores mobile : (33) 6 03 95 77 70 www.wrds.com www.sahores-conseil.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Rodeo: 2 questions
I think you miss understand what I'm saying or your experiences don't match my own. What I suggest is not expensive and is, in effect, what most n-tier architected solutions do. I learned from a couple guys who invented data access via a stateless browser. But what do they know? You might be surprised by what's going on under the covers of Amazon, Google and the other commodity services. Best, Jerry Daniels Create iPad web apps with Rodeo: http://rodeoapps.com On May 20, 2010, at 11:25 AM, David Bovill da...@vaudevillecourt.tv wrote: On 20 May 2010 16:55, Jerry Daniels jerry.dani...@me.com wrote: The cheapest, most scalable and fastest performing are all the same solution: 1. Client: thin 2. Web server: thin, but round-robin'd the IP addresses to 1 of the 13 app servers 3. Web app server: hefty, almost fat 4. Data: thin and agnostic (NO stored procedures) Hi Jerry this is not the sort of scalability that is needed for some interesting classes of apps. First it is very expensive in terms of set up, and then admin. By very expensive I mean more than $1,000. It is the transition between - give the idea a go and wow it's taken off that I'm interested in addressing. If you can get the costs down on that you can do some interesting things. At the progression from basic hosting to the set up you describe is a big expensive jump. Also it does not scale massively for bursts on unpredictable demand. One application I've been asked to get my head around may have up to 1 million concurrent users or it may flop - a pay as you go service like Amazon or Google App engine helps you cope with that. In the world of webApps, I think we can also consider other scenarios: 1. AJAX embeds / Flash / revLet plugins for blogs, webApps on mobiles 2. Client side processing and web service based data = no need for 2) 3. Cloud based DB such as Google AppEngine or Amazon SimpleDB (effectively combines 3 and 4) People buy the apps, come to a separate web site where they can create customised embeds for their blogs or social networks. They can buy or subscribe and this covers the cost of the Cloud DB as it scales ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Rodeo: 2 questions
Absolutely. Best, Jerry Daniels Create iPad web apps with Rodeo: http://rodeoapps.com On May 20, 2010, at 11:49 AM, Andre Garzia an...@andregarzia.com wrote: You're probably safe on On-Rev or Rodeo or whatever is invented soon ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Rodeo: 2 questions
David, Not sure if there was a Rodeo question or something in there, but I will try to clarify, etc. Rodeo is not a hosting package. We host your LIST code and translate it into iPad web app pages. You don't get an ftp addess or anything like that, so, no it's not a standard On-Rev package. I have mentioned On-Rev, etc because we like the technology and recommend it. We are also using it for Rodeo at this very moment, and we are in discussion with Kevin to throw more resources at it for our users, based on demand, of course. I'm not sure I understand what you're going for here. You do or don't have a gazillion users and you need or don't need a beefy server solution. You're heard: If you build it they will come? There's a better one: If they come, you'll be able to build it. Money. It's about the money. Get some money and you can do whatever you want. There's some great stuff out there. Best, Jerry Daniels Use tRev's buy link during your 7 day free trial to get 20% off: http://reveditor.com/tag/shouldiswitch On May 20, 2010, at 2:13 PM, David Bovill wrote: On 20 May 2010 19:21, Jerry Daniels jerry.dani...@me.com wrote: Absolutely. Best, Jerry Daniels Create iPad web apps with Rodeo: http://rodeoapps.com On May 20, 2010, at 11:49 AM, Andre Garzia an...@andregarzia.com wrote: You're probably safe on On-Rev or Rodeo or whatever is invented soon Ok. Still would be good to get some detail. As far as I can tell at the moment Rodeo is: 1. offered on a standard On-Rev hosting package. 2. but it is on a dedicated server 3. it will be possible to arrange further traditional load balancing and add extra servers as demand requires 4. that we can expect such an infrastructure to cope with several thousand users at a time, but probably not hundreds of thousands of concurrent users. It would be interesting to know the details because having a clear migration path that On-Rev users can plan for is a particular issue - because it is not quite so straight forwards to migrate an On_Rev application to other hosting - though hopefully the revServer package will make this easier. In terms of cost, the point I am making is that you get good capacity for free for instance with Amazon SimpleDB, and you don;t have to do anything to scale it - just pay for the actual usage. N-tier requires a hundred if not thousands of pounds up front. Also if you need to plan for many hundreds of thousands of concurrent users - then again something like SimpleDB or the equivalent becomes an interesting option. These options were not available to developers until very recently. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Rodeo: 2 questions
Andre- Thursday, May 20, 2010, 9:49:57 AM, you wrote: David, I don't think you'll reach problems of scalability that easily. Twitter and Facebook have scalability issues, you'll probably be fine for months before reaching scaling issues even if you're really successful. Twitter, Digg, Reddit, etc are indeed reaching the scalability limits of their databases, and are moving into the NOSQL world of Cassandra, Hadoop, CouchDB... but you need to up at the level of shoveling around petabytes of data before you need to start dealing with those issues. And dealing with NOSQL databases means you need to know your data formats and how you're going to be using them before you start, because once you slice and denormalize your data into various storage compartments you lose things like the ability to do adhoc searching. -- -Mark Wieder mwie...@ahsoftware.net ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Cloud databases and scalability (was Rodeo: 2 questions)
On 20 May 2010 21:52, Mark Wieder mwie...@ahsoftware.net wrote: Twitter, Digg, Reddit, etc are indeed reaching the scalability limits of their databases, and are moving into the NOSQL world of Cassandra, Hadoop, CouchDB... but you need to up at the level of shoveling around petabytes of data before you need to start dealing with those issues. And dealing with NOSQL databases means you need to know your data formats and how you're going to be using them before you start, because once you slice and denormalize your data into various storage compartments you lose things like the ability to do adhoc searching. Thanks for the input Mark - terabytes of data is not likely, and would also be expensive. The biggest real world problem is lots of concurrent users. For a live event - for instance something that would be promoted on TV, you might get a lot of users in one go - then nothing. Amazon SimpleDB seems an interesting way to cope with one off high capacity surges like this at very low cost (as long as the data fields are small). Can anyone advise on how you would do a stress test to replicate say 100,000 concurrent users - are their tool kits or a company perhaps that is set up to do that sort of thing? ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
