Release It! - 15 Design Summary

This chapter recaps the information that has been presented thus far:

"It can be hard to draw attention to these topics during the hustle and
rush of a development project, especially once crunch mode begins.
There’s good and bad news here; you can choose not to deal with these
issues during development. If so, you will deal with them in produc-
tion...time and time again. Dealing with these issues in development
does not necessarily cost much, in time or effort, and what it does cost
is far outweighed by the long-term cost of ignoring them.

Remember that your application will run on a server with multiple net-
work interfaces. Be sure it binds to the correct address for any sockets
it listens to, and be sure that any special routing requirements are set
up and documented. Administrative functions should be exposed on
the administration and monitoring network, not the production net-
work.

Be sure to use virtual IP addresses to access clustered services, such
as database servers or web services provided by other systems. Using
the VIP allows the service provider to fail over—whether planned or
unplanned—without necessitating the reconfiguration of your system.
Applications should be able to run as application users; they should
not require root or Administrator permissions. Sensitive configuration
parameters, such as database passwords or encryption keys, should be
kept in their own configuration files.

Not every system requires five nines of availability. The cost of greater
availability increases radically at each level. Considering the availabil-
ity requirements as a cost/benefit trade-off (well, a cost/cost trade-off,
really) with the sponsors helps move the discussion forward.
Rather than defining the availability of the entire system as a whole,
I prefer to define the availability of specific features or functions per-
formed by the system. Be sure to write exclusions for loss of availability
caused by external systems.

Load balancing and clustering are two prerequisites for high availabil-
ity. You can employ a variety of techniques, with a wide range of costs.
Armed with your availability requirements, you can apply various load-
balancing and clustering solutions as needed to meet the requirements
at efficient cost. Each of these solutions has its own unique set of con-
siderations, so defining the high-availability architecture early makes
development and deployment much easier.

Your application’s administrators will never know as much about its
internals as you will. You can help reduce the likelihood of operator
error by making your application obvious to configure. This means
separating essential plumbing, such as Spring’s beans.xml files, from
environment-specific configuration. Mixing them is the equivalent of
putting the ejection seat button next to the radio tuner. Sooner or later,
something bad will happen.

Spend some time making your application simple to operate. Start-
up and shutdown should be nondisruptive to users, and any admin-
istration duty must be scriptable. Pretty Java desktop administration
GUIs help the novice learn his way around, but nobody wants to click
through the pretty GUI for the thousandth time."