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.
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.
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.
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...
biasLogic runs in//across azure, amazon and also local remote servers depending upon need and technologies used. We focus on integartion across the cloud and cloud PaaS/SaaS and Developer API's - We make it easier for a developer or enterprie to move to the cloud and provide a way to avoid vendor lock-in at a cloud/IaaS level and are designed to work with existing PaaS platforms even though we are a PaaS in a way ourselves. (yes you can run locally inside your network if you want..) drop me a line personally at: scott.worley@biaslogic.com --> we are coming out of stealth in the next couple months.
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.
By "straightforward replicate the functionality" you mean hire a team of 20 and spend 3 years building your own platform fabric? I wouldn't trivialize work product or the capabilities of the Heroku team. Building multi-tenant infrastructure is quite a bit more difficult than it sounds.
I totally agree. straightforward != easy. That's why I'm not chomping at the bits to do it myself :-). But the opportunity and potential is there, there should be some investors and star developers who should take it.
Sure but the integration of the addons is tightly done, and there'll be a commercial contract with these companies. You'd probably need a similar contract with those addon providers which they may not be willing to provide if they've an exclusive contract with Heroku.
And don't forget the number of free applications running on Heroku, these aren't making them any profit at all and are using up a lot of resources.
Every one of those addons is available directly from the vendor. The addons just set some ENV variables, or auto installs a plugin on deploy. Plus the provisioning apis are well documented so you could easily replicate it on a competing service so existing addon's would work with no additional dev effort needed by the addon provider (I've deployed a heroku addon).
Yep, good point on the free apps. I don't think a competitor would have to offer free apps though if they were able to lower the cost for paid installs and use the exact same deployment tools.
To use the addons in a standalone setup you need to create an account at the provider's website. I assumed that Heroku had some agreement with the providers which lets them bypass this and instead passes on the user's Heroku details transparently
Yep, these are handled via the provisioning apis. When the addon is installed, the service gets a simple provision api request with the customer details. When the addon is uninstalled, there's a deprovision api request.
Heroku Addons are super well documented and easy to develop and deploy. One of the best parts of the platform.
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.
While EngineYard is cloud Ruby hosting, they actually offer a very different product. Heroku is like "Accept a few limitations, never worry about anything," while EngineYard is like "Don't worry about ever writing Chef scripts again."
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.
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.
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.
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.
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".
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.
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.
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.
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.
