"Like Heroku but for PHP" would have been a less arrogant slogan IMHO.
Actually a lot of top tier websites are built in PHP (Facebook's front end is a good example) and so I don't doubt there is middle tail in there that might jump on a Heroku-style managed black box hosting platform.
Put in my email for an invite, its going to come down to pricing.
My initial skepticism is that deploying PHP apps is easy, and Fantastico already gives us 1-click installs for stuff like Drupal and Wordpress. So you'll have to provide all the value on the sysadmin side.
However, we do have a couple of apps that require load balancing. I'm pretty happy with the dedicated server and load balancing prices we get from WiredTree already, but I'm always looking for new opportunities.
The benefit here is the git integration. I'd also assume that the control panel is going to be thousands of times easier to use and more efficient than Cpanel/Fantastico (which is pretty gross in my opinion)
I also dropped my email address in out of interest, but I agree this is definitely something that isn't needed for PHP. The web that we have right now was built for PHP. 99.9999% of hosts support it out of the box, and offer one click installs. If you're running your own app, it's just as easy to get that running with PHP.
What we really need is a Heroku for PYTHON! And Google App Engine is NOT the answer.
BigTable is not a motherfucking key/value store. It's a sorted tuplestore with built-in multidimensionality. Hypertable is a direct clone, HBase and Cassandra use the same style of API but have slightly different storage backends.
Just because it isn't a SQL database doesn't mean it's non-relational or key/value.
Interesting idea! I'm curious to see what exactly this service provides (considering PHP deployment isn't exactly hard, as others mentioned). I would certainly love to see such a setup for Python frameworks...
I don't think there's a huge market for what Heroku does in the PHP world. With Rails, you want to run it as a long-running process. The amount of time to spin up a (Thin|Mongrel|Unicorn|etc.) is too long to do it based on a user request for a page and it's why Rails isn't run as a CGI.
PHP is a bit different. The language is typically embedded in the server and then the individual files are parsed and run. There's little configuration other than uploading the files since the server can just interpret the files ending in ".php".
Heroku needs to be able to put your application code on multiple servers and know which servers are responsible for your application. When one of your Thins isn't working, they need to kill it and spawn a new one, potentially on a new server and make sure they update their routing table. It's a tad complicated.
PHP Fog doesn't have to do much. Heroku is running around 65,000 applications. Assuming that applications are under 30MB (for the hard drive), a RAID-1 with 2TB drives on every server they have would do the trick with a simple load balancer sending requests to a random server would do the trick. Your code is resident on their 15 app servers, a request comes in and gets routed to a random one, it parses your PHP and returns a response. The application isn't in memory as a long-running process like it is with Rails. Heroku already just has shared or dedicated database servers. There's no fancy process monitoring that you need since you only have to ensure that Apache is still going strong.
But that's also why PHP Fog won't do as well. They aren't taking on as difficult a challenge as Heroku. They don't need to run something like god or monit to monitor lots of user processes. They don't need to pre-spawn application servers. They don't need fancy routing to keep track of what domain is being requested, what application belongs to that domain, and on what server that application is located. Because PHP doesn't usually involve long-running processes, it's taken care of for them. In fact, there are services like this already such as Rackspace's Cloud Sites (which puts your PHP or ASP code on multiple boxes, has a shared database, and loadbalances it). The same situation exists with Media Temple's Grid Service. Media Temple says, "hundreds of servers for the price of one". That's possible because the application code takes up such little space and can be easily replicated since it doesn't store state. Rails and Django users on Media Temple have to buy a "container" which comes with a certain amount of RAM on a specific box - because they need to keep the application in memory.
Rails deployment will get a lot more people on board because it's more difficult to do. You have to manage application processes. PHP deployment is already seen as something that "just works". And if someone is going to argue that this "just works" a little better, wait until different users are expecting different php.ini stuff - or they expect to be able to save to the local filesystem because that's what the code they downloaded does or do a highly insecure cross-domain require or all of the various things that can't "just work".
They could still be a very good webhost, but they aren't solving the same problem as Heroku and others (including Media Temple and Rackspace) have already gone the multi-server, auto-load-balanced and managed failover route for PHP (just not using git).
Those are pretty absurd arguments. Have you ever deployed a scalable PHP app? While it might be somewhat easy to deploy a simplest-case PHP site, real sites are much more complicated.
* For good performance you need at least 2 boxes (Web Server and DB)
* For scaling web to 2+ boxes, you need to deal with sessions meaningfully
* For HA/Failover, you need to run a load balancer and infrastructure to keep hot-standby boxes running.
In fact, the only difference between a scaled PHP app and a scaled Rails app is the ruby interpreter. Everything else pretty much you need solutions for on both languages.
When Heroku first came out, I immediately asked when to expect PHP support. Since the answer was "don't expect it", I am glad to see someone else working on a solution.
i disagree, somewhat. yes, this won't provide truly comparable services to heroku. clearly. the languages and stack don't work the same way.
but i think the point of this is to communicate the fact that they're abstracting out the server and scalability details. i'd pay to not have to worry about all that stuff and just work on the app.
if this thing will handle the server for me, keep it secure and up to date, provide me with a database that will scale with my app like amazon's RDS, provide me with meaningful data and metrics about my server/application/database, and provide me with things to make common tasks easier (deploying), then imo, it is worth me paying for it, or paying a small premium on top of what i'd be paying amazon or whoever. but then again, i'm a solo bootstrapper. the more time i have to develop, the better.
"heroku for php" might not be a great choice of a tagline from a strategic perspective, but it is a decent one if you want to consider SEO and organic search results.
this is pretty much what Mediatemple.net already offers with Containers for their GS (shared hosting). They don't have PHP Containers but they do have MySql Containers that are automatically instantiated if traffic spikes.
I think you could really make a difference by offering killer features on demand, like isolated memcached instances, redis, cassandra/mongoDB and RabbitMQ.
But for decent scalable PHP hosting there are lots of options - sure you need to do a little configuration but, as an example, I just purchased another couple of "shares" on Gandi.net tonight.
Adding "share" as extra capacity for a server that needed it took a few seconds. Booting up a new instance on another "share", whipping nginx and my default configuration on took seconds (to set the script off, then it was a 10 minute wait).
So what, I guess, they have to do is put together a comparable service that removes the extra 10 minutes configuration work but adds benefit and doesn't cost any more.
(don't get me wrong - if they make it, I will use it :D)
The "typically embedded" part is where something like this might be useful. PHP doesn't have to be embedded, the FCGI version of PHP runs as it's own daemon and responds to requests from the web server. In that case, management of the PHP daemons falls right under PHP Fog's responsibilities and that is where it adds value.
since rails has so much convention, you can write a system that scales it as long as peopel follow that convention.
PHP is a free for all. Different frameworks do things differently and need to be scaled differently. Lots of people don't use frameworks. I think it will be hard to write a "one size fits all" infrastructure solution for PHP, like what Heroku did for Rails.
the problem that PHP doesn't have is configuring the environment to run it. You just install a few pkgs and boom!
Even plugins come in php itself and aren't seperately pkged. There's no gems, no seperate server to serve the ruby backend. Just upload/push your code and it'll run. And any cheap host would do it. The _only_ advantage I see here is that I can increase my resources for the app (if it's like heroku) just with the click of a button without restarting the server.
But I can't wait to be proved wrong. All the best guys :)