Subsequent Info/Thoughts from Brian
Tom Tsai (cc'd) probably needs to be involved in the actual pricing of the service. I've just posted an estimate which should allow Tom to get started on some preliminary pricing: https://wikihub.berkeley.edu/display/istas/Service+Costs+Estimates
Here it is: https://wikihub.berkeley.edu/display/istas/IST+Drupal+Services+Project#ISTDrupalServicesProject-ProjectRoadMap
A "middleware" group should be created.
The current segregation of system administration tasks-specifically, OS package installation and server tuning-from application development is hurting our ability to rapidly deploy high quality solutions. IST should create a middleware team whose members are skilled system administrators with full root privileges AND experts in their technology areas. (Examples of "technology areas" might be: LAMP, Java/Tomcat…) The middleware team would be responsible for creating centrally managed server configurations yielding servers optimized for the technologies that they host.
Responsibilities of the middleware team would include:
- Best practices configuration and tuning of servers hosting specific sets of technologies. This may include implementation of memory and byte-code caching for performance optimization.
Support services for developers in Application Services.
Some amount of application implementation and testing, i.e. eating their own dog food.
Performance benchmarking of servers.
Speed to market of essential campus services must be improved.
- We have the ability to configure servers and deploy applications on then in less than 1 hour. We now need the ability to provision virtual machines just as quickly. In the outside market a VM a high performance VM can be requested and provisioned in 15 minutes. IST needs to improve billing workflow and technical procedure related to VM provisioning to approach this level of efficiency.
Campus standards solutions should be reviewed.
- Shortcomings should be addressed.
Red Hat Enterprise Linux (RHEL):
- Out of date software packages in the official repositories: RHEL provides only an outdated versions of popular software packages, such as subversion, PHP (version 5.1.6), and Ruby in the official rpm repositories. IST should maintain its own rpms of important packages in a local repository like http://searingblade.ist.berkeley.edu/repo/epel/5/x86_64/. Failure to provide up to date versions of important software will drive developers to unofficial 3rd party repositories for solutions. Creation and maintenance of RPMs could be a responsibility of the aforementioned middleware group. Note: Debian and Ubuntu maintain current PHP packages(version 5.2.4) in their repositories.
- To what extent is IST's support contract with RHEL being utilized? How does the service and cost of support compare to other options, for example Canonical's support of Ubuntu?
- How does RHEL's up2date solution for software updates compare to other options, for example Canonical's Landscape. Features: how easy is it for administrators to hold back a potentially sensitive upgrade to a production system? Price: is our selected standard still the best deal on the market?
- To what extent is IST benefiting from RHEL-specific features like selinux? Is selinux required to be enabled in non-permissive mode on production systems? If not, how often is it disabled as a result of problems it can cause with applications.
- File system backups of server are crucial to any system. The current turnaround for a UC Backup order is one week. IST needs to reduce this turnaround to a matter of hours.
- Pricing of this service needs clarification. Presently a price of $0.25/GB is advertised. Depending on one's configuration the cost can actually be 10 times that much.
- The installation procedure for the TSM client on RHEL should be improved. This standard solution should be installable as an rpm. Rpm installation is the best practice for use with centralized configuration management solutions. If no official RPM exists, IST should create and maintain one (as mentioned above).