Re: taking deployment/operations considerations into account

Al,

I share your frustration.

I can speak as a developer who has moved into the realm of  
operations---mainly related to web sites and ecommerce.  After that  
move, I became immensely dissatisfied with how poorly most software  
makes the transition to operations.

Take configuration files, for example.

Some amount of configuration must be under administrator control:  
hostnames, port numbers, and passwords at a minimum.  Usually also  
tuning parameters such as database connection pool sizes.  All these  
parameters must vary from one environment to the next.

Yet, these properties are always mingled together with essential  
plumbing of the application.  I use this example from Spring  
configurations in some of my talks:

<bean id="DataSource" class="org.apache.commons.dbcp.BasicDataSource">
	<property name="driverClassName"><value>com.mysql.jdbc.Driver</ 
value></property>
	<property name="url"><value>jdbc:mysql://localhost:3306/exp2</value></ 
property>
	<property name="username"><value>expdev</value></property>
	<property name="password"><value>expdev</value></property>
	<property name="initialSize"><value>10</value></property>
	<property name="maxActive"><value>40</value></property>
</bean>

This one bit of XML mixes together plumbing (change the  
driverClassName and it breaks completely), environment parameters and  
tuning parameters.

Developers should not require administrators to edit XML files by hand  
during deployment.  Worse yet, this file lives inside the codebase, so  
any production properties will have to be replaced by hand after every  
deployment!  That's just begging for errors.

These issues, and many others, motivated me to write "Release It!  
Design and Deploy Production-Ready Software".  In it, I talk about  
designing for successful deployments and good operations. I also  
discuss design patterns and antipatterns that can dramatically affect  
how applications survive contact with the real world.

(BTW, Spring does provide a handy class called  
org.springframework.beans.factory.config.PropertyOverrideConfigurer  
that can help with the configuration problem above.  Developers have  
to build it into their beans.xml files, but it lets you externalize  
overrides into a simple name=value file that lives under /etc or some  
other place outside the codebase.)

Cheers,
-Michael Nygard


On Apr 28, 2008, at 8:31 AM, Al Chou wrote:

> I realize that one's actions/decisions are colored by one's  
> experience, and that not many developers have ever worked in IT  
> deployment/operations, but I'm increasingly frustrated by the fact  
> that our developers do not take ease/consistency of configuration  
> into account when developing our product.  Like Windows (up until  
> Vista), they assume that the administrator of our product owns the  
> machine outright, as well as dependencies such as a SQL Server  
> database that may or may not be installed locally on the machine our  
> software runs on.  These assumptions don't hold up in, for instance,  
> third-party hosting environments (where you can't necessarily log on  
> to the machine via Remote Desktop) or organizations where the  
> separation of responsibilities precludes owning the whole machine  
> (there are plenty of organizations among our customers where the  
> machine/OS-level administrator is not allowed to see the application  
> data, and the application administrator is not
> allowed administrative access to the OS).
>
> I'm wondering how much such issues are taken into account by the  
> individuals on this mailing list?
>
>
> Al
>

Michael T. Nygard
[email protected]
http://www.michaelnygard.com/

Author of "Release It!"
http://pragmaticprogrammer.com/titles/mnee/index.html