Application hosting: How to manage your software the right way

Jan 19, 2000
Tim Landgrave

Many companies are discovering that just because you can add more machines to solve a problem doesn't mean you won't create an even larger problem. You still have to manage the platform you've created with all these boxes, and that's a much more difficult task than it first appears.

Most companies I've dealt with "solve" the problem by getting the PCs off the floor and into racks in their data center. At least then it doesn't LOOK like there are a bunch of PCs lying around the data center. But it doesn't solve the fundamental problem of having tens—or, in some case, hundreds—of PCs running disparate systems that require their own management systems, troubleshooting methods, provisioning software, and so on. Their software management systems consist of "Web monkeys"—the entry level engineers that would otherwise be pulling cable, but now sit in operations and watch monitors and machines for signs of trouble.

In this article, we'll examine the software side of the application hosting issue, focusing on five specific problems with the software scalability model and four tools you'll need to manage your software effectively.

1. Being too spread out. Since applications are composed of many different components (HTML files, ASP files, COM components, PERL scripts, graphics files, and so on.) spread across multiple machines, the applications are very difficult to manage in this environment.
2. Efficient replication. Effective scaling of the application requires that these application components can be replicated intelligently to a group of servers.
3. Multiple location application development. Assuming you can handle the distribution of the application's core components, the application still has to be developed in such a way that it works effectively when running in multiple locations. Most developers still assume that an application is running entirely in one box during their development and testing. This has huge implications when the application gets deployed in a distributed environment for the first time and problems like state maintenance begin to surface.
4. Monitoring limitations. The fourth major issue is the difficulty in monitoring the applications proactively. In order for these applications to be considered robust enough to be mission critical, we have to be able to manage them proactively. This is easier to do in a single machine/single application where you can monitor performance metrics like CPU and memory utilization for that one application. Once you add multiple applications to one machine or spread an application across multiple machines, you need an effective way of predicting the application's ability to execute successfully in the environment.

5. Testing applications designed to scale. Not only do you need to test the application's components and their interactions, but you also need a way to simulate the user's experience. Unless you can tightly define the user platform, you need to be able to test varying client platforms (versions of Windows, Web Browsers, Terminal Server clients) under differing speeds and authentication scenarios (56K modem, DSL or T1 authenticating via a private network or public internet scenario). You may have to test a huge number of permutations in order to verify that your application can work in this distributed environment.

Tim Landgrave is the founder and CEO of eAdvantage. eAdvantage assists small to medium enterprises in the development of their electronic business strategy.