Jan Burkl, systems engineer and overall PHP wizard walked through what it takes to manage PHP applications. Taking the day-to-day viewpoint, Jan dissected each area into its many parts.
When it comes to security, think big
Big picture that is. Jan advises to think in many directions – not just one specific area. PHP applications are more than just applications, they include the entire stack, from OS to database and servers. So, for security, he says, “Take a broader look at security, it’s not just one thing or another, It’s everything.” Start with the key pillars, application and stack. This encompasses the community, internal and customer-driven security policies, custom code, skillsets, QA tools, and ongoing support.
Train your security muscle: Eight out of the top 10 OWASP vulnerabilities are directly related to development. Is your team savvy on these, and can avoid introducing vulnerabilities into applications? Do you have the skills to prevent these? In an audience poll, 63 percent said they were either very or somewhat confident in their PHP applications’ security.
Not you? In our last poll, more than 50 percent of the participants were using unsupported PHP.
How and when to scale
Two questions to ask when it comes to scaling:
- Is your app scalable?
- When should you scale?
When to scale may be the harder question, as volumes can either dramatically increase without warning, or slowly grow over time until they become unmanageable. Monitoring becomes the key to identifying what’s happening across the infrastructure, the applications, and even offers insight into development practices. With cost as a primary concern with server additions (even in cloud environments), ongoing monitoring allows admins to dynamically scale to meet current needs without incurring static cost.
Jan cautions to be careful of diagrams. With APM data, including the comprehensive charts and diagrams from Zend Server, it might be easy to identify an issue that looks big on a pie chart, but is in fact low value in pursuing. If overall performance is acceptable and within SLAs, time spent chasing an issue might be better spent elsewhere. Focus on the larger picture, versus a large contributor to a small problem.
When and why DIY fails
PHP is inherently built to support DIY, but that doesn’t mean it’s always the right choice. Ask yourself: Do we have the right skills to manage application migrations, framework migrations, testing, tool selection, and OS upgrades. And, have we identified and instilled best practices across teams? The result may be less DIY and more science project that you intend. In developing and running production applications, time to market, risk mitigation and cost controls are paramount. Weigh the cost of hiring to manage the DIY solution, versus purpose-built commercial, supported software.
- Watch Jan’s webinar
- Catch up on the series:
- Register for the October 11 Ask the experts panel webinar