Justin,
I can't agree with your point of slower package build times. The thing
is, when a package is built on the deployment server, the data is
retrived from Central Objects. If database is on the same machine where
build takes place, it eliminates network use. If you have a double
processor machine with separate disks for packages and database, there
should not be a penalty in terms of CPU use or disk. Also, from my
experience with B7332, a full client/server package without recompile
runs in under 2 hours on a lowly Intel SQL (PIII-500, , single IDE disk)
which runs both as deployment and enterprise server (one of our
sandboxes). A full client-only package is taking about 4 hours, when it
is built on the following config: Enterprise (HPUX, Oracle, 3-way, 3Gb
RAM, RAID), Deployment (Intel, 2-way, 512(?)RAM, RAID) over 100Mbit
connection (they are on the same switch). I would imagine a modern
AS/400 (iSeries) in a similar config would be anyhting from 6 to 12
hours (this, if everything is properly tuned up, it would be 6, but
longer is much more probable)
On the other hand, I do not think that faster package build times
justify additional costs, mostly in terms of maintenance.
My set of pro's and con's:
Pro:
Cheaper platform (Intel), which, for 1W provides more "bang per buck"
Faster package build times
Separate maintenance of data and programs (Central Objects are on the
same server as pathcode, which you have to back up anyway).
Backups can be scheduled separately, less often then production data
You save precious disk space on production machine
Con:
You need a more powerful deployment server
You have to buy SQL server, which IS a different RDBMS from Oracle or
DB/2
You have to maintain, tune and secure this new RDBMS
If your deployment server fails, only clients with full packages can
continue to work without interruption (partial will only be able to use
functionality, which already has been installed)
Backups of deployment server are more important then in the case of only
pathcode backups (C functions tend to change less frequently then the
specifications, which change every time you create version or change
Data Selections)
Sum:
If your enterprise server is Intel (especially SQL) and network is good,
it does not make sense to move CO to deployment. If network is not good
- improve it.
If your enterprise is Unix or AS/400, then depending on lack of HD space
on it, power of your deployment server, availability of SQL Server
licenses and IT staff to maintain it, you may consider moving CO to
deployment server.
Regards,
Vladimir Ponomarev
B7332, XE (mostly XE at the moment); SQL 7.0, Oracle 8.1.5 (mostly SQL);
Wintel, HP (mostly Wintel)