Today's Top SOA Links
Web 2.0 News Desk
Web Application Lifecycle Maintenance
A ten-point tune-up check list
By: Dave Jilk
Dec. 28, 2012 03:15 PM
Like an automobile, a web application needs occasional maintenance and management over its life cycle. Although it doesn't need oil changes, it will probably need version upgrades. There may not be manufacturer recalls, but sometimes servers fail or hang. An application doesn't need to be washed and detailed, but it does need to be backed up. And both cars and applications need occasional performance tuning.
This article provides a complete list of the system management functions that need to be performed on a standard architecture web application, with a particular emphasis on doing so in an Infrastructure-as-a-Service environment.
Evaluation is facilitated with two primary components: information about the application and a try-before-you-buy capability. Many questions about an application can be answered efficiently with basic feature and function information, and ideally a competitive comparison from several similar applications will give visibility to their strengths and weaknesses. But these are prerequisites rather than substitutes for actually trying and using the product. Ideally, a "test drive" will not require any setup or configuration, since the goal is only to determine whether it meets your needs. You want to spend your evaluation time using the software, not learning how to deploy and configure it.
Automating a deployment has many benefits, even if it is superficially a one-time deployment, because the automation script provides documentation and a kind of checklist to ensure that configuration details are handled properly the next time. If the upgrade is performed by re-deploying to a new server entirely, (this is much easier with virtual machines and cloud servers), then the upgrade process is just a matter of re-running the automation.
Another benefit of automating deployments is that best practices are made repeatable and documented, thereby reducing the chance of human error.
Ideally, a backup contains the minimum unique data necessary to reproduce the state of the system. This keeps the cost of transporting and storing the backups low, which in turn encourages a higher backup frequency. However, sometimes this minimization should be traded off against the amount of time required to restore the system to working order.
Importantly, applications must be monitored at the application level - by robotic access through the application itself. It is common for servers and virtual machines to seem perfectly fine while the application is unresponsive. Remember that users and customers do not care about "server uptime" - they just want to use the application or site.
Deeper monitoring can signal trends that suggest that an imminent failure before it happens. For example, by tracking memory utilization and number of web server processes, a monitoring system may be able to predict that a server is about to overload. This type of deeper monitoring can also be useful for automated scaling procedures.
5. Job Scheduling
If the application has this requirement, there must be an easy, flexible, and reliable method of scheduling and automatically performing these jobs. It is common to use cron or Windows Task Scheduler for these procedures, and as long as these tools are accessible this is a workable solution. Even better is an off-server job scheduling mechanism, so that the status of the server and application does not affect whether the job runs and whether failure notifications can be delivered.
It is extremely convenient to be able to easily duplicate the entire application environment and perform the upgrade first on a copy. Running manual or automated tests to confirm that the upgrade worked can improve reliability. If the upgrade failed, because (for example) a step was left out or a configuration change conflicts with the new version, the duplicate environment can be used to check and repair these issues and the upgrade process repeated until it works properly. This best practice minimizes the downtime associated with the upgrade.
Obviously, when a server or application does fail, the first thing to try is to restore the operation of the application in place. The next thing to try is deploying a new application environment, then restoring a backup or turning a replication slave into the master. The former will result in a loss of data based on how long ago the backup was performed. The latter will typically result in only the very last transaction being lost. DNS entries must be updated.
Sometimes, a server failure is actually a consequence of an entire data center experiencing downtime. In this case, it becomes clear why the backups must be kept offsite. The attempt to deploy a new application will fail in the original data center, so it must be performed elsewhere.
Ideally, a management system will provide the optional ability to sequence and automate all these procedures in connection with the monitoring. This can minimize downtime and avoid the need to have staff on call 24x7.
In single server application deployments, scaling consists of redeploying the application on a server with more memory and/or compute resources. Multi-server deployments are scaled by adding or removing servers from a homogeneous horizontally scalable tier, usually a web tier and possibly a separate application server tier.
In addition to deploying fully configured web or application servers, they must be properly added to (or removed from) a load balancer queue, and this must be done in a way that does not affect active connections. Thus, whether these scale changes are initiated manually or dynamically in response to monitoring output, it is crucial that the deployment (or un-deployment) of resources be automated to avoid configuration errors and to ensure a transparent user experience on the production environment.
If system management for the application is largely automated, any manual changes need to be reflected in the automated deployment procedures to ensure that they are reflected in later re-deployments (including restoring backups, deploy from scratch upgrades, and the like). A very sophisticated management system might actually perform tuning automatically based on load and performance characteristics of the application. However, this is unusual because it is typically very application-specific.
10. Utility Management
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week