Zend Server

I’ve always been a data fan so it’s not surprising that the field of application monitoring (APM) is something that interests me a lot and has also become a top priority for our application development. But honestly it’s not been an easy ride. Despite the fact that there are more monitoring tools than I can count, finding the right one for not only our application, but our entire development stack as a whole, has been difficult to say the least. And we think that Zend is going to answer the call, and then some. This post is on how we got to that conclusion.

First, let me outline our challenges, or in other words - the reason that monitoring our application has been a tricky business:

1. We are using Azure which is not widely supported by Cloud monitoring tools, especially for PHP.
2. PHP the language - Need I say more. I am happy with our language selection, but it does not give much in the way of good debugging, and production visibility.
3. We do not have a QA team, yet. Although we know how we want to test our application, we are very limited with resources. It’s important for us to get set up correctly to support continuous deployment and other initiatives. So we need something that can allows us to focus our attention on critical issues that come up without worrying about the time spent on code-based integrations.

Our application dev team is small. My role is mostly as an architect and we have two full-time developers and a product manager. While we want to have a full-time QA person that would give us greater coverage in testing and help squash the bugs faster, it is not something we can take on until after MVP (minimal viable product) launch.

Our stack is pretty straightforward. We are running our entire application on Azure. Our frontend is based on Azure websites, a PaaS with a slot for production, staging, and dev. Our backend resides on two small VM clusters, one for development, and one for staging and production. Currently, our backend lifecycle is not ideal and very manual. Deployments require a lot of effort and take about three hours.

Our backend services are critical to our application. They manage critical elements to the application such as our invoicing interface, our analytics aggregation, content analysis, etc. and an admin interface to manage them all.

Where Zend Server comes in is helping us support the backend applications. Zend Server allows us to keep all our resources in our Azure bucket of goodies and also gives us comprehensive monitoring for our backend service applications. To top it all, the setup was simple.

Setup

Because it was the fastest way to get started, we grabbed the Zend Server from the Azure marketplace. There are several versions of Zend Server available in the marketplace, and you can select between the Zend Server PHP 5.6 Developer, Professional, and Enterprise editions. For now we are working with the Developer edition.

This setup installs a Linux box with Ubuntu, and Apache. Once it was provisioned, all we had to do was locate the server IP and go to the following address: http://[serverip]:10081/ZendServer to launch the Zend Server user interface. You are then presented with a nice launching wizard. Click, click, click and the total setup time was about 5 mins.

Once Zend Server was launched, we had to start collecting data. The easiest way would be to have Zend deploy our application to what we are now calling our integration environment for us, instead of what we were doing manually.

Things did get a bit tricky at this point. Even though the actual deployment wizard is easy to use, you need to package your application as a .zpk file, using one of the techniques available. We found that the easiest way to do this was to open our application in Zend Studio, Zend’s IDE, and package it there directly. We are not using a lot of libraries at this point, so this was not too big of an issue. But I could see where it might be more of an issue in more complex applications .

Now we are off to the races. Because this was a fresh instance it took a while to get useful data, but right away we began seeing red-light issues that we could not address previously. Previously, we simply got white pages in our admin application when we tried to manually execute one of our services.

Below is a screenshot of what these types of errors look like (called Events in Zend Server). Because our application is in stealth mode, I’m unable to share ours.

The other extremely valuable feature we used right away was the extensions manager. We were going to setup a separate repository manager, but there’s no need for that anymore since Zend Server provides enough information for us to manage our artifacts, libraries and tools. It will also help us keep them current. For example, we can make sure OpenSSL is the sans-Heartbleed version.

Because our main drive for trying Zend Server was application performance monitoring and debugging, we won’t be leveraging the full functionality available in the product until we leverage the entire Zend stack. And that is the next step for us, at least for our backend applications. Because these applications are already running on IaaS infrastructure we are able to quickly get the development team on board to start deploying the applications via Zend Server versus what we are now manually doing through GitHub.

The UI for our backend applications is limited, so we do not get to leverage Z-Ray as much, but this is a great Zend Server feature. Z-Ray is a toolbar that shows up on every application page, in your browser, for seeing what’s going on under the hood and in real time. Z-Ray displays much more information than Firebug or equivalent and is way more intuitive. It helps with live variable information and also displays notifications for updates if we do not happen to be logged into Zend Server.

The product also gets some bonus points in my book because of Zend’s history. Zend was actually created by some of the top contributors to the PHP project and it has dramatically impacted PHP’s evolution, including the latest version - PHP 7 - which I hear is awesome.

The only major downside I see using Zend server for us is the fact that you ideally want to have your application in the entire Zend ecosystem, for example, leveraging their IDE called Zend Studio, and the Zend Framework. If you are committed to doing so then everything is easier and the data you can collect is even more comprehensive.

With a small development team we are limited in what we can do to ensure we implement practices and quality tools. We needed to do the most with the least amount of effort so that when we do launch there are no big surprises, and we are setup to grow. I’ve seen this kill a lot of very early startups. Zend Server is going to give us the opportunity to leverage better package administration, application performance monitoring, and debugging tools to keep us going on an effective path. And when we set up continuous delivery and deployment directly within Zend Server, we will have the ability to have a unified release automation process.

So far, Zend Server is the most comprehensive release automation, APM, and extension management tool I’ve found that supports PHP applications.