Easing the Pain of Enterprise Application Deployment

Oct. 1, 2003 12:00 AM

To provide the best application performance, reliability, scalability, and security for J2EE applications, many large organizations utilize network load-balancing appliances and application switches. However, coordinating the deployment of applications between application developers and network managers can be a slow, painstaking process for companies choosing the many advantages of the network-based, load-balancing switches.

By developing an application to manage the time-consuming coordination between these two teams, developers can self-serve their needs more quickly, network managers can save valuable time previously spent performing manual tasks, and companies can experience more flexible application deployment and updates.

Budget-conscious IT departments can also save enormous amounts of scarce financial resources and time. On a network basis alone, conservative estimates show that companies can save nearly $20,000 per network engineer per year in time spent managing this process by building a very basic application deployment-and-update application. At the same time, the client experience is improved through better orchestrated application deployment.

Summarily, an opportunity now exists to help automate the process of deploying and updating Java applications in order to save development time, ease frustrations of deployment, and gain flexibility to deploy new applications on demand while offering the best client experience.

The Current State of Enterprise Applications
It should come as little surprise to developers that as Web applications have flourished, so have demands on the application servers required to deliver them. The days of deploying an application to one server and hoping it delivers performance and reliability are a thing of the past.

As a result, applications are typically deployed in a redundant fashion across multiple identical application servers. This ensures that the application is available when requested, even if one application server is out of service or experiencing technical difficulties. Traditional "load-balancing" solutions help virtualize a specific application IP address so that when people access a URL or IP address, the load balancer determines which redundant server is best suited to accept and respond to the application request.

The advantages of load balancing are significant. Most serious Web sites and e-business applications today employ some form of load balancing because it ensures a predictable client experience. Load-balancing solutions also help increase application performance by distributing requests to the best performing servers. In some cases, they can deliver more cost-effective applications due to lower server license costs and server expenditures.

When it comes to application reliability and load-balancing options, companies usually consider two alternatives for increasing the reliability and performance of their applications. One choice is software load balancing, which is included as a feature with most Java application servers. In this scenario, application servers help distribute load by utilizing some form of clustering or "round robin" load balancing. While this capability is usually included in the price of application servers, it comes at a cost to server performance. In many cases, software load balancing can inflict a 20-40% performance hit to each application server running the load-balancing software.

Alternatively, companies choose hardware solutions that help provide load balancing and more intelligent IP traffic management to realize significant advantages while complementing their existing software clustering. A key advantage to this is extremely high reliability (99.999% or less than 5.3 minutes of downtime per year). For applications utilizing HTTPS for security, these devices can also offer performance optimization such as hardware-based SSL processing and acceleration. These devices can also provide more intelligent balancing schemes for complex applications using persistence. In the event a server goes down, the user session can typically be routed to the next available server for seamless, transparent application continuity.

While network devices provide advantages for high availability, reliability, and performance perspective, there's an added benefit for application developers and network staff who are responsible for deploying and updating applications: these devices provide an ideal control point to help orchestrate application updates and deployment at the ingress and egress point of all application requests.

Application Deployment and Update Challenges in the Enterprise
Deploying or updating application components is a topic of pain and frustration for many companies. While they desire the high availability, reliability, performance, and security that the combination of network load balancers and application servers provides, orchestrating application deployment requires collaboration between the application and network teams.

Updates require access to servers to perform application updates and enhancements on a regular basis and usually require manual intervention by network administrators. Typically, this process requires application teams to request manual assistance from the network team to stop servers for updates and then restart them when updates are completed.

This approach has proven to be a burden for both the network and application teams. It takes longer to complete updates. There is an increased chance of human error and deploying new applications takes too long. To further complicate these matters, update times must be scheduled during periods experiencing the least amount of application traffic - commonly 2:00 a.m. on a Saturday morning. In almost all cases, the manual network procedures can be automated to shorten application development life cycles, enhance developer productivity, and roll out applications instantly for the best client experience.

A contributing factor to this challenge is the limited information provided by the J2EE specification. The J2EE spec, which vendors rely upon to build application servers and developer tools, provides guidance for installation and configuration. But it neglects to address execution, which is left to the product provider's platform. While many application server vendors have developed their own update and deployment capabilities, they are usually proprietary in nature. When combined with network devices in true enterprise environments, the combination of limited specifications and vendor-specific solutions can further complicate matters.

Finding the Solution
An opportunity exists to build intelligent applications that bridge the gap between the J2EE applications, servers, and the network that supports them.

When considering application development options, the two most likely approaches include SNMP and Web services based on SOAP/XML. While both offer the ability to help automate functions necessary for deploying and updating applications, SNMP has inherent security issues. For instance, the only access control available for SNMP is the ability to restrict access on IP addresses and alter the public string. Further, communications are done via clear text, which can enable other applications to spoof addresses and requests. Finally, SNMP requires developers to learn specialized MIB vocabularies to develop applications.

To me, Web services via SOAP/XML appears to be a much more viable option. Based on widespread industry support, it offers rapid development with many different development environments and enables the use of virtually any language to fit developer needs. Therefore, I'll utilize SOAP for the following application example.

Application Overview
An application can be created quickly to help automate the update process. Applications can be full-featured, Web-client solutions that enable developers to log in and control which servers or applications they wish to update. Or, this same functionality can be combined with existing code management solutions to streamline the deployment process.

For this example, I'll outline the basic building blocks that can work for either scenario. To gracefully update application components, the update application must locate the server resources supporting an application, determine which servers need to be updated, gracefully remove existing traffic and connections to the server hosting the application, and enable the update process to begin. After the application components are updated, initialized, and tested, the application must also gracefully reintroduce the new applications to client requests.

Key Terms and Definitions
While network load-balancing technologies are not new, some of the terms and function definitions may not be familiar to application developers. Since these terms relate to the interfaces and methods I will be discussing in this example, here are some basic definitions of terms common to network devices:

Node: A specific combination of an IP address and port (service) number associated with a server in the array that is managed by a network load balancer.

Pool: Composed of a group of network devices (called members). The network load balancer distributes requests to the nodes within a pool based on the load-balancing method and persistence method you choose when you create the pool or edit its properties.

Member: A reference to a node when it's included in a particular pool. Pools typically include multiple member nodes.

Virtual server: A specific combination of a virtual address and a virtual port associated with an application or Web service managed by a network load balancer or other type of host server.

Connection: An active TCP connection to a specific server.

Application Description and Code Samples
For this example, the functions are relatively generic and represent logical steps needed to deploy or update application components on servers managed by a network load-balancing device. The code samples, designed to provide guidance on how to build your own application, are specific to F5's iControl API. Directions for how to learn more about this API and obtain more samples are provided at the end of this article. For other networking vendors, you can visit their respective Web sites for additional information on how to use the APIs they make available to developers.

Query for Pool Associated with Virtual Server Address
To locate the pool of nodes or members associated with a virtual server, query the virtual server address (see Listing 1). The response will indicate which pool(s) are available to manipulate. In many cases, the virtual server is the primary URL or IP address associated with a particular Web service or application.

Query Pool for Members
To determine which members (servers) are available for application updates, query the pool associated with the virtual server (see Listing 2). From the response, you'll have a listing from which to choose. This will be the total collection of servers that you will have access to when deploying new applications or updating existing applications.

Determine How Many or Which Member(s) to Target
In many cases, this is a business-process decision. The number or quantity of members you will want to target for updates comes down to a simple question: How many servers can you afford to take out of service at any given time? Your decision may be based on a number of factors including current server load, server resources provisioned for various peak times, or possibly something as elegant as calculating the average number of persistent application connections.

One option, although not defined in the article, could include the creation of server groups to be utilized as "update groups." These could then enable switching between groups when updates are executed (see Listing 3).

Set State to Disable Targeted Members
Once the targeted members (servers) have been identified, the next step is to proceed with setting the state of the members you wish to update. This step effectively prepares the servers by ensuring that no new client connections can be established. Further, it ensures that no new traffic is sent to the servers. Once this state is set, new connections and traffic will be sent to other members in the pool, ensuring that new requests always get an active server and not a server going through the update process.

void setNodeState(IPPortDefinition[] members, int state) {
...
// Setting method parameters
soapParams.addElement(new Parameter("node_defs",
IPPortDefinition[].class, members, null));
soapParams.addElement(new Parameter("state", Integer.class,
state, null));
// Set Call object method and parameters
call.setMethodName("set_state");
...
}

Establish When to Drop All Connections from a Member
Once the state has been set to disable targeted members, the decision must ultimately be made as to when all remaining connections will be disabled. There's a variety of criteria from which to choose depending on your business needs. A good approach can include determining the threshold of the tolerable number of connections to drop. For example, once only two connections remain, drop them and disable. Another alternative is using the time since the member was disabled. A further option could include looking for connections from specific client IP addresses. When these connections cease, disable the server.

Once the member is disabled and all connections are dropped, it's considered offline and ready for updates.

void setNodeAvailability(IPPortDefinition[] members, int avail) {
...
// Setting method parameters
soapParams.addElement(new Parameter("node_defs",
IPPortDefinition[].class, members, null));
soapParams.addElement(new Parameter("state", Integer.class,
avail, null));
// Set Call object method and parameters
call.setMethodName("set_availability");
...
}

Update Application Components on the Target Server
At this point, the developer has many choices as to the best way to distribute the application. Most simply use existing component distribution techniques that can include FTP, programmatic deployment, or even integration with an existing code management system.

Once the update process has been completed, appropriate steps should be taken to initialize or register new components on the server. It's further recommended that new component testing be performed prior to restoring the member to an active pool.

Update Application Monitor
One feature usually deployed with intelligent network load-balancing solutions is application health checking. Monitors check application availability at periodic intervals based on specified criteria. This ensures that if an application goes down, no new client requests are routed in its direction.

If an application monitor needs to be created or has been in use for previous versions, now is the time to create the new monitor. Once created, it is associated with the newly updated member and the old monitor is deleted (see Listing 4).

Set Updated Member to Receive Connections
Now that application updates are completed, the server tests out correctly, and the monitor is set, the member is ready to be reintroduced to the pool of servers supporting an application. The member state needs to be set to receive connections and placed in an enabled mode.

Set State to Allow New Traffic
Once enabled, the member is reintroduced to the pool and can begin allowing new client requests that will respond with the new application just deployed.

Putting It All Together
At this point, there are a variety of options for how a member should be reintroduced to the incoming flow of requests. In most cases, how it is reintroduced depends on factors based on overall methodology and the process outlined for spot or rolling updates.

For instance, an organization may want to schedule regular updates when applications or sites have specific availability requirements. Alternatively, this application could enable an organization to update applications at any time, given that now there's control of how the application is deployed, such that clients will continue to have seamless application access throughout the process.

One deciding factor may include whether the application is a basic application or a more complex application using session persistence. For basic applications, an application based on the building blocks provided may stage blocks for updates. For example, in a pool of six servers, the first three may be updated and upon being reintroduced into the pool, the remaining three are removed to follow the same update process.

For applications where persistence is a factor - particularly long persistent sessions - a deployment strategy might include creating a new pool for the updated servers, adding the servers to that pool, and then remotely telling the network device to begin directing new client requests to the newly formed pool of updated servers. The benefit to this approach is that all remaining persistent sessions running on servers using the old application version can time out in their own graceful manner. This helps ensure that client experiences go smoothly. Only after the session is complete will the servers be cycled through the update process.

Application Benefits
By deploying this solution to ease application deployments and updates in a J2EE environment, companies are able to increase developer productivity, reduce deployment frustration, reduce management overhead, and gain flexibility to deploy new applications on demand. With this solution, the customer can:

Reduce time spent managing the deployment of applications: Some customers have reported savings of 3-5 hours per week per network administrator. Given only four network administrators saving six hours per week, this could equate to a savings of 144 workdays/year. Given the cost of network management, this can relate to significant cost savings for any organization.

Accelerate deployment of applications through automation: Replacing manual processes with automation enables faster updates and deployments and thus increases the developer time available to continually improve applications. Further, it provides end users with access to more current applications - increasing their net productivity.

Reduce errors associated with manual intervention: Some estimates suggest that nearly 80% of network configuration errors can be attributed to manual, human intervention. By automating this process, you can reduce a significant volume of configuration problems that limit mission-critical application availability.

Related Information
For additional information and sample code to build similar applications, please visit http://devcentral.f5.com.

Related Links

▪ Source Code

About Jeff Browning
As Product Manager for F5 Networks, Jeff is responsible for driving the product and marketing strategy for F5's iControl API and Software Development Kit. With over 10 years of software industry experience, Jeff's extensive background in Web services, Enterprise Portals, and Software Development tools at leading companies like Microsoft and DataChannel helps bridge the gap between networking technologies and Web services applications for better performing, scalable, and secure enterprise solutions