Orchestra.io - PHP Platform as a service | Hacker News Reader

Orchestra.io - PHP Platform as a service

orchestra.io

61 pointsjoelg8728 comments

At roughly $30/month minimum for the "basic" service (that doesn't auto-scale), plus costs for add-ons, you really have to not know what you're doing when it comes to deployment (or just have money to burn), because PHP/MySQL is just about the easiest thing to deploy in the world.

But having auto-scaling on your app, I could see this being worth the value if you want that kind of stuff to be managed for you.

Agreed, anyone can deploy PHP -- it's not rocket science. Scaling is what Orchestra is all about, but obviously you need to deploy before you can get to that point.

A note on pricing -- we're trying to find the right price point / service level offering, that the market will respond to. We've a "grandfathering" policy in place, which we've detailed at the bottom of our pricing page: https://orchestra.tenderapp.com/kb/about-orchestra/pricing-b...

That's great to hear. I understand that you guys just launched and you're still figuring things out.

I was just trying to understand the initial value proposition for someone like me (who builds and deploys PHP sites for a living), when the initial cost is 3x what I am used to, and there are additional limitations.

I wasn't able to find it, but do you list application resources anywhere? How much memory do the various applications have access to, how much disk space do I get, etc?

At this point I would probably still roll my own cloud server for prototyping and initial deployment, and look into your scaling service if/when the need arises.

While this is very true that there is a steep initial payment curve, many companies can afford to fit this minimal bill considering the cost of running their own dedicated machines. I think it's quite beneficial that there is OOB support for MongoDB, CouchDB, Amazon RDS, ZeroMQ, Gearman, Memcache & Memcached. Assuming some of these queues scale out automatically, there's a huge benefit in reducing the complexity of your application layer if you're trying to do some rapid prototyping for a minimal viable product that still has the balls to scale out if necessary.

Hosting costs are very minimal these days.

I can provision and configure a dedicated Ubuntu machine at Rackspace Cloud with all those services in about an hour (and I am far from being a sysadmin guru, I just follow the wiki instructions and best practices for security/firewall etc), and it costs me $12/month.

This isn't about cost -- it's about scale and trust. When your app gets beyond what one instance will give you, and your customers demand more reliability than Rackspace Cloud is capable of today, you'll want some dudes in your corner who can help you.

Imagine a world where your application has enough traction that you're spending more of your time fixing issues or adding features to please/retain the maximum number of users.

Having been there, when that day comes, you won't be nickel-and-diming. You'll just want some rock-solid guys in your corner who allow you to worry about one less thing.

Yeah I think you missed my point. When starting out, at the point where I am not worried about scale, which means I would be looking at Orchestra's "basic" package (that doesn't scale), I am having a hard time understanding why I should pay 3x more than I would rolling my own server at Rackspace Cloud.

When my app needs to start scaling up a lot (and that's often an "if" not a "when" for a lot of projects), then for sure I agree that a well-managed service backed by talented people is worth every penny.

Having done consulting for the best part of 10 years, we've taken that kind of route many times. It got to be a bit repetitive after a while, tbh.

I think if pushed on it, most developers would prefer to spend their time writing code than setting up and configuring servers. Which is why we created Orchestra.

Each to their own though :)

the cost is about the same as its competitors (phpfog, cloudcontrol). "basic" is for people who've outgrown shared hosting and maybe a small virtual server, not really for someone who has a pet project they need a little space for.

I've got production apps running on the base cloud servers at Rackspace (12$/month) and they run just fine with non-trivial traffic and users. Far from what I would call a pet project.

But to each his own. Again, my whole argument is not about elastic or scaling apps (where I totally get the value), it's about their non-elastic intro package and the value you would get from it (no scaling and limitations on what you can do compared to your own vanilla dedicated box) versus a dedicated cloud server that costs 1/3 of the price.

If they want to bring in customers initially onto their platform (which makes it way easier to upsell to the elastic service when the time comes), they might need to adjust their base pricing a bit to be competitive with similar (non-scaling) offerings.

I say this because unlike other application stacks like Rails, setting up a proper basic hosting stack in PHP is dead simple for a lot of people, so the bar is a lot lower than rolling you own for those other stacks.

true, getting something nontrivial set up isn't tough, and thats why (i think) the pricing isn't as steep as something like engine yard. this isn't meant for the people who're more than willing to do it themselves.

but don't you think that paying the extra $18/mo might be worth paying if it means that your server "just works" and you don't have to deal with it? even a LAMP-ish stack has its headaches during setup and (especially) high growth.

The problem I have with "$18/month more" is that when you are running and hosting 10 or 20 sites (like our company does) that adds up fast and cuts into the margin.

And I don't have ssh access. And I can't install my own extensions. And if I want to run cron jobs, it costs more. And if I want to run MongoDB, it costs more. And if I want to use Memcached, it costs more.

So while I get the convenience, "doing it myself" is super simple for PHP stacks, and the costs of using their basic non-elastic add up fast when you are hosting lots of sites, and it actually gives me less, not more.

When you say it isn't meant for people who want to do it themselves, I would agree on the elastic plans (running an auto-scaling setup correctly is not easy), but their basic plan really doesn't offer anything compelling for what I consider to be a relatively high price.

The whole scaling argument is great and if that's a real concern for your project, then services like Orchestra.io are awesome, but I think a lot of people over-provision and plan for scaling prematurely, and pay the price for it unnecessarily.

My sites don't have millions of users, but some of them have up to 10k registered active users and with some smart caching and setup, run just fine on the aforementioned 12$/month servers.

Anyways, I think I've made my point here. I wish these guys the best and I'm happy to see people offering these kinds of services in the (admittedly un-sexy but still very popular) PHP space, and I will definitely follow their progress on the scaling offerings.

1) not every addon at every place like this immediately costs more.

2) your setup is the more common one, using services like this are less common. i have my own cheap servers that host multiple pages, as well, and i'm not going to switch them over. but i also have some apps that i might, because they're a headache to manage. but i think we agree -- this isn't something you're interested in because its not really for people in your situation.

Why do all these companies think I want to see the charge per hour for hosting? Maybe per hour would be useful for some people in certain situations but at least list the per month charges too.

I would like to see a security page. It is not clear if your app is isolated in its own microinstance or shared in some way that should be specified.

Thanks for the comment. Security important for everyone.

"Free" is multi-tenant. "Basic" and "Elastic" are isolated.

Some of the restrictions we have in place on "Free" are documented here. https://orchestra.tenderapp.com/kb/system-constraints/system...

I agree, a dedicated security page would be helpful, and is something we'll be creating soon.

Thanks again for your feedback!

You guys may want to look at this as well: http://sae.sina.com.cn/

Sina App Engine - sort of like Google App Engine's take as a China clone, but it runs in PHP.

This platform (Orchestra) takes another approach, liking managing the ec2 instances than like the app engines that even the instance thing is transparent from the developers. Guess there can be many debates on whether which ones are better approaches.

Also thing to notices on SAE, for non-Chinese readers, SAE has built-in function constraints. That means it's more like GAE in a way that not all the core functions and libraries are available[1] which is obviously security and performance reasons.

It would be interesting to see if any core functions be limited on orchestra.io as well.

[1]http://sae.sina.com.cn/?m=devcenter&catId=39#anchor_f2de...

Thanks for the tip, we'll check it out :)

You will need to be very good at explaining why you are better than the traditional hosted solutions. For example, for PHP stuff, my provider (OVH) is putting my website one a cluster with 1000 servers with unlimited traffic and an insane number of goodies for 2€ (yes two) per month. I can hook a managed MySQL instance (Solaris Zone) with up to 1GB of RAM for some € per month. So it starts at 2€ and up to 60€ for something which can really handle heavy load.

I would have to do it now. I would look at offering PHP hosting for a limited set of frameworks with a really good integration of the framework within the infrastructure to add really good value to the developers. Let say a fanatical support of ZF with ready to use Solr indexing, memcached etc.

How do you differentiate? What is the real added value against Plesk whatever control panel is used at the moment?

Anyway, good luck and have fun!

great to see an Irish company in here

And Great team! It's still early but my bet is that they're going to crush it...

Seconded, well done lads!

If echolibre happens to be reading this, I'm seeing a stylesheet issue on your activation form where the two input boxes for email address and password are extending beyond the login containment box. Screenshot below.

http://tinypic.com/r/30mwjrl/7

I'm running FF 4.0 on Fedora 13. Hope this helps =)

Thanks for the heads up! We'll get that fixed :)

Its' fixed :)

and on a macbook air with the browser maximized, i can't read the quote and whatever else this cloud is hiding:

http://i.imgur.com/pRWyAl.jpg

Thanks for the heads up :)

Great job, looks great.

Reply on news.ycombinator.com