Social Enterprise

How to contain development costs in a multiple-machine environment

Companies running enterprise-wide applications from multiple vendors, including applications developed in-house, face several challenges. This week's Landgrave's View looks at how to contain development costs when operating in a distributed environment.

After discussing the future of development technology in recent articles (MS v. Java and Why .NET will not become Microsoft OS2), I was surprised by the subject of some of the responses. Many TechRepublic members were more concerned over the cost of continuing to develop applications in existing distributed environments, specifically the cost of configuring and maintaining development workstations and testing environments. In this article, we’ll look at the costs involved in developing for a distributed environment and how some organizations are dealing with the increased costs involved.

Maintaining a stable development environment
The first issue that most development managers must address is the stability and reliability of the developer workstation. Most developer workstations need rebuilding on a regular basis because the normal process of developing applications (adding registry entries during application testing and local testing of the applications) requires it. If workstations are not rebuilt, especially when you consider that many developers install numerous tools and add-ons to their machines, then you are writing a recipe for lost time. The real need here is to ensure that developers have the office productivity and communications applications they need to stay in touch with other company employees while also operating in the richest development environment possible.

Lost productivity is the hidden cost
Most developers and development managers don’t realize that their real cost here is lost productivity when development workstations don’t work properly or have to be reconfigured. And where most companies spend hundreds of thousands of dollars working on standard, supportable configurations for their end users, they spend very few dollars thinking through the proper configuration and maintenance of development workstations, testing machines, and certification environments.

Development workstations are only half the battle. When you’re developing applications for deployment in distributed (and in some cases mixed) machine environments, there’s another huge cost associated with the testing environment. You have to consider the initial cost of the machine as well as the cost to configure, maintain, and reset the machines when needed to resume testing.

This is hard enough if you’re dealing in a multimachine environment that’s “pure” (all Microsoft or all Sun), but really difficult in a mixed environment. To do realistic testing, your developers will need access to multiple workstation operating systems (Windows 95/98, Windows NT 4, Windows 2000, Linux) as well as multiple server operating systems and environments (Windows NT4, Sun, Linux, Windows 2000 running a combination of Microsoft SQL Server, Internet Information Server, Exchange Server, BizTalk Server, Apache, MySQL, Oracle, etc.).

How a stable environment helps cut costs
The most common method of dealing with the development resource issue is simply to buy more hardware. It’s not uncommon for developers to have multiple machines in their work areas—one development workstation, a productivity applications PC, a Web server, and either a database or object server. Buying more hardware may exacerbate the problem, since each machine must be configured and maintained by developers with limited systems engineering training or ability.

In some organizations, developers lose as much as a third of their productive development time because they’re futzing with machines that are not properly configured for development and testing. Some companies have minimized the engineering effort by buying common machine configurations and using products like Ghost to make copies of common, tested, and approved configurations. When a developer needs a machine with a specific configuration, he or she can simply boot to DOS and install one of the common Ghosted images for the server.

Many companies deal with the “stable workstation” issue by isolating common productivity applications, such as Microsoft Office and Exchange, on a central server and then allowing developers to access them using Windows Terminal Services or Citrix Application Services. This allows developers to have access to e-mail and Office applications from any machine that has a Web browser or the WTS or Citrix clients loaded. If an application they develop has toasted their machine or if they need to reload the machine from scratch or from a Ghost image, they don’t lose any of the source files, e-mail, or documentation that is maintained on the central applications server.

The converse of isolating the productivity applications is to isolate the development environment instead. This is most easily accomplished by deploying a product called VMWare Workstation or VMWare ESX Server. VMWare’s products allow a Windows or Linux user to host multiple virtual machines running on top of the host operating system.

For example, a developer running Windows NT 4.0 on his or her desktop for productivity applications can install VMWare Workstation and then create a Windows 2000 development virtual machine, a Windows 2000 Server virtual machine running Web services and test COM objects, a Windows 2000 Advanced Server virtual machine running an instance of SQL Server, and a Linux virtual machine running Oracle for Linux. Now the developer can test an application that runs across these virtual machines running on top of the standard Windows NT 4.0 desktop.

VMWare’s new product is called the ESX Server, which takes the virtual machines created with the workstation version and allows the developer to run all of them on a multiprocessor server with lots of memory. In this configuration, development shops can install productivity applications on the developers’ desktops and use a product like the ESX Server to host multiple development and testing configurations. Developers can all have inexpensive desktop machines (or even Windows Terminals) and all the machine images can be developed and deployed on the ESX Server.

Consider the costs of testing and expertise
A combination of these solutions will be necessary, given the widespread use of non-Microsoft technology. Although VMWare will support all flavors of Windows and Linux (useful for Microsoft-centric development shops), you’ll need to use other methods to configure and test in NetWare, HP/UX, Sun, or mainframe environments. Just make sure you consider not only the cost of the testing equipment, but also the cost of the expertise needed to configure it properly.
If you'd like to share your opinion, start a discussion below or send us an e-mail.

Editor's Picks