When you are building enterprise-class, mission-critical applications – “hope is not a strategy” according to Rogue Wave CTO, Rod Cope. During the Keeping up with PHP webinar yesterday, we learned that you need to ensure your organization has a strategy for:
- Maintenance – How to maintain your PHP stack
- Security – How to ensure code security
- Production support – What to do when your system goes down, affecting users
The first webinar in our four-part series, Building the perfect PHP app for the enterprise, Rod walked through each of these areas identifying the challenges, best practices, and recommendations for successful enterprise applications.
The webinar is now available on-demand. Watch, re-watch, or share it with a friend. We’ve recapped some interesting facts below, as well as answered audience questions. Be sure to attend our next webinar, on September 14, when we cover Developing apps faster, and fill out this DevOps maturity assessment, which we’ll discuss then.
During the webinar, we polled the audience to see how many consider their application to be enterprise PHP. By definition an enterprise PHP application is one that is built securely, delivers optimal performance and scale, is always on, and has a clear support path (production and LTS). It was not surprising that over half the audience said yes, given that PHP is the most popular programming language for websites, used by many large organizations, and not just for blogs and small websites anymore.
As one of the key building blocks, maintenance of your PHP stack is critical to achieving security, performance, and high-availability. However, there are costs involved in maintenance and it’s not always seen as the highest priority. We saw this reflected in the results of our second poll which showed only 15 percent of participants said confidently that they are “up to date”. Consider the costs to your organization of performing maintenance vs. being effected by the next Heartbleed.
Answering your questions
The session was very interactive and we received some great questions which we promised to recap. If you have more questions please leave us a comment below.
[Daniel L.] Are IBM i customers going to get PHP 7 before ZendCon? There have been numerous vulnerabilities made public for PHP 5.6.23 and lower and our hands are tied at the moment regarding patches.
[Rod Cope] We’re targeting PHP 7 support for IBM i towards the end of Q3/beginning of Q4. This ties in with ZendCon 2016, where we’ll have dedicated IBM i sessions on PHP and modernization best practices plus an IBM i pavilion where you can meet other fans of i.
[Mark M.] Can you list enterprise grade CMS-es? Thanks!
[Rod Cope] A quick Google search provides dozens of options, each with its own strengths and weaknesses. Among many others, options include Alfresco, Drupal, and TYPO3.
[Jocelyn K.] How do you define middleware?
[Rod Cope] It’s a highly overloaded term, but I use two definitions: one for system architecture and one for software architecture. When talking about system architecture, middleware is anything that sits between your application and the operating system, such as an ORM layer, message queues, job queues, and other facilities. However, it generally does not include data stores. In the context of software architecture, middleware is usually a kind of plug-in that adds value to a request or transaction. For example, in a web application, you might have a chain of middleware that decrypts, decompresses, and decodes a request; parses headers; validates and scrubs user input; routes a request; handles the request by calling application-specific code; encodes, compresses, and encrypts the result; and sends the final data stream back to the client.
[Juan L.] How do you handle emails about application failures? Send one email per FATAL error found or group them?
[Rod Cope] Either option is possible, depending on your application. In most enterprise cases, however, I would prefer to group them. To save time and complexity, consider using a service such as Pager Duty to aggregate errors and minimize notifications.
[Nicolae C.] Is it worth writing your own CMS with best-practices and open source components/frameworks and stacks?
[Rod Cope] In brief, no. Plenty of good CMS options are ready to use. Unless you have a highly specialized use case that is not well served by one of the many alternatives, don’t even consider rolling your own. It will take too long, be difficult and expensive to maintain, and require far more security vigilance than using something off the shelf.
[Annabel T.] Previously you mentioned examples of framework like Zend, Dupal, Cake etc. that are used for enterprise projects. And stack examples are LAMP, XAMPP. What is the difference between stack and framework? Is it essential to have both stacks and frameworks to become an ideal enterprise app?
[Rod Cope] Web application frameworks and standard stacks are both optional, but will almost certainly save a significant amount of time and effort. A web application “stack” typically includes an operating system, a data store, a web server, and an application server or other runtime deployment environment. A web application “framework” is usually an opinionated integration of hand-selected components that provide the facilities needed to create a highly functional web app. If you agree with the framework creator’s opinions, you’ll save yourself a lot of headaches. If you disagree, it’s better to choose another framework. A good framework provides structure that your code plugs into so you don’t have to deal with low level details such as request parsing, document encoding, encryption, and the like. Higher level frameworks can also help structure your application code, provide UI components, make request routing easier, facilitate data store connection pooling, and much more.
[Mzer T.] What is the difference between Cron and job queues and which is better to use?
[Rod Cope] Linux (and other flavors of Unix) use Cron to run tasks periodically. Although you can build job queueing functionality based on Cron, most modern web applications prefer to use a purpose-built job queueing system for several reasons. First, you’re not constrained to Unix-like operating systems – most job queueing systems can also work on Windows. Second, job queueing facilities usually store their jobs in a data store, which can be one you already use in your web application. This helps minimize system administration work such as backing up data, disaster recovery, and monitoring. Third, because they already use an enterprise grade data store for their job data, most job queueing systems allow you to store complex job parameters, job status, retry information, error details, and other extremely useful information that comes in handy when things go wrong. Finally, a good job queueing system lets you create multiple kinds of jobs easily. For example, you might be able to write your job in PHP or as a REST API built in any language. Cron-based systems tend to be less flexible.
[Dmytro D.] Where can I find best practice code examples of OWASP security implemented in PHP?
[Rod Cope] OWASP itself has a PHP security cheat sheet and a more detailed one that covers general secure coding principles. We also have online security training courses coming up that use examples to cover OWASP and best practices to prevent vulnerabilities.