Phaas - anyone interested in setting up Pharo as a Service?
We would love to develop more of our ideas in Pharo, but we are completely allergic to doing sys admin. We don't want to deal with anything below the Pharo application level. What I would ideally like to see if something like Heroku, or similar, but for Pharo. However, just wishing won't make it happen, so I am wondering if there is anyone out there who is thinking about this, and whether there are enough of us to constitute are market. Our requirements are pretty simple. We need a way of uploading an image, and some standard for of persistence. At this point, we would be perfectly happy to make compromises by agreeing that it had to be e.g. Mongo or whatever (although ideally it would be gemstone). We just want to make some progress on this. Personally, I think lots of bits are coming together. We now have various persistence options, websockets (both in Zinc and Aida-web), OAuth ( in both places again), and lots of other exciting elements. We just want a really simple way to take advantage of them. Does anyone else feel this need?
I'd be so happy if something like this existed. However, I'm not sure there are enough Pharo webdevs to make a service like that profitable... But yes, I do feel this need! I'm sick of configuring VPSes with their apache virtual hosts, DBs, etc. 2013/1/26 Andy Burnett <andy.burnett@knowinnovation.com>
We would love to develop more of our ideas in Pharo, but we are completely allergic to doing sys admin. We don't want to deal with anything below the Pharo application level. What I would ideally like to see if something like Heroku, or similar, but for Pharo. However, just wishing won't make it happen, so I am wondering if there is anyone out there who is thinking about this, and whether there are enough of us to constitute are market.
Our requirements are pretty simple. We need a way of uploading an image, and some standard for of persistence. At this point, we would be perfectly happy to make compromises by agreeing that it had to be e.g. Mongo or whatever (although ideally it would be gemstone). We just want to make some progress on this.
Personally, I think lots of bits are coming together. We now have various persistence options, websockets (both in Zinc and Aida-web), OAuth ( in both places again), and lots of other exciting elements. We just want a really simple way to take advantage of them.
Does anyone else feel this need?
-- Bernat Romagosa.
On Jan 25, 2013, at 10:02 PM, Andy Burnett wrote:
We would love to develop more of our ideas in Pharo, but we are completely allergic to doing sys admin. We don't want to deal with anything below the Pharo application level. What I would ideally like to see if something like Heroku, or similar, but for Pharo. However, just wishing won't make it happen, so I am wondering if there is anyone out there who is thinking about this, and whether there are enough of us to constitute are market.
It would be so great! This is a big orthogonal but I know that laurent laffont worked on Harbor. The idea was to provide a better Seaside hosting in the same that you could install it in an easier manner on your machine. I imagine that the work done by nicolas P and mariano/esteban around mongo, fuel⦠fit perfectly.
Our requirements are pretty simple. We need a way of uploading an image, and some standard for of persistence. At this point, we would be perfectly happy to make compromises by agreeing that it had to be e.g. Mongo or whatever (although ideally it would be gemstone). We just want to make some progress on this.
Personally, I think lots of bits are coming together.
Yes me too.
We now have various persistence options, websockets (both in Zinc and Aida-web), OAuth ( in both places again), and lots of other exciting elements. We just want a really simple way to take advantage of them.
Does anyone else feel this need?
you could use cloudfoundry for that :) http://www.cloudfoundry.org/ Esteban On Jan 26, 2013, at 12:25 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jan 25, 2013, at 10:02 PM, Andy Burnett wrote:
We would love to develop more of our ideas in Pharo, but we are completely allergic to doing sys admin. We don't want to deal with anything below the Pharo application level. What I would ideally like to see if something like Heroku, or similar, but for Pharo. However, just wishing won't make it happen, so I am wondering if there is anyone out there who is thinking about this, and whether there are enough of us to constitute are market.
It would be so great!
This is a big orthogonal but I know that laurent laffont worked on Harbor. The idea was to provide a better Seaside hosting in the same that you could install it in an easier manner on your machine.
I imagine that the work done by nicolas P and mariano/esteban around mongo, fuel⦠fit perfectly.
Our requirements are pretty simple. We need a way of uploading an image, and some standard for of persistence. At this point, we would be perfectly happy to make compromises by agreeing that it had to be e.g. Mongo or whatever (although ideally it would be gemstone). We just want to make some progress on this.
Personally, I think lots of bits are coming together.
Yes me too.
We now have various persistence options, websockets (both in Zinc and Aida-web), OAuth ( in both places again), and lots of other exciting elements. We just want a really simple way to take advantage of them.
Does anyone else feel this need?
Hi Andy, Dne 26. 01. 2013 02:02, piše Andy Burnett:
We would love to develop more of our ideas in Pharo, but we are completely allergic to doing sys admin. We don't want to deal with anything below the Pharo application level. What I would ideally like to see if something like Heroku, or similar, but for Pharo. However, just wishing won't make it happen, so I am wondering if there is anyone out there who is thinking about this, and whether there are enough of us to constitute are market.
Our requirements are pretty simple. We need a way of uploading an image, and some standard for of persistence. At this point, we would be perfectly happy to make compromises by agreeing that it had to be e.g. Mongo or whatever (although ideally it would be gemstone). We just want to make some progress on this.
Personally, I think lots of bits are coming together. We now have various persistence options, websockets (both in Zinc and Aida-web), OAuth ( in both places again), and lots of other exciting elements. We just want a really simple way to take advantage of them.
Does anyone else feel this need?
Certainly! Smalltalk as a dynamic language with environment which enables applications to grow organically (saying simpler: to be updated while running) has actually a big potential in the cloud. To provide web services via REST APIs to the so called front-end clients like mobile apps or client-side web apps. And yes, we have now adequate support for REST API services, including OpenID for authentication and OAuth for authorization. Maybe OpenID/OAuth server would be also nice.. You are probably aware of work by Gemstone guys, specially by James Foster, to put Smalltalk web app on the CloudFoundry [1]. This can be the start and their experiences adapting Gemstone to work in existing cloud infrastructure is valuable to tho the same with Pharo. I'd also go adapting Pharo to some existing cloud infrastructure like Amazon, Heroku, CloudFoudry, ... We seems to don't have enough resources to build and maintain our own ones, as experience with our hosting attempts so far shows. It would be also long-term better to join the cloud wave instead building our own replicas. Because a whole IT world goes that way. Best regards Janko [1] Preparing Smalltalk for Cloud Foundry http://programminggems.wordpress.com/2012/02/14/preparing-smalltalk-for-clou... -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
On 26/01/13 02:02, Andy Burnett wrote:
Our requirements are pretty simple. We need a way of uploading an image, and some standard for of persistence. At this point, we would be perfectly happy to make compromises by agreeing that it had to be e.g. Mongo or whatever (although ideally it would be gemstone). We just want to make some progress on this.
I would prefer to upload a MetacelloConfiguration (or something similar) instead of an image. I like to think about the image as a temporary runtime. Not something where I store code or someting I deploy. I would love to have something like: $ pharo -v 1.4-summer myProject.ston where myProject.ston would contain all the necessary information to load my project (dependencies, repositories, etc). This command would create an image with my project on the fly from a stock Pharo 1.4-summer and launch it. It would recreate the image everytime I want to work on my project (or when it is deployed). The problem right now is the loading time for dependencies (try to load seaside in a pristine image, you'll get the point). All the other bricks are there.
On Jan 26, 2013, at 7:30 AM, Francois Stephany <tulipe.moutarde@gmail.com> wrote:
On 26/01/13 02:02, Andy Burnett wrote:
Our requirements are pretty simple. We need a way of uploading an image, and some standard for of persistence. At this point, we would be perfectly happy to make compromises by agreeing that it had to be e.g. Mongo or whatever (although ideally it would be gemstone). We just want to make some progress on this.
I would prefer to upload a MetacelloConfiguration (or something similar) instead of an image.
I built CloudFoundry so that you uploaded a .st file (in my ESUG example it was 'aida.st') that was used to build the image. The server executed the .st file and saved the resulting image (it could load .mcz files directly or execute a Metacello script). Whenever your application was needed, a copy of the saved image was used. James Foster
On 27/01/13 07:04, James Foster wrote:
On Jan 26, 2013, at 7:30 AM, Francois Stephany <tulipe.moutarde@gmail.com> wrote:
On 26/01/13 02:02, Andy Burnett wrote:
Our requirements are pretty simple. We need a way of uploading an image, and some standard for of persistence. At this point, we would be perfectly happy to make compromises by agreeing that it had to be e.g. Mongo or whatever (although ideally it would be gemstone). We just want to make some progress on this.
I would prefer to upload a MetacelloConfiguration (or something similar) instead of an image.
I built CloudFoundry so that you uploaded a .st file (in my ESUG example it was 'aida.st') that was used to build the image. The server executed the .st file and saved the resulting image (it could load .mcz files directly or execute a Metacello script). Whenever your application was needed, a copy of the saved image was used.
That sounds great. http://programminggems.wordpress.com/2012/02/17/adding-smalltalk-to-cloud-fo... http://programminggems.wordpress.com/2012/02/27/using-mysql-in-aida-on-pharo... https://programminggems.wordpress.com/2012/02/28/using-mysql-from-smalltalk-... Are the three articles describing it :) Thanks James
While it is great that one can actually use Smalltalk in Cloud Foundry ... it does require a lot of steps to get it going. Having said that reckon it would be interresting to have an easy to use Pharo-as-a-Service. For persistence maybe rely on things like MongoLab or MongoHQ so you don't have to worry about that? fstephany wrote
http://programminggems.wordpress.com/2012/02/17/adding-smalltalk-to-cloud-fo...
http://programminggems.wordpress.com/2012/02/27/using-mysql-in-aida-on-pharo...
https://programminggems.wordpress.com/2012/02/28/using-mysql-from-smalltalk-...
Are the three articles describing it :)
-- View this message in context: http://forum.world.st/Phaas-anyone-interested-in-setting-up-Pharo-as-a-Servi... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
What if we ask one of existing commercial PaaS providers to add Smalltalk among the languages of choice? This way we achieve one-click Smalltalk cloud apps the fastest way for sure. Right now I'm looking at AppFog http://www.appfog.com. This is CloudFoundry based PaaS provider over the Amazon, Rackspace and Azure IaaS providers. It supports also "unusual" languages like Erlang and Go [1], so maybe they are open for Smalltalk too. James, AppCloud is located in Portland, Gemstone as well, so you are neighbors :) Do you think it would be wise to make a contact with them to start discussing the possibilities? Best regards Janko [1] Languages and Runtimes https://docs.appfog.com/roadmap#langs Dne 28. 01. 2013 09:17, piše Geert Claes:
While it is great that one can actually use Smalltalk in Cloud Foundry ... it does require a lot of steps to get it going. Having said that reckon it would be interresting to have an easy to use Pharo-as-a-Service. For persistence maybe rely on things like MongoLab or MongoHQ so you don't have to worry about that?
fstephany wrote
http://programminggems.wordpress.com/2012/02/17/adding-smalltalk-to-cloud-fo...
http://programminggems.wordpress.com/2012/02/27/using-mysql-in-aida-on-pharo...
https://programminggems.wordpress.com/2012/02/28/using-mysql-from-smalltalk-...
Are the three articles describing it :)
-- View this message in context: http://forum.world.st/Phaas-anyone-interested-in-setting-up-Pharo-as-a-Servi... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
I will contact them and ask what it would take for them to support a new runtime/framework/database. I expect that the primary question will be business opportunity followed by support requirements. James On Jan 28, 2013, at 3:58 AM, Janko Mivšek <janko.mivsek@eranova.si> wrote:
What if we ask one of existing commercial PaaS providers to add Smalltalk among the languages of choice? This way we achieve one-click Smalltalk cloud apps the fastest way for sure.
Right now I'm looking at AppFog http://www.appfog.com. This is CloudFoundry based PaaS provider over the Amazon, Rackspace and Azure IaaS providers. It supports also "unusual" languages like Erlang and Go [1], so maybe they are open for Smalltalk too.
James, AppCloud is located in Portland, Gemstone as well, so you are neighbors :) Do you think it would be wise to make a contact with them to start discussing the possibilities?
Best regards Janko
[1] Languages and Runtimes https://docs.appfog.com/roadmap#langs
Dne 28. 01. 2013 09:17, piše Geert Claes:
While it is great that one can actually use Smalltalk in Cloud Foundry ... it does require a lot of steps to get it going. Having said that reckon it would be interresting to have an easy to use Pharo-as-a-Service. For persistence maybe rely on things like MongoLab or MongoHQ so you don't have to worry about that?
fstephany wrote
http://programminggems.wordpress.com/2012/02/17/adding-smalltalk-to-cloud-fo...
http://programminggems.wordpress.com/2012/02/27/using-mysql-in-aida-on-pharo...
https://programminggems.wordpress.com/2012/02/28/using-mysql-from-smalltalk-...
Are the three articles describing it :)
-- View this message in context: http://forum.world.st/Phaas-anyone-interested-in-setting-up-Pharo-as-a-Servi... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
This is very timely. For last three years I have been trying to get my Rails developer friend (they build fairly large scale educational products) to take a look at Pharo/Seaside/Gemstone... and, funnily enough, the last time we discussed this was 3 days ago over lunch at our local Cafe. But this time he didn't say anything. He just passed me his iPad and showed me the Heroku app managing live performance and services of their applications, with real time monitoring for any latency or bottlenecks issues. He told me they could not seriously consider moving to another language/framework without the same peace of mind of knowing the back-end was well taken care of, so they could focus on development... and know that scaling their applications was no longer an issue. It seems that for most enterprises, hosted 'back-end management' is now the single most important factor in the decision making process of what language/framework to go with. -- View this message in context: http://forum.world.st/Phaas-anyone-interested-in-setting-up-Pharo-as-a-Servi... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Yep, same here. I still use Rails for almost all my client work. Not because of the language/framework but because of a common full stack and easy deployment options (handling attachment is a breeze, deploying is ridiculous). I'm not sure those benefits still stand for big apps you develop in house but for small-medium client work they are crucial. Saying that, most the tools should be portable to Pharo/Seaside quite easily. For example: Error handling: https://github.com/errbit/errbit http://airbrakeapp.com/pages/home Stats and log aggregator: https://github.com/etsy/statsd http://graphite.wikidot.com/screen-shots It's hard to evaluate the market size for a Pharo/Seaside PaaS. Who would pay for it? How much? Do you mind paying 10~20â¬/month per app for a small instance? On 28/01/13 10:32, Nick Smith wrote:
This is very timely. For last three years I have been trying to get my Rails developer friend (they build fairly large scale educational products) to take a look at Pharo/Seaside/Gemstone... and, funnily enough, the last time we discussed this was 3 days ago over lunch at our local Cafe.
But this time he didn't say anything. He just passed me his iPad and showed me the Heroku app managing live performance and services of their applications, with real time monitoring for any latency or bottlenecks issues. He told me they could not seriously consider moving to another language/framework without the same peace of mind of knowing the back-end was well taken care of, so they could focus on development... and know that scaling their applications was no longer an issue.
It seems that for most enterprises, hosted 'back-end management' is now the single most important factor in the decision making process of what language/framework to go with.
-- View this message in context: http://forum.world.st/Phaas-anyone-interested-in-setting-up-Pharo-as-a-Servi... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- http://tulipemoutarde.be +32 65 709 131
On 28 Jan 2013, at 10:49, Francois Stephany <tulipe.moutarde@gmail.com> wrote:
It's hard to evaluate the market size for a Pharo/Seaside PaaS. Who would pay for it? How much? Do you mind paying 10~20â¬/month per app for a small instance?
Euh, that seems like extremely cheap - I am not a RoR/Heroku user, but it seems they are way more expensive, hundreds of $ per month for anything non-trivial, right ?
Yep but the first stage is free and is honestly more than enough for a small website/app (which I guess is the target if 95% Pier setups). Then more processing power (or a background job queue) starts at $35. Database is free up to 10k rows ($9/month up to 10M rows). If you want more data/robustness/speed a database with a 400MB cache is $50/month. I don't know the size of a typical smalltalk webapp but it seems to me that 80% of them are pretty lightweight. The remaining 20% probably already have their custom setup suiting their needs. But I would love to be completely wrong. On 28/01/13 10:55, Sven Van Caekenberghe wrote:
On 28 Jan 2013, at 10:49, Francois Stephany <tulipe.moutarde@gmail.com> wrote:
It's hard to evaluate the market size for a Pharo/Seaside PaaS. Who would pay for it? How much? Do you mind paying 10~20â¬/month per app for a small instance?
Euh, that seems like extremely cheap - I am not a RoR/Heroku user, but it seems they are way more expensive, hundreds of $ per month for anything non-trivial, right ?
I am currently busy with a client who does solid stuff. This means sizeable chunks of money, way above that pricepoint. Phil 2013/1/28 Sven Van Caekenberghe <sven@stfx.eu>
On 28 Jan 2013, at 10:49, Francois Stephany <tulipe.moutarde@gmail.com> wrote:
It's hard to evaluate the market size for a Pharo/Seaside PaaS. Who would pay for it? How much? Do you mind paying 10~20â¬/month per app for a small instance?
Euh, that seems like extremely cheap - I am not a RoR/Heroku user, but it seems they are way more expensive, hundreds of $ per month for anything non-trivial, right ?
That's good to know :) What do they consider? Sysadmin+custom servers? Are you allowed to quantify the load, size of data and budget? Me needs are pretty basic so I assume other's are :p On 28/01/13 11:23, phil@highoctane.be wrote:
I am currently busy with a client who does solid stuff. This means sizeable chunks of money, way above that pricepoint.
Phil
2013/1/28 Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>>
On 28 Jan 2013, at 10:49, Francois Stephany <tulipe.moutarde@gmail.com <mailto:tulipe.moutarde@gmail.com>> wrote:
> It's hard to evaluate the market size for a Pharo/Seaside PaaS. Who would pay for it? How much? Do you mind paying 10~20â¬/month per app for a small instance?
Euh, that seems like extremely cheap - I am not a RoR/Heroku user, but it seems they are way more expensive, hundreds of $ per month for anything non-trivial, right ?
-- http://tulipemoutarde.be +32 65 709 131
It's hard to evaluate the market size for a Pharo/Seaside PaaS. Who would pay for it? How much? Do you mind paying 10~20â¬/month per app for a small instance.
My friend pays $350 month for a bunch of apps, and considers it money well spent. I think that the developer community has a tendency to compare the price of of services with the price of open source software (free) and assume that no-one will pay. In the commercial world though, the comparison is with what it would cost you for hosting PLUS sys admin.. which, for most organisations is both a pain in the ass and very expensive. As Sven mentioned, this is very much a chicken and egg situation. -- View this message in context: http://forum.world.st/Phaas-anyone-interested-in-setting-up-Pharo-as-a-Servi... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
On 28 Jan 2013, at 11:10, Nick Smith <life2point0@gmail.com> wrote:
My friend pays $350 month for a bunch of apps, and considers it money well spent. I think that the developer community has a tendency to compare the price of of services with the price of open source software (free) and assume that no-one will pay. In the commercial world though, the comparison is with what it would cost you for hosting PLUS sys admin.. which, for most organisations is both a pain in the ass and very expensive.
Yes, any serious company making real money, will normally pay closer to $1000/month and often much more for infrastructure. Regarding Heroku, I guess it would be a manageable, realistic project to do a third-party build pack for Pharo Smalltalk, with interfaces to some of the underlying infrastructure (Glorp for PostgreSQL, memcached, maybe also ampq) and to integrate a bit in their ecosystem (logging, monitoring), using some base image containing the necessary libraries, with some vm+image on dynamo validation. There are many others (and thus examples): https://devcenter.heroku.com/articles/third-party-buildpacks This does cost work and thus money. I know there are ways to monetize addons in the Heroku world, so that is a possibility as well. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
"Regarding Heroku..."
That is really interesting Sven. I am a newcomer here, so at present this is beyond my technical capabilities... but it would be wonderful to see Pharo on that list of third-party build packs and able to leverage their infrastructure. I imagine, really frictionless way of allowing folk to deploy and scale quickly. -- View this message in context: http://forum.world.st/Phaas-anyone-interested-in-setting-up-Pharo-as-a-Servi... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Sven Van Caekenberghe-2 wrote
Yes, any serious company making real money, will normally pay closer to $1000/month and often much more for infrastructure.
I may be wrong but at those figures (i.e. 1k/month) there a lot of options, its more the smaller ones who have nowhere to go. Sven Van Caekenberghe-2 wrote
There are many others (and thus examples):
https://devcenter.heroku.com/articles/third-party-buildpacks
Redline Smalltalk is in the list I noticed. -- View this message in context: http://forum.world.st/Phaas-anyone-interested-in-setting-up-Pharo-as-a-Servi... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Hi guys I'm really interested in seeing this egg/chicken problem solved by getting something out the ground. for the visibility of Pharo and smalltalk in general. So I would love to see some proposals and some budgets to see how to Pharo association/ESUG/Consortium/other companies could put money on the table to get started. Stef
My friend pays $350 month for a bunch of apps, and considers it money well spent. I think that the developer community has a tendency to compare the price of of services with the price of open source software (free) and assume that no-one will pay. In the commercial world though, the comparison is with what it would cost you for hosting PLUS sys admin.. which, for most organisations is both a pain in the ass and very expensive.
Yes, any serious company making real money, will normally pay closer to $1000/month and often much more for infrastructure.
Regarding Heroku, I guess it would be a manageable, realistic project to do a third-party build pack for Pharo Smalltalk, with interfaces to some of the underlying infrastructure (Glorp for PostgreSQL, memcached, maybe also ampq) and to integrate a bit in their ecosystem (logging, monitoring), using some base image containing the necessary libraries, with some vm+image on dynamo validation.
There are many others (and thus examples):
https://devcenter.heroku.com/articles/third-party-buildpacks
This does cost work and thus money.
I know there are ways to monetize addons in the Heroku world, so that is a possibility as well.
Sven
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
I did a quick Google and found this Squeak Heroku Buildpack: https://github.com/frankshearar/smalltalk-heroku-buildpack -- View this message in context: http://forum.world.st/Phaas-anyone-interested-in-setting-up-Pharo-as-a-Servi... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
On 28 Jan 2013, at 14:32, Geert Claes <geert.wl.claes@gmail.com> wrote:
I did a quick Google and found this Squeak Heroku Buildpack: https://github.com/frankshearar/smalltalk-heroku-buildpack
That seems pretty recent, I am also not so sure it really works⦠And this worries me: https://github.com/frankshearar/smalltalk-heroku-buildpack#notes He is using a older stack VM because of a 32/64 bit conflict. It would be a shame to lose the use of a Cog based VM. It is not that we need a 64 bit VM, but the 32 bit VM should be compilable against a 64 bit OS. This is beyond my skills... When I said that Heroku would be doable, I did not say it was the best way to go. All this looks still pretty complicated for people without *nix skills. Maybe it is worth the effort for what you get back, I just don't know. I myself like Amazon AWS a lot, but that is not PaaS, but IaaS with lots of options. Also note that there is no such thing as magic scalability... Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
This is very timely. For last three years I have been trying to get my Rails developer friend (they build fairly large scale educational products) to take a look at Pharo/Seaside/Gemstone... and, funnily enough, the last time we discussed this was 3 days ago over lunch at our local Cafe. But this time he didn't say anything. He just passed me his iPad and showed me the Heroku app managing live performance and services of their applications, with real time monitoring for any latency or bottlenecks issues. He told me they could not seriously consider moving to another language/framework without the same peace of mind of knowing the back-end was well taken care of, so they could focus on development... and know that scaling their applications was no longer an issue. It seems that for most enterprises, hosted 'back-end management' is now the single most important factor in the decision making process of what language/framework to go with. -- View this message in context: http://forum.world.st/Phaas-anyone-interested-in-setting-up-Pharo-as-a-Servi... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Hi Andy, On 26 Jan 2013, at 02:02, Andy Burnett <andy.burnett@knowinnovation.com> wrote:
We would love to develop more of our ideas in Pharo, but we are completely allergic to doing sys admin. We don't want to deal with anything below the Pharo application level. What I would ideally like to see if something like Heroku, or similar, but for Pharo. However, just wishing won't make it happen, so I am wondering if there is anyone out there who is thinking about this, and whether there are enough of us to constitute are market.
Our requirements are pretty simple. We need a way of uploading an image, and some standard for of persistence. At this point, we would be perfectly happy to make compromises by agreeing that it had to be e.g. Mongo or whatever (although ideally it would be gemstone). We just want to make some progress on this.
Personally, I think lots of bits are coming together. We now have various persistence options, websockets (both in Zinc and Aida-web), OAuth ( in both places again), and lots of other exciting elements. We just want a really simple way to take advantage of them.
Does anyone else feel this need?
(I am reacting to the whole thread - all this is IMHO) Yes, I think this would be nice to have. The way I see it, the necessary technology is all there. Even better: it was all there years ago (Seaside, AIDA/Web, Glorp, seasidehosting.st, and so much more), and in recent years we made important progress (Pharo taking off as the most forward thinking open source Smalltalk, Cog VM doubling performance, many, many large and small projects adding more and more technologies, interesting fundamental changes in Pharo which are and will pay off big time in the future). If you have been following this list, you know that deploying all kinds of Pharo Smalltalk based applications in the cloud is daily business. But of course, it requires some expertise, some of which is outside Smalltalk itself. A number of people, including myself, could help you with the definition of a production architecture and a way to deploy and operate your application. In the realm of more managed solutions, OpenShift has been done, CloudFoundry has been done. It is not that hard, but it is still pretty technical. So your idea comes down to an easier to use platform for deploying. I would consider uploading images a bit old school. Just specify your app as a Metacello configuration, and let it build by a continuous integration farm working in stages to deal with the longer build times of some packages, but with unit tests. To run, a single expression passed along the command line is enough. Of course, a nice web based management interface is necessary. The challenge is this: to make the platform easier to use, the process and solution space have to be simplified, and choices have to be made. In a community like ours with so many intelligent but also strong headed people, it can be hard to find consensus. In general, that is not a problem: more choices, alternatives, competing ideas, may the best win, are OK - fragmentation is the price to pay. But many complicated choices and alternatives are in conflict with an easy to use platform. For example, Google Apps has a limited set of very specific services, you can't install arbitrary code (so also no Smalltalk). This makes for one clear way to use it. Hence, it might be easier to use. Now, the perspective of doing this commercially is challenging. There currently are probably only a limited number of people really willing to pay for this (and it would depend very much on the choices being made). But that might be a chicken and egg problem: before Ruby on Rails, Ruby was certainly a niche language, in the beginning of RoR, it probably made little sense to do Heroku. But even today, not everybody deploys to Heroku, because they need more control (over resource or money). Maybe it just takes somebody crazy enough to try. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
participants (11)
-
Andy Burnett -
Bernat Romagosa -
Esteban Lorenzano -
Francois Stephany -
Geert Claes -
James Foster -
Janko Mivšek -
Nick Smith -
phil＠highoctane.be -
Stéphane Ducasse -
Sven Van Caekenberghe