>Similarly to C++ relation to C, Azure+ is Azure done right and useble
There's a certain class of people who will see this and think "Ha! The product must be a thoughtless inconsistent kludge of new features, tacked haphazardly onto a perfectly fine strong, simple, performant base for popularity's sake".
Although, i suspect there's very little overlap with your target audience.
My apologies too, I don't mean to criticise without trying your product. It seems like you've made a lot of advances.
I see where you're going, i just think the analogy would be inappropriate if this were a product aimed at C or C++ developers (which it isn't). Perhaps, "Notepad to Notepad++"?
So this is for Windows people who want to run PHP in the cloud? Is that a big enough market to sustain a SAAS company?
I'd think most Windows people gravitate toward Microsoft/.NET based web technologies.
Good for a 6am-because-I-stayed-up-all-night laugh though.
The post is devoid of any information that is actually useful and seems like a medium for pointless meme comics.
Why do I care about this? You need to answer this question within the first paragraph, if not sentence.
This is the polar opposite of good copy.
I will use this anti-example in my next discussion of copywriting with my employers/clients.
SAAS/PAAS for PHP/Windows programmers? The punchline writes itself.
Automation of internal infrastructure is good, but you're not really going to be able to improve upon or otherwise differentiate yourself from any of the existing providers.
It's not really for Windows people. It runs on Windows, but a normal PHP app can be deployed to it too. So as much as there is negativism against Windows, this doesn't require knowledge of it or using of any of it's features.
What's different now is the flexibility of live-change configuration and once it goes live - much better (think cheaper) pricing.
Maybe I'm missing something here… but is there a particular reason that you built your service atop what you admit yourselves to be a crap platform, other than "nobody else is doing it"?
Seems to me there's a reason nobody else was doing it.
It's not really good platform from developers perspective, the one deploying stuff. But it's not a bad platform from platform perspective and allows great things to be built on top who actually make it fine for developers. Makes sense?..
I'm having trouble understand the value-add here. PHP is so dominant specifically because it's so easy to deploy - it's everywhere, and requires next to nothing to have a working installation up and running. There's no compelling reason to run PHP on Windows over Linux (and a bunch of reasons not to). The one feature that might sell me is a Heroku-style "addons" system, with things like Memcached, Redis, error aggregation and reporting, logging, and the like all ready to deploy at the touch of a button, but there's no mention of anything like that.
So, sell me. Why would I pay a premium for Azure+ when I can roll out my own equivalent infrastructure trivially, or use the existing competitor?
Git supports hooks, so you could write a script to push a branch out to a server whenever a commit is made. That would be more sensible than running 'git pull' in a cron job.
You can configure a Git repository we are going to pull code from every minute or so. Once we find new commits they are going to be automatically deployed to the cloud."
... so it sounds like they did not take the sensible route either ;)
Sure, and I'd expect any PaaS to have dynamic scaling. The question is, though, how many people really need a dynamic scaling PHP service? In your average web app, you're far more likely to bottleneck in the database before the application requests queue (and the DB is significantly harder to horizontally scale), and if you do need more application CPU, it's generally as easy as "put multiple VMs behind a load balancer". You can even auto-scale with AWS using existing toolkits.
Heroku made its mark because Rails deployment is (or was, anyhow) a lot of work if you don't know what you're doing, and they simplified it to as-easy-as-PHP deployment. PHP just doesn't have the same barrier to entry.
Well, let's look at the options:
- Run own server. Buy hardware, find colo etc. I guess the advantages of PaaS are obvious here.
- Run vps, manage yourself. Required: somebody to buy/maintain the machine, plus a lot sysadminning. Advantages of PaaS obvious, too.
- Run managed vps. Advantages of PaaS become less obvious. Maybe more supported versions, more specific functionality. Or automatic scaling (from tweaking db disk access times to network-level load-balancing); you don't get that with a managed vps.
I guess my point is that rolling out your own equivalent infrastructure is far from 'trivial'. Buying machines, worrying about mundane details like amps on the power backbone, setting up and maintaining the server software (lol at the first person - there always is one - to suggest that this can be solved with putting 'apt-get update' or equivalent in cron), or testing various versions of infrastructure software with your app because you don't know if it'll be safe to deploy that update that came out yesterday - I don't use PaaS but I see many advantages for small-time operations (and maybe bigger ones too, maybe I'd trust them more if I had more experience with them).
I understand the benefit of PaaS; I've used Heroku on occassion, and PHPFog seems to be making in the space as well. If you just want an app online, and don't care about how it gets there, and have more money than system administration skill, PaaS is great. My question is more along the lines of "What do I get with Azure+ that I don't get with PHPFog or an existing AWS AMI or a Linode StackScript?" What's the killer feature? It's going to be more expensive (you get to buy a cloud-sized slice of a Windwos license), likely slower than a Linux platform (the benchmarks I've seen put PHP on Windows significantly behind Linux deploys), and so far, it doesn't solve the hard parts of a PHP application deployment.
I'm a Rails developer, mostly, and I have Heroku apps, apps running on Linode VMs, apps running on rented Rackspace servers, and apps running on AWS. I've got a lot of experience setting this stuff up and maintaining it, but I still really appreciate the simplicity of Heroku; a dashboard of services and extensions ready to install in a click is awesome. Heroku's killer feature isn't that you don't have to set up RVM and Passenger, it's that you don't have to write bundles of daemon managers, monitoring scripts, rake tasks to manage code deploys and reloads, git hooks, background worker management, and a bunch of otherwise-tedious stuff.
The sales pitch for Azure+ seems to be "We solved a problem that only exists on Azure", which just isn't very compelling. So far, it seems like the only target audience for this thing is people who will only deploy PHP apps on Azure and don't have any other options, period, which seems like a really small target audience.
Why would I pay a premium for Azure+ when I can roll out my own equivalent infrastructure trivially, or use the existing competitor?
Because "you" have another reason to use Windows and would like to offer a PHP front-end for it. What other reason? Expertise, another application, etc.
I think the upside for a PHP PaaS is the existing market of commercial & open source deployable PHP application packages. A sort of app store could be created where vendors package their application with some special hooks for the platform. Obviously this would have to be bootstrapped, but I'm sure you see where I'm going with this.
so it looks like right now you have nothing, just the idea of a PHP cloud platform built on the MS cloud. What exactly makes this better than say PHPFog who have a Heroku Style solution for PHP that is already solid and proven ?
This is a non-starter from many angles, aside from the choice of platform/language, a choice in which they completely missed what the actual target market does and how they do it. Inconsiderate product/market fit.
I wouldn't be so negative if the ignorance of the copy and comments weren't so palpable.
I see Microsoft having to slap him with a notice just because they have to defend the trademark.. not necessarily because they want to. Bad form on his part.
In my experience, writing PHP on one platform and deploying it on another doesn't always work out. Your developers have to be aware of where their app will be deployed and the specifics of that OS.
> I think PHP support on Windows is as good as on any other OS.
I have seen several things fail in that environment - escaping shell commands and arguments is problematic, invoking external executables is only reliable when full path is used [1], realpath() (used to, at least) chokes on / as a directory separator... Autoloading classes based on classname => filename can produce funny results. File uploads can work differently (case sensitive filenames - foo.jpg and foo.JPG can coexist in Linux, but not in Windows).
On the other hand, there are things like the new MSSQL PDO driver that only exist in the Windows world.
---
[1] Windows 2003 Server was running our app, which invoked Imagick similar to `convert $input.jpg $output.jpg`.
Worked just great for half a year.
Deployed to a second machine, Windows 2008 Server.
Command execution fails silently.
Change %PATH% to be identical to the old server's one.
Restart.
Still fails.
Compare phpinfo().
$_ENV['PATH'] in new server doesn't match %PATH% (it appears
to be re-sorted with windows folders first), $_ENV['PATH'] in old server matches %PATH%.
Messing around with new %PATH% changes nothing, new server keeps giving PHP the silently-reordered %PATH%.
Nothing helps, short of specifying full path to `convert`.
I see a lot of negative comments, but I actually think it is quite interesting that they are targeting Windows/ Azure. There are situations in which the platform to deploy the apps has been decided higher up in the organization (that can be for a variety of reasons, some more rational than others) and in many cases it is Windows. In that case the question is not whether it is better to use Heroku or Azure, it is how to make Azure suck less :) The AppHarbor guys are doing well with a similar approach to .NET As a reference point, I am one of the developers of BitNami.org (we also provide a cloud hosting service) and we get over 150k developers every month coming to the site to get LAMP environments, Wordpress, Drupal, etc. You will be surprised at the (quite high) percentage of those developers that run open source web apps (PHP, Java, Ruby) on Windows. Again, not recommending that you do so, just remarking it is not as weird as some of the comments here make it look (though HN is probably not the target audience :)
"If you have tried to deploy anything to Azure you'll know that it takes 15 or more minutes, which is unacceptable!"
I've been using Azure for a year and a half. I feel like I know it pretty well. Yes, this was a problem originally but has been solved with the Web Accelerator. You can now deploy your web projects instantly across all nodes.
I can only laugh when I see 'Azure done right'. Isn't that http://AppHarbor.com tagline too? Sorry, but you don't buy Azure for a single web box for your toy project. You buy it for the suite of other features that are all available in the same datacenter. Message Queues, NoSql (Table Storage), SQL Azure and many other enterprise level feature.
> Right now we are working on adding MySQL support, so you can port pretty much any existing app.
If you're offering a PHP PaaS, shouldn't you plan support for the de facto standard PHP RDBMS out of the gate?
> Currently a group of 15 or so people is actively testing this and is sending us valuable feedback. Nevertheless it’s quite close to production-quality service and you’ll hear more about it very soon.
Be careful there. 15 people is not a large enough sample size to claim that your distributed system is "close to production-quality". There are plenty of assumptions that work for 15 people that could completely fall over at scale.
37 comments
[ 0.23 ms ] story [ 131 ms ] thread>Similarly to C++ relation to C, Azure+ is Azure done right and useble
There's a certain class of people who will see this and think "Ha! The product must be a thoughtless inconsistent kludge of new features, tacked haphazardly onto a perfectly fine strong, simple, performant base for popularity's sake". Although, i suspect there's very little overlap with your target audience.
I see where you're going, i just think the analogy would be inappropriate if this were a product aimed at C or C++ developers (which it isn't). Perhaps, "Notepad to Notepad++"?
Btw, how is it different from PHP Fog?
The post is devoid of any information that is actually useful and seems like a medium for pointless meme comics.
Why do I care about this? You need to answer this question within the first paragraph, if not sentence.
This is the polar opposite of good copy.
I will use this anti-example in my next discussion of copywriting with my employers/clients.
SAAS/PAAS for PHP/Windows programmers? The punchline writes itself.
Automation of internal infrastructure is good, but you're not really going to be able to improve upon or otherwise differentiate yourself from any of the existing providers.
What's different now is the flexibility of live-change configuration and once it goes live - much better (think cheaper) pricing.
Seems to me there's a reason nobody else was doing it.
So, sell me. Why would I pay a premium for Azure+ when I can roll out my own equivalent infrastructure trivially, or use the existing competitor?
"Pulling code from a repository
You can configure a Git repository we are going to pull code from every minute or so. Once we find new commits they are going to be automatically deployed to the cloud."
... so it sounds like they did not take the sensible route either ;)
Heroku made its mark because Rails deployment is (or was, anyhow) a lot of work if you don't know what you're doing, and they simplified it to as-easy-as-PHP deployment. PHP just doesn't have the same barrier to entry.
I guess my point is that rolling out your own equivalent infrastructure is far from 'trivial'. Buying machines, worrying about mundane details like amps on the power backbone, setting up and maintaining the server software (lol at the first person - there always is one - to suggest that this can be solved with putting 'apt-get update' or equivalent in cron), or testing various versions of infrastructure software with your app because you don't know if it'll be safe to deploy that update that came out yesterday - I don't use PaaS but I see many advantages for small-time operations (and maybe bigger ones too, maybe I'd trust them more if I had more experience with them).
I'm a Rails developer, mostly, and I have Heroku apps, apps running on Linode VMs, apps running on rented Rackspace servers, and apps running on AWS. I've got a lot of experience setting this stuff up and maintaining it, but I still really appreciate the simplicity of Heroku; a dashboard of services and extensions ready to install in a click is awesome. Heroku's killer feature isn't that you don't have to set up RVM and Passenger, it's that you don't have to write bundles of daemon managers, monitoring scripts, rake tasks to manage code deploys and reloads, git hooks, background worker management, and a bunch of otherwise-tedious stuff.
The sales pitch for Azure+ seems to be "We solved a problem that only exists on Azure", which just isn't very compelling. So far, it seems like the only target audience for this thing is people who will only deploy PHP apps on Azure and don't have any other options, period, which seems like a really small target audience.
Because "you" have another reason to use Windows and would like to offer a PHP front-end for it. What other reason? Expertise, another application, etc.
I wouldn't be so negative if the ignorance of the copy and comments weren't so palpable.
> I think PHP support on Windows is as good as on any other OS.
I have seen several things fail in that environment - escaping shell commands and arguments is problematic, invoking external executables is only reliable when full path is used [1], realpath() (used to, at least) chokes on / as a directory separator... Autoloading classes based on classname => filename can produce funny results. File uploads can work differently (case sensitive filenames - foo.jpg and foo.JPG can coexist in Linux, but not in Windows).
On the other hand, there are things like the new MSSQL PDO driver that only exist in the Windows world.
---
[1] Windows 2003 Server was running our app, which invoked Imagick similar to `convert $input.jpg $output.jpg`.
Worked just great for half a year.
Deployed to a second machine, Windows 2008 Server.
Command execution fails silently.
Change %PATH% to be identical to the old server's one.
Restart.
Still fails.
Compare phpinfo().
$_ENV['PATH'] in new server doesn't match %PATH% (it appears to be re-sorted with windows folders first), $_ENV['PATH'] in old server matches %PATH%.
Messing around with new %PATH% changes nothing, new server keeps giving PHP the silently-reordered %PATH%.
Nothing helps, short of specifying full path to `convert`.
A very fun thing to debug.
I've been using Azure for a year and a half. I feel like I know it pretty well. Yes, this was a problem originally but has been solved with the Web Accelerator. You can now deploy your web projects instantly across all nodes.
I can only laugh when I see 'Azure done right'. Isn't that http://AppHarbor.com tagline too? Sorry, but you don't buy Azure for a single web box for your toy project. You buy it for the suite of other features that are all available in the same datacenter. Message Queues, NoSql (Table Storage), SQL Azure and many other enterprise level feature.
If you're offering a PHP PaaS, shouldn't you plan support for the de facto standard PHP RDBMS out of the gate?
> Currently a group of 15 or so people is actively testing this and is sending us valuable feedback. Nevertheless it’s quite close to production-quality service and you’ll hear more about it very soon.
Be careful there. 15 people is not a large enough sample size to claim that your distributed system is "close to production-quality". There are plenty of assumptions that work for 15 people that could completely fall over at scale.