Re: taking deployment/operations considerations into account

Hear, Hear!

It would do many a development organisation a world of good to ensure 
that developers get a six month stint in support or operations on a 
semi-regular basis ... every five years. Just to remind them how hard it 
can be to use the intellectual output of others.

Modern configuration files (usually based on XML) are a nightmare to 
edit successfully and rarely have decent commentary in them to assist in 
  understanding the range of permissible values/enumerations.  All too 
often an implict familiarity with the relevant class hierarchy is 
assumed. This leads to a lot of head scratching by a sysadmin.

I still have problems with log4j, even after 4 years of using it. It 
should NOT be this hard.

Regards,

Gordon

Michael T. Nygard wrote:
> 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