

Heroku for... - garethr
http://morethanseven.net/2010/12/29/Heroku-for....html

======
randall
Don't forget DotCloud... they're like Heroku for all of these.

~~~
shykes
Solomon @DotCloud here - thanks for mentioning us. We're convinced that the
"one language, one platform" model can't work as a sustainable business, for
various reasons. Heroku has learned that lesson as well, but we're taking a
shortcut :)

If you want an early invite, mention HN in your registration and we'll hook
you up.

------
danhak
Looks like there's a huge opportunity in the .NET game...one of those
providers looks amateurish and the other isn't even running yet. I would
definitely pursue that if I didn't have my hands full.

~~~
vyrotek
I noticed this too. We run on Azure but I would love to evaluate other
options.

But, could someone really compete with Windows Azure and all the features that
come with it? It would take a startup quite a bit of time and money to match
services such as Blob Storage, Table Storage, Message Queues and Distributed
Caching.

Perhaps those features aren't for everyone. I guess there is still a need for
quickly and easily creating nodes running IIS.

~~~
troethom
There are alternatives to all these services.

People have used S3 even before hosting at EC2, and if you like, you can use
Blob Storage without hosting at Azure too.

Table Storage, message queues and distributed caching exists in various
flavors - and your point about not everybody needing these things are indeed
true.

A common interface to avoid vender lock-in will be the next big step...

------
jpcx01
How about another Heroku for Ruby? Could use some competition I think, and the
market is already proven.

Seems like it should be straightforward replicate the functionality for a
lower price and get a good percentage of the Heroku user base. Nothing really
ties people to the platform. And the addon's should work with pretty much any
EC2 based platform as a service.

~~~
ig1
EngineYard

~~~
jpcx01
Cloud is a good product. But it basically just resell AMZN ec2 instances and
doesn't provide the simplicity of Heroku. I switched from EY to Opscode's
Platform and it's both much cheaper and much more powerful.

edit: ok, I love engineyard and the people there. I'm really sorry to say that
EY cloud is not actually a good product. I despise it. Probably the worst tool
I've ever used to deploy rails.

~~~
samstokes
_Cloud is a good product._

 _Edit: [snip] EY cloud is not actually a good product. I despise it._

Why the change of heart?

~~~
jpcx01
I was just trying to be nice. But then realized I'd rather be honest than
nice.

------
kaylarose
I have evaluated a few of the these for PHP deployments recently, here are my
thoughts (from comment on the article):

Cloudfront: Pros: Best "Heroku" for PHP. Fair pricing. Deployment process is
sort of similar to Heroku Cons: Documentation is lacking, and in some cases
flat out wrong. Lacking "heroku-y" polish. Customer support needs improvement
(replies to questions/bug reports were a bit gruff). Other: Have to use
Mercurial (ability to use Git is documented, but wrong [see documentation in
Cons])

Kodigen: Pros: Lots of options. Good pricing. Cons: Lots of options. Very
complicated/busy UI. Have to use in-browser code editor. Hard to find relevant
documentation. Other: Probably more for hobbyists.

All in all - for intermediate or advanced developers - there isn't really much
of an advantage to using one of the mentioned PaaS vs. FTP or scripted
deployments (capistrano, etc.) to regular hosting.

------
diego
All the Python ones other than GAE are in different beta stages. I hope one of
them becomes as good as Heroku, Google would be incredibly tempted to buy
something like that. GAE seems designed to assimilate apps into Google rather
than to serve the needs of developers.

~~~
shantanubala
I remember reading somewhere that Google was trying to get pure Django code to
work on App Engine (with limited support for queries, of course), and I am
very interested to see how that goes. If that happens, (and App Engine gets
SSL and an SLA), App Engine will probably come out on top.

But the competition never hurts.

EDIT: <http://code.google.com/appengine/docs/roadmap.html>

At the moment, Google only has "bulk datastore import/export tool" on their
roadmap, which implies that they are trying to reduce their lock-in at least a
little.

EDIT 2: <http://code.google.com/appengine/articles/django-nonrel.html>

Looks like you technically _can_ run pure Django with some limitations.

------
SoftwareMaven
It's sad that one of the originals in the space that I worked at (Bungee Labs,
<http://www.bungeeconnect.com/>) couldn't quite make it work. They had an
amazing technology but very poor customer development: up to the day they
closed the doors, I don't think they could have identified their target
customer beyond "developers".

~~~
sgrove
That's a interesting point I'm very interested in - how should they (or any of
these services) be able to identify their target customers?

~~~
SoftwareMaven
Developers is still too broad, that's for sure. I would have started by
spliting it into problem domains: enterprise apps, enterprise middleware,
enterprise foundations, consumer apps, etc. For each of these, I'd identify
salient requirements: enterprise apps need to be easy to build, handle lots of
form-ish data, connect with disparate systems; consumer apps needs strong
branding capability, etc. As with any market analysis, this would include
information about size of market, number of dollars, how the customers behave,
etc.

I would then have identified our core competencies: amazing browser
interaction, strong form builder, strong component re-use architecture,
automated version control and deployment to the cloud, etc.

Take the first, overlay it with the second, and start sorting by "closest" and
"number of dollars."

The closest we were to identifying a market was (more by default than choice)
"consumer apps." Unfortunately, that's a really bad market for development
tools because there are so many good, free ones available.

We later tried switching to enterprise apps, but we had significant
deficiencies there (poor integration support [great web services support, good
RDB support, but no other integration options], no on-premise deployment (a
real problem for most enterprises, especially two years ago), among others.

Since we weren't willing to commit to that market segment to fill the holes
(instead, focusing on developing a little of everything), we couldn't build a
compelling sales story.

Ultimately, the problem was they put their headphones on, started coding,
looked up three years later, then tried to scramble to figure out how to take
everything they'd built and get people to use it. They should have started
from day one looking for customers to work with, started telling their story
to see what resonated, and adjusted their roadmap to match.

------
brandnewlow
I wish there was a Heroku for Drupal. Over the last three years I've learned
how to twist that poor project into all sorts of fun shapes. Deploying it
quickly and reliably on a new domain is a real pain in the butt though.

~~~
endlessvoid94
There is: <http://getpantheon.com/>

They're awesome folks -- the same people from Chapter Three in SF. They
already have some high-paying customers, so I imagine they'll be around for a
long time.

~~~
brandnewlow
Holy cow. Just signed up for the beta and watched the demo video from
DrupalCon. This looks terrific. Thanks for the heads up! The list of the tech
stack they give you is absolutely perfect.

------
vladd
You can add to the list <http://www.erbix.com/> (for server-side JavaScript).
We're using RingoJS as an engine (you can go to
<http://www.erbix.com/documentation/overview/nodejs/> for a comparison with
NodeJS).

Disclaimer: I'm affiliated with the Erbix project.

