Phaas - anyone interested in setting up Pharo as a Service?

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:
--
http://tulipemoutarde.be
+32 65 709 131

Hi Andy,

On 26 Jan 2013, at 02:02, Andy Burnett <[hidden email]> 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

On 28 Jan 2013, at 10:49, Francois Stephany <[hidden email]> 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 ?

> 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.

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 <[hidden email]> 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.

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, [hidden email] wrote:
--
http://tulipemoutarde.be
+32 65 709 131

On 28 Jan 2013, at 11:10, Nick Smith <[hidden email]> 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

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:
--
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si

> "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.

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.

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

I did a quick Google and found this Squeak Heroku Buildpack: https://github.com/frankshearar/smalltalk-heroku-buildpack 

On 28 Jan 2013, at 14:32, Geert Claes <[hidden email]> 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

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 <[hidden email]> wrote:

I have some ideas I would like to discuss off-line. Anyone interested should contact me at [hidden email].

James

On Jan 26, 2013, at 8:04 AM, Stéphane Ducasse <[hidden email]> wrote: