… or how the operations folks can stop servicing configuration tickets and do something more valuable with their time!
At the InterConnect conference this year, it struck me how one particular aspect of Liberty kept coming up in conversations involving WebSphere admins: how the flexible configuration structure makes it easy for them to ‘get out of the way’ of application updates and do something more useful with their time. Traditional application deliveries often require the operations team to set application-specific configuration requested by the app developer. This request may be as formal as a ticket system or as informal as a conversation in the corridor, but however it is managed it has two undesirable effects:
- Application deliveries have to wait for completion of the configuration request by the ops team.
- The ops team spends a lot of time servicing requests which don’t make the best use of their skills.
Several Liberty adopters presented at the conference this year and described how they customize their Liberty configuration, using both the
include syntax and the
configDropins locations, to allow different groups to contribute their own pieces of the configuration. The ops team retain overall control, setting the infrastructure and security properties in files that are common to all deployments, but all the application-specific configuration is delivered by the developers along with the application source, through the (automated) build systems. Use of config variables makes each file highly portable through the development–test–production flow. File system permissions are used to secure the files containing sensitive data like passwords.
In one session, the presenter was asked whether the admins in his organisation were now fearing for their jobs, since the queue of config tickets had dried up (as the application updates were pushed straight through by the app developers). On the contrary, was the response, they were now doing higher-value work, acting as consultants to development for production configuration and finally getting time to make key improvements to the infrastructure. The developers, of course, were equally happy because they can deliver their changes as soon as they are ready, and not sit on a queue until another team can get to them.
This white paper (PDF) describes the differences between traditional WebSphere and Liberty, why not take a look and see if the benefits of using Liberty for deployment can help you with some of your challenges.