May 21st, 2008Pondering large scale application consolidation
Historically many bespoke application are developed on the same servers the prodcution application runs on. Often this server was built by the developers with little regards for consistancy. After all developers develop applications for a living, not build server infrastructure.
Developing an application on the production server can lead to many problems, particularly if that server build is not quite right or the developer is a little wet behind the ears and does not considure scaling issues and hard coded resource refernces. Then of course it is always possible to cripple the production server by testing rogue application code at the whim a developer. I could witter on for ages about this, bit i want to get on towards what needs to be done to consolidate these applications to central managed infrastructure. Putting to one side the issues of supporting the, often extremely large, consolidation platform, many problems need to be over come to ensure the successful migration / consolidation of bespoke applications in the enterprise.
<UPDATE>
It is worth pointing out that these applications should be consolidated to a well defined, well managed platform, where each appliaction exists in a logical container where ALL interfaces and features are defined and controlled by the infrastructure. Hopeful reducing or even eliminating many of the future gotchas
It should also be noted the technology is only a small part of the battle. Accurate recording of succesfull migration, ownership, and reporting of KPIs also need to be considered. i am not talking a few spreadsheets, it needs to be a fully operation CMDB. spreadsheets are not searchable on MASS, so without a proper CMDB you still only have a huge quantity of unstructure data which is be out of data before you can use it
</UPDATE>
So this is my list of check points and Gotchas
Information Required
- Who owns the application (business owner, not a Project manager) ?
- Do they have resource to manage coding changes that may be required ?
- Who Need access to develop the application ?
- Who supports the APP ?
- Does the app have a offical supoprt team ?
- Does the app have approval from the corporate security guys?
- How many users ?
- Does it need access to employ data / GAL ?
- .net version requirements
- Database Requirements (oracle and SQL), linked Servers
- Database requirements (un supported and will need to migrate)
- Downstream dependencies
- Upstream dependencies
- LOB implications (many corporates have to segragate their LOBs BT Openreach for example)
- Any 3rd party access customers (via portals)
- Any 3rd party access offshore users
- Any 3rd party access offshore support
- Any 3rd party access vendors COTS software
- Quantity of SMTP traffic generated
- Database growth expectations
- File Space growth expectations
- Any confidential data requirements
- Any encryption Key management requirements
Things that may need to change
- Db connect strings
- Tnsnames migration to non tns connection strings
- SMTP parameters
- Cold fusion with ldap queries
- Hard coded File paths
- Hard coded Server names
- Hard coded data (other)
Gothchas
- Oracle client compatibility
- File system access by application
- 3rd party components
- Has it been used to running with elevated privileges
- Do any DTS/SSIS need access to file systems
- Does SQL run as a service account, What perms does this have
- Self referencing http calls such as web services (can break on hardware load balanced farms)
- SMTP components
- Non web based components, windows exe, scripts or services
- Use of MS Office components
- Use of MSACCESS
- Sql optimisation (query and indexes)
- Cold fusion version (4.x , 5 code not 100% compatible with MX series)
- Cold fusion with AD authentication (will need code change if using bluedragon CFML engine)
- Asp/asp.net auth against local accounts
- .net data components and memory usage
- SSL
- Session management
- Web gardens
- .net assemblies in bin folder
- .net assemblies in GAC
- .net trust requirements
- Frontpage (Yuck)
- WebDAV (Security implications)
- Application session variables cannot be seen by other servers in the farm
- Do the support guys have SA access to the current SQL server
- Do the Support guys have console access to the current SQL server
- Do the support guys have console access to the web current server
- Date time issues on code developed on servers with wrong regional configuration