Zend Server is proprietary. NNNOOOOO!!!!

In my Do You Queue article there was a comment posted about open source alternatives to Zend Server's Job Queue.  Being somewhat of an open source afficionado (I can spell that thanks to my love of fine tobacco products) that is a position that I can relate to.  I have heard several times "I like what Zend Server offers but I only want to use open software, or I don't think the features are worth the money."  I understand why.  "Open" is the new black, and has been for a while now.  So let's explore these two issues.  1) Proprietary software, and 2) the price of the software.

There are many places where I have no doubt that "open" is beneficial.  Chief among those is communication.  An open communication protocol can be easily integrated with.  TCP is a good example of this.  Without an open TCP communication protocol it would be difficult to have the Internet.  In fact we couldn't.  Same thing with HTML.  In fact we've seen with HTML the problems that can be associated with taking something that should be open and making it not so open. But as we've moved forward "open" and "standards" are becoming more and more important.

But does that mean that everything needs to be open?  From a purely utilitarian perspective, no.  I'm listening to Creed right now on proprietary speakers on a proprietary computer running a proprietary operating system.  Would I prefer that it was open?  Yeah.  Absolutely I would.  Do I really care?  Well, not really.  Why not?  Because I want to listen to Creed.  I record music using Cakewalk Sonar Producer.  Would I prefer that it was open?  Absolutely I would.  Do I really care?  Well, not really.  Why not?  Because I want to record music.  When I code I use Zend Studio.  Would I prefer that it was open?  Absolutely I would.  Do I really care?  Well, not really.  Why not?  Because I want to write code.  When I deploy my application I deploy using Zend Server.  Would I prefer that it was open?  Absolutely I would.  Do I really care?  Well, not really.  Why not?  Because I want things like monitoring of my PHP application, asynchronous execution, code acceleration and code tracing. 

I don't think that this position is overly controversial.  That is because the purpose of software is to solve a problem or do work.  That's it.  (Ok, software can also be written for fun too.)  But code written to be poetic it is pointless code.  If you are looking for existentialism in an "if" statement you won't find it.  If you are looking for joy in an architecture design you won't find it, unless that architecture solves the problem you are trying to solve.  Otherwise you are going to spend all of that joy trying to justify why you designed your system that way when it breaks or doesn't do the job it was supposed to.

So what if you are writing software for an open source platform (like PHP)?  Should you use proprietary software (like Zend Server)?  That's a question I can't answer.  The reason I can't answer that is because it depends on who your customer is.  Is your application going to deployed to a VHosted LAMP setup that is intended to be as cheap as possible?  Then, no, Zend Server is not a good solution to build for. 

But here's a question.  What if your application is going to be used in an operation where it's important to the bottom line of the customer?  What if your developer time is extremely important, and not cheap?  Going back two paragraphs; what if "open" really isn't truly all that important.  Let me make a strong and, perhaps, controversial statement.  If an application is either important to the bottom line or the developers are not cheap, there is no reason to not use Zend Server.  And in fact, it may be in your best interests.

Now, I know that the open source folks are may start getting hot under the collar at this point.  But let me explain myself first.  I have now used Zend Server since it came out.  That was originally when I was working in Zend's Global Services organization.  Often I would be brought in to do performance audits for people's applications.  People would spend 5 figures to get someone like me onsite and one of the first things I would do is install Zend Server and turn on Monitoring.  Once Zend Server 5 came out the first thing I would do is install Code Tracing.  Within a day I would have a pretty good idea of what was wrong and within 2-3 days I had a solution that I was working on.  Was it because I was hot stuff?  Hell no.  It was because I had the tools to diagnose the issue.

And the funny thing about it was that in many cases had the customer spend a few grand on Zend Server licenses they might not have needed to spend several thousand more on having me come out there.

"But!" I hear you say. "The likes of Yahoo and Facebook don't need Zend Server.  Why should I?".  That's a good, and a very valid, question.  The way I look at it is that there is a relationship between the number of developers and the number of servers you have that help you to determine that.  Do you have a thousand servers?  Zend Server might be too expensive, though I'd be VERY willing to bet that you could get a good deal if you had a thousand servers.  The question isn't whether or not Yahoo or Facebook need Zend Server, the question is whether or not you do.

Let's go back to what I had said about software.  It is there to do a job, or to help you with yours.  You, like me, might prefer that it's open.  But at the same time, if it means that you can go home at a decent hour do you mind that it's proprietary?  Maybe you do.  I dunno.  I like solving problems faster.  I also like having the ability to run things asynchronously out of the box, clustering out of the box and so on.

The way I look at Zend Server is that it is not about cost.  It is about benefit.  Would Zend Server cost you $10,000 a year?  Big deal!!  The real question is does it save you $10,001.  It might not, but when you factor in things like developer costs and such $10k in a developer organization of 3 people only requires a 4% increase in productivity, or less.  So, if you spend 5 hours a week fixing bugs, if you can reduce that by 1.5 hours per person you are already in the black.  Add to that reduced mean time to resolution through the use of Monitoring to notify you of problems that could be causing a material impact to business operations and the benefit starts to increase very quickly.  Even on this site, I know within a few seconds that an issue has occured in the code, which is something that typical monitoring, such as nagios and the like, cannot do.  For a blog like this Zend Server is overkill.  But unless I (personally) were heading up a business that was unprofitable and self-funded (meaning that it would be cash-strapped), Zend Server would be at the core of my operations.  Which brings me to my next point.

There is one thing that developers are not very good at.  In fact they tend to be really bad at it.  That is: operations.  I had a year and a half spat of working in a large operations department and you know what I found out?  Developers know squat about what actually needs to be done to manage their applications.  It's kind of interesting because the people who I hear from who are less convinced about Zend Server are generally developers and not sys admins.  That is partially because I fancy myself more a dev than a sys admin and I tend to run into developers more than sys admins.  But in my experience, system administrators tend to be more pragmatic and developers more poetic.  I think there's a very good reason for this.  It is the sys admins who are paged at 4:00 in the morning when the server goes down.  Being philosophical about software drops rapidly after a week of no sleep because of an unstable application.

So, coming back to my original reason for writing this article.  The question was asked if there was an open source alternative for the Zend Server Job Queue.  My response is that one should not look at the Zend Server Job Queue in isolation from the rest of Zend Server.  Could you write an application that uses Gearman and does asynchronous processing even better than Zend Server?  Maybe.  I haven't used Gearman yet, but I am willing to aknowledge that it might be true.  But that would be missing my point.  My point is that looking only at individual features is not the best way to look at Zend Server.  Can you get debugging, asynchronous execution, cluster-like functionality, caching and code acceleration elsewhere?  Of course you can.  But will it cost more to maintain your application in an environment of multiple disparate services than with Zend Server?  That question is not so easy to answer.

So, here is a summary of my thoughts.

1. Proprietary isn't as evil is it's often made out to be – I am 90% convinced that for 90% of the people out there that proprietary is an easy objection to overcome because most people would simply like to either get more done or spend less time working.  Open is great for interoperability.  While, for developers, it would be nice for everything to be open, in practically, it is probably less important.
2. Price is not the correct terminology to judge software on.  Cost/benefit is.  If the price is above the benefit then don't buy.
3. Don't look only at development features.  Look at operational costs too.  Can you set up something with asynchronous execution in under 5 minutes?  I can.  And I can fully harness it in another 10 minutes. (That's how long it took me to re-implement that code in another application)
4. Don't just look at operational costs.  Look at mean time to resolution.  Replicating and fixing bugs takes time.  Using Code Tracing and Monitoring you can drastically reduce that.  How do I know that?  Because I have only had one situation in what is now approaching 4 years at Zend where those two features did not provide significant benefit when dealing with bugs or production issues.

Given that some people will find this posting contentious, do consider that there are a lot of other considerations that I had made when writing this that I did not include.  Don't misunderstand me.  This article is not meant to be "pro-proprietary".  My purpose in writing this was to show that just because something is proprietary does not mean that it's as big of a problem as you might thing.