Lower Total Cost of Ownership for a J2EE Infrastructure

Transcription

1 Lower Total Cost of Ownership for a J2EE Infrastructure by David McNally Senior Product Manager, Management Tools, Borland Contents Introduction 1 Cost of acquisition 2 Cost of implementation and deployment 3 Cost of maintenance and operations 8 Complete vendor product offering 9 Summary 10 Introduction Total Cost of Ownership (TCO) is a type of calculation designed to assess both direct and indirect costs and benefits related to the purchase of any IT component. TCO for a J2EE platform infrastructure is based on the cost of acquisition, the cost of implementation and development, and the cost of maintenance and operations. The cost of acquisition is the easiest of the three to calculate. It is the amount of money paid for the software and hardware that comprise a J2EE infrastructure. The software is composed of middleware technologies such as application servers, database software, and management software. The hardware is composed of physical servers, databases, and the routers and physical networks that connect the various components. While cost of acquisition is an important consideration, it ultimately accounts for the smallest percentage of TCO. The majority of the costs associated with TCO can be attributed to the capabilities of the software. The cost of implementation and development is more difficult to quantify because one must consider how the capabilities of the software purchased might lower TCO over an extended period of time. Adding to the complexity of this calculation is the fact that software features can vary significantly from vendor to vendor. In the case of an application server, the characteristics of performance, scalability, and reliability will most significantly contribute to lowering TCO. Superior scalability and performance of an application server are key factors to reducing TCO because less hardware and fewer

2 application server licenses are required to perform the same number of transactions for an application. The cost of maintenance and operations is based on application availability and the amount of effort needed to ensure functioning applications. The single most important factor in reducing maintenance and operations costs is ensuring that mission-critical applications are fully functional at all times. While the cost of application downtime can vary significantly from enterprise to enterprise, unexpected downtime is generally expensive, and therefore greatly affects TCO. Reducing the cost of maintenance and operations requires robust management software that scales along an existing J2EE infrastructure to help ensure the availability of mission-critical applications. Such software would first attempt to proactively correct a problem with the application, resulting in little or no impact to operations. If the problem cannot be solved by the management software alone, it must immediately be escalated to the relevant IT manager and quickly guide the IT manager to successfully bring the problematic applications back online. The power to automate management of critical applications 24x7 is one key factor in minimizing Total Cost of Ownership across the enterprise. Cost of acquisition Although the actual purchase cost is the first investment in a technology, there are many factors to consider prior to completing a purchase. The enterprise must always consider carefully the capabilities that are being paid for, as well as the impact the technology purchase will have on the organization for years to come. The cost of software can vary greatly even when evaluating the same technology such as an application server. The cost of acquisition for an application server is ultimately tied to factors such as the vendor, overall product quality, technical features of the development and deployment licenses, scalability, and the pricing model. Development license Today, many development licenses are given away for free or offered at a significantly lower rate than deployment licenses. When considering development licenses, it is important to ensure that the licensing agreement allows the development team to do what the license describes to develop. Software vendors may restrict the number of development licenses that can be used together, forcing the enterprise to purchase full deployment licenses to support a team of developers. Vendors do need to impose limitations on development licenses to ensure that an application cannot be deployed and run live using solely that license. But a good licensing scheme should at the very least allow a development team to test the applications over an extended period of time without being cut off due to technical limitations. Deployment license The costs of deployment licenses should be compared to each other only when it has been determined exactly what features are being purchased. If two application servers have identical technical merits, the purchase decision can be based purely on price. But it is challenging to compare feature to feature. Similar to buying a car, one must determine which features come standard and which features will cost extra. The first consideration should be the future reliability of the technology and the vendor. One would not want to buy a technology that will not be supported two years after the purchase. This trap can be avoided by ensuring that the vendor historically has been a leader in defining and accepting the most recent industry standards, such as published J2EE standards. Quite often a sales team will show a wonderful demo of the capabilities of an application server when in reality many of the demonstrated features may cost significantly more. Features such as two-phase commit, transaction service, security, firewall support, CORBA support, management, and clustering do not always come standard with a deployment license and can significantly add to the cost of acquisition. Also, it is important 2

3 to check that licenses for the complimentary technologies such as database tools, Web servers, and CORBA technologies are included in the purchase price. Pricing model Pricing models can also vary significantly from vendor to vendor. Ideally, a vendor will propose a consistent and transparent pricing model. A transparent pricing model is the least confusing model because the cost for an application server license will be based on the number of CPUs for a server alone and will not change depending on the machine class and/or platforms on which it will run. With the appropriate pricing model, application availability can be achieved with tremendous cost savings. To achieve high availability for applications, the infrastructure should be modeled using backup and standby servers. However, it is not easy to justify doubling or tripling the cost of acquisition to buy licenses that ideally never are used because it would mean there was a server failure. Responsible vendors realize this and offer significant discounts for backup and standby server licenses. Vendors that offer this discount do so because they are confident the backups will rarely be used due to the reliability of their technologies a good sign when considering a purchase. Obviously, core functionality is the most important consideration when purchasing an application server. The degree of scalability, performance, and the footprint of the application server can quickly lead to cost savings or to greater expenditures if additional licenses and hardware become necessary. While the core functionalities are important in the initial configuration of an infrastructure, it becomes exponentially more important as an organization grows to require greater scalability and reliability of applications. Cost of implementation and deployment For a number of reasons, implementation and deployment costs for applications are traditionally much greater than the costs encountered during development. Significant changes to an infrastructure during deployment changes to address scalability and reliability issues can have a ripple effect that will be much more costly than if the original infrastructure choice had planned for such growth. As an organization grows, the cost of an infrastructure should increase in a linearly predictable fashion: it should not grow exponentially more expensive. Some may argue that this is not possible, but it is possible if the enterprise begins with the proper technologies and architectures and scales them correctly. A good exercise to undertake when making this decision is to consider capacity planning for hardware as well as software. This will force an organization to have a better idea of what its needs will be in three to five years, and it is critical in determining what the TCO will be during this time. Scalability requirements Scalability has always been an issue with software applications, and we have seen technology movements to combat this problem. The movement from mainframe to client-server to the n-tier technologies of today is one such example. Even within an n-tiered application there are technological decisions that can lead to lower TCO from both a hardware and software perspective. Performance and throughput of an application server are key factors that contribute to infrastructure scalability. Simply put, if more transactions per second can be run through an application running on a particular application server, the result is that fewer application server licenses, CPUs, and physical servers will be needed. Ideally, scalability with regards to performance should be linear to secure the greatest cost savings. This means that if an application server can process 10,000 transactions per second on four CPUs, then the same application server should be able to process 60,000 transactions per second on 24 CPUs. Such statistics are best obtained through independent benchmarking 3

4 tests such as the Sun EJB benchmark, ECperf. In "Borland Posts First J2EE ECperf Result: Still King of the Hill 30 Days Later," John Meyer advises: To make sure users don t get taken for a ride by their application server vendors, Giga asserts that users should demand the following from application server vendors (current and prospects): 1. Provide official ECperf results prior to their signing of a purchase or maintenance renewal. 2. Provide an application server configuration kit for ECperf 1.0 (similar to Borland s kit) for their specific platform, so users can easily perform their own benchmarks in their own environments. 3. Publish an official result on an equivalent hardware and software configuration (Sun Fire V880, Oracle Database 8.1.7) to that of Borland s official results, which should all but guarantee a true apples-to-apples comparison. Vendors of many application servers on the market today have run the ECperf benchmark and, if they are satisfied with their results, they will make a tool kit available for customers to evaluate the performance and scalability of their application server. When reviewing these types of benchmark scalability results, the ideal results for an application server will be as close to the theoretical maximum as possible. If the scalability starts to tail off like the result entitled bad performance, an organization will end up paying more both for physical servers and for software licenses to support the organization s growth, which may be unpredictable. For example: Application server partitioning and memory usage In addition to performance, there are other important factors that contribute to scalability. Application server partitioning effectively enables the user to configure and run multiple virtual instances of the application server in a protected environment while running only one application server. Application server partitioning will reduce the number of deployment licenses that need to be purchased, and it will reduce the amount of memory and physical servers required. The capability to partition an application server is critical to successful scalability because it allows for multiple EJB containers to run on one application server. Through partitioning, multiple instances of applications can run on one application server. There is memory overhead associated with creating a partition, but it is significantly less than running an additional application server. Application server partitioning will apply to the application server tier (or middle tier) of the application, providing additional scalability to the middle tier in a more cost-effective way. Most of the business functionality should be executed on the application server tier because it is the easiest and most costeffective tier to scale. Partitioning the application server makes the application server tier easier and less expensive to scale because it leads to fewer physical servers and fewer licenses for 4

5 application servers. Following is an example of a traditional three-tiered architecture where application servers are clustered to support the load of the application. The first criterion that needs to be considered in our example is the memory footprint of the application server. If an application server can run in 64 MB of memory in lieu of 256 MB of memory, there is an instant cost savings of 4x assuming the same number of applications can run on each application server. If an application server can be partitioned, it is easy to show a huge cost savings in this example. A partition is not free in terms of memory because the overhead could be MB. Within each partition, an EJB container can run with a separate process, providing isolated protection for each of the 10 applications in only 238 MB of memory. This is assuming the application server s memory footprint is 128 MB and each partition uses 20 MB of memory. Without partitioning, the same level of isolation would cost 1280 MB with the same application server, since only one EJB container would be able to run on an instance of the application server. Figure 1: Traditional three-tier architecture To demonstrate the benefits of application server partitioning, we will walk through a conservative example of an organization deploying 10 business-critical applications such as accounts receivable, order management, inventory management, etc. To fortify the availability of the mission-critical business applications, a duplicate instance of each application should be running. The second application should run on a duplicate instance of an application server running on the same machine. That entire configuration should then be replicated on a separate physical server. Figure 2: A conventional application server, where components from numerous applications run together in the same container on an application server This model provides four-way redundancy, which is necessary to ensure high availability. Each application also should run in a separate container to prevent a problem with one application from bringing down a container or application server that is running other critical applications. With such a model in place it is easy to see how costs can grow exponentially as more applications are required within an organization. 5

6 machine (JVM). This eliminates the possibility of having transactions bottlenecked when calls are made outside of the EJB container. It also allows the application to be more easily managed. Figure 3: Example of application server partitioning each application is isolated on a virtual instance of an application server using partitioning, while running on only one application server When this example is expanded to create four-way redundancy to support application availability, the cost savings is dramatic. A partitioned application server would use GB of memory, while the same application server without partitioning would use GB of memory for the same level of reliability. Partitioning the application server results in a saving in memory of nearly 4x. The following graph demonstrates the obvious benefits of partitioning the application server to sustain the growth of the enterprise: In addition to being able to have multiple EJB containers per server, another important feature is for the EJB container itself to have each container use a separate process or Java virtual Most application servers boast of the ability to support server replication and clustering, but not all clustering offers equal benefits. Flexible clustering offers a much greater benefit to increase scalability than non-flexible clustering. It also allows the clustering of two deployments that are not identical (heterogeneous clustering) and enables a server to be shared among clusters. Flexible clustering also provides an easier way to deal with increased loads, since additional servers can be added without affecting the system. Database cost savings When purchasing an infrastructure, cost savings for hardware and software should not be limited to the middle tier. Application servers should help optimize the use of the database as well. The database is a valuable resource in an organization and is shared by many applications. Databases will not scale as easily as application servers do because they cannot be clustered horizontally like an application server. Application Databases can Server scale only vertically, which means that buying a bigger, faster, more expensive machine is the most practical option. Operating Systems Typically, the cost of adding an additional database server is much more expensive than adding a server Hardware on the middle tier, since a robust database (such as Oracle ) requires a high-end physical server to run it efficiently. In order to double the processing power from eight CPUs to 16 CPUs, the application server tier can simply add another 8-CPU machine (or two 4-CPU machines) and cluster them together. In order to gain the same performance advantage by scaling the database vertically, a new 16-CPU machine would have to be purchased. A 16-CPU database server is much more than twice the cost of an 8-CPU server or two 4-CPU servers for the middle application server tier. 6

7 The example provided in Figure 4 shows an application server that pushes the processing to the database level: The example provided in Figure 5 shows the application server tier utilized 100 percent while the database is utilized only 40 percent. This can be accomplished by having the application servers performing the majority of the processing while using the database only sparingly. This model pulls the load off of the database as opposed to pushing it to the database: Figure 4: Example showing the utilization of application servers that push the load to the database level. It is very expensive to scale this type of configuration. The preceding example may perform well in the given configuration, but as soon as another application has to access the database, or if the original application needs to scale, another database server will need to be added. This is not a costeffective, scalable model. Figure 5: Example showing utilization of application servers that pull the load from the database level. Adding additional servers on the application server tier can scale this configuration easily and inexpensively. If the performance in the above example is the same as the previous example, then it is much more cost-effective to maximize use of the application servers rather than the database. Additional application servers can be easily added. Adding application servers is also more economical than adding a database server. The above example also allows for additional applications in an organization to access and utilize the database because it has been used sparingly. The ECperf benchmark tests can also provide statistics relating to database optimization. 7

8 Cost of maintenance and operations Once all of the applications are running on the infrastructure, the goal is to keep them running with as little involvement from IT operations as possible. Choosing an application server with application management functionality that will successfully maintain application availability is critical to reducing the cost of maintenance and operations. The cost of application downtime can vary greatly from organization to organization, but it is always expensive. Depending on the quantity and type of applications that are running on a J2EE infrastructure, downtime can cost an organization tens of thousands of dollars per minute. Application downtime prohibits commerce transactions from taking place and other critical business from processing. It is very difficult to calculate the amount of money lost due to lack of productivity from systems being down and preventing employees from being able to do their jobs. From an operations perspective, getting the applications and infrastructure back online also has a cost associated with it. Diagnosing the problems and rectifying the situation can take valuable time away from IT managers. As applications have become increasingly more complex, the tools that manage today s distributed applications also need to become more sophisticated. Distributed applications no longer run on a specific machine but rather across a network where parts of an application run on different machines and might be shared among applications. Components of an application might run in different locations on the network from day to day, adding to the complexity. It has become very difficult to know if a distributed application is completely running at a given time, let alone running properly and efficiently. Application downtime can be reduced or eliminated by using application management features that allow modeling, monitoring, and management of the applications. Choosing an application server with proper management features that proactively keeps applications running can significantly reduce application downtime and help to deliver a Service Level Agreement established with a customer. The first goal of effective application management is to identify all of the applications components so the IT manger can monitor the entire application with confidence (modeling). The second goal is to quickly identify the specific problem when something is wrong with an application (monitoring). The third goal is to give the IT manager or the management features themselves the ability to correct the problem quickly (manage). Applications will also have to be modified occasionally for enhancements or to fix bugs. Allowing these changes to be implemented without bringing down the application is another feature (a hot swap) that can reduce application downtime. Modeling Eliminating application downtime is possible, but the enterprise must be able to define and model the complex relationships among the components that define the distributed application. If the management software is compatible with the application server, much of the modeling work will be done for the user because the management tool will be able to automatically identify applications and components running on the application server. This feature models the basic application for the IT manager wanting to manage the application. Monitoring Managing a distributed application is more difficult than managing applications running on a single machine. In order to successfully monitor and manage a distributed application, the application must be monitored and managed at the component level. The status of components within an application should be easily identifiable by the management features. Many management tools today manage infrastructure and applications only at the process level. Unfortunately, such tools will not be able to answer the simple question is the application running? Because components of an application can be distributed across a network, one or more components of the application might 8

9 not be working, yet the application could appear to be functioning properly. If the application is not managed at the component level, a broken component could go days before it is detected. If the component is critical to the application, such as a pricing component, days of transactions can be lost before the problem is identified. Managing Applications can be fixed only after the problem has been flagged and diagnosed. Problems should be quickly identified either through a visually represented GUI or through error and event logs. Even if the management capabilities proactively correct the problem within an application, an operator will want to be aware of the problem that has occurred. The more granular the management of the applications, the quicker the problem can be diagnosed. Application management features should allow the user to view, start, stop, and ping components and applications remotely from a central console. All of these features work together to provide a powerful tool to maximize application availability. Figure 6: Application monitoring at the component level using the Borland AppCenter console When features such as fault tolerance and load balancing are used by the application server, there will be components on the network that are not being utilized all of the time. These features will be invoked only when a sister component fails or is overloaded. The application will continue to function properly, but the IT manager will want to know that there was a problem. Again, only through management at the component level can these problems be easily and quickly identified; application availability is improved because problems can be identified before they bring the application down. Performance monitoring is another management tool that can help contribute to lower TCO. Tracking the demands for applications throughout the day provides the information that allows for the optimization of network and hardware capabilities. By tracking performance statistics, application instances or replicated components can be shut down if they are not maintaining a minimum threshold level. This helps optimize memory and network bandwidth. Complete vendor product offerings As we have seen, numerous aspects of an infrastructure affect TCO. When making a purchase decision, an enterprise must consider costs from developing to deploying to managing all of the enterprise s applications. We feel there are few vendors offering enterprise-class products that will lead to lower TCO from development through management, warranting careful examination prior to purchase. While it is ideal to purchase an infrastructure through one vendor in the interests of superior interoperability and cost-savings through volume discounts and support contracts, core functionalities such as performance and scalability should never be sacrificed. 9

10 Summary Today, purchasing decisions are being scrutinized more than ever. A software purchase is made to enable the extended enterprise to function more effectively and efficiently. Often, hardware sales are pushed in conjunction with the purchase of software with promises that more powerful hardware will make applications run better. As we have discussed, this is no guarantee. Depending on the size of deployments, an organization can save anywhere from tens of thousands to millions of dollars by choosing an infrastructure that allows the organization to scale economically. Applying the concepts discussed in this paper should help drive these cost savings. There is continual market pressure to deliver applications to market cheaper and in shorter timeframes. To some extent this has been accomplished, but often at the expense of delivering solutions to the customer. Because distributed applications are more complicated than traditional applications, they are more easily broken, require increased maintenance, and are much more difficult to manage. Many of the applications being developed today are critical to the financial success of a company. Choosing an application server that contains management capabilities is vital to the availability of mission-critical applications. A successful infrastructure should bring reliability and efficiency to an organization while also reducing the costs of hardware and IT personnel associated with supporting the infrastructure. There are countless roadblocks preventing a business from growing in this economy, but careful choices can ensure that Total Cost of Ownership for an organization s infrastructure is kept at a minimum. 100 Enterprise Way Scotts Valley, CA Made in Borland Copyright 2002 Borland Software Corporation. All rights reserved. All Borland brand and product names are trademarks or registered trademarks of Borland Software Corporation in the United States and other countries. Java, all Java-based marks, and ECperf are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All other marks are the property of their respective owners