How elastic is your ESB?

Knowledge base
, , , , ,
1

Issue 4, 2013

 Download pdf

Scaling made easy with Command Central 9.5

Is your Enterprise Service Bus (ESB) able to handle expected (and unexpected) peaks in demand? Maybe you have sized it to handle the busiest day of the year, just to find it sitting idle most of the time. Or maybe it is under-powered and struggles to perform well during spikes in demand or with gradually growing transaction volumes. So wouldn’t it be great if you could easily scale up and down the size of your ESB in line with the demand at the time? Well now you can! Read on to find out about the exciting new features of Command Central 9.5 that put the elastic ESB within reach.

Agile Infrastructure

The easiest way to add capacity to an ESB these days is through so-called horizontal scaling. This involves adding additional machines with the same software and configuration that can share the load with existing servers. With most organizations using virtualized environments, adding a new “machine” is no longer a matter of capital expenditure requests, purchases orders, and lengthy delivery or installation times. Virtual hardware is now available within minutes, either in a company’s own resource pool (also known as “private cloud”), or in a public cloud environment like Amazon Elastic Compute Cloud (EC2).
 
But spinning up a new machine is only the start of the story. What about the software, fixes, configuration and assets (like services)? How do you make sure these are available with as much agility as the virtual hardware? What is needed is a way to automate the installation of products, fixes, configuration and assets to facilitate horizontal scaling at the touch of a button, or even without the touch of a button, through active monitoring of performance.

Command Central

Command Central was introduced in webMethods 9.0 last June and provides a single, centralized tool for monitoring, managing and configuring all webMethods products in your landscape. Initially, support is focused on the core webMethods products: Integration Server, Broker, Universal Messaging and My webMethods Server (MWS). All functions of Command Central are available not only through a Web user interface but also through command line tools and a REST API. This means it is easy to script and automate using standard tools like Ant or shell scripts, or webMethods Flow or BPM. You can already monitor and start/stop products centrally using Command Central and we are adding more and more configuration capabilities with every release. One of the most popular features is the ability to compare the installation, fixes or configuration of multiple instances side-by-side in order to easily find discrepancies.

Template-Based Provisioning

Command Central 9.5 adds the capability to use templates for installing, patching and configuring your webMethods landscape. A template contains all the relevant information about which products are installed, which fixes are applied and what configuration is present. A template is created by extracting all that information from an existing installation, using the “Save as template” function. A template can be modified if necessary, and then applied to a different machine. 
The target machine only needs to have the Platform Manager component running—a small agent that is part of Command Central. Platform Manager is best included in the machine image (e.g., VMware or EC2) you use to launch new instances. When applying a template, Command Central remotely installs the exact products, fixes and configuration that are defined in the template, thus creating a clone of the original installation.

Establishing the Elastic ESB

With the building blocks provided in Command Central 9.5, you just need to put them together in a way that suits you
and your environment:
  • Triggering scale up/down
    This could be manual by executing a service, or through a portlet or Web application. Or you could monitor a certain KPI and trigger scale-up based on the KPI exceeding a pre-configured value. You could monitor performance using Optimize for Infrastructure and define a rule that triggers a service invocation that scales up. You could also keep it simple by using the basic KPIs provided out-of-the-box in Command Central. A scheduled service in Integration Server can periodically monitor the performance KPIs (such as average service execution time) and trigger scale-up if things slow down too much.
     
  • Orchestrating the scale-up process
    The scaling process may involve additional steps outside the scope of Command Central, and you may want to control the sequence, or include a manual approval step (in the case of an automatically triggered scale-up). You can orchestrate the process using command-line scripts or Ant, or you could use Integration Server Flow or BPM to control the sequence and provide visibility and control.
In the end—with minimal effort—it is possible to fully automate the process of scaling up or down your ESB, as we demonstrated at Innovation World this year in San Francisco.

 

Elastic ESB in action

At this year’s Innovation World conference in San Francisco, we demonstrated the elastic ESB in a demo that showed fully automated scale-up based on an increase in load on a group of Integration Servers.

1385×799 121 KB

Figure 1: Elastic ESB in action
 
 
The demo used a scheduled Flow service to retrieve performance KPIs from Command Central and trigger the scale-up process if a pre-set SLA was exceeded (figure 1). The performance was also visualized on a Software AG Presto dashboard (figure 2).
397×787 90.4 KB
Figure 2: Presto dashboard showing current
performance ( see mobile device)
 
A BPM process was used to orchestrate the sequence of steps involved in the scale-up (figure 3) and to monitor its progress.
 
We used Apache JMeterTM to generate a large number of concurrent service calls and an Nginx software-based load balancer to distribute to load across Integration Servers.
 
By simply increasing the number of concurrent service calls in JMeter, the scale-up process was triggered, resulting in an additional Integration Server being added to the group, thus bringing service performance back within the defined SLA. The entire process took approximately 15 minutes.
 
Scaling down was a simpler process, involving removing the instance from the load balancer and Command Central landscape, followed by deleting the virtual machine at the cloud provider.
1254×891 188 KB
Figure 3: Scale-up process in BPM

Other Use Cases

The template-based provisioning features can be used for much more than the elastic ESB scenario described above.
  • Disposable test environments
    For many organizations, coordinating access to test environments can be a challenge. Ensuring various test teams don’t step on each other’s toes in a shared test environment can cause headaches for a project manager. Now, they can use template-based provisioning to create private clones of a test server, thus allowing each test team to use their own environment without fear of conflicts with others. They can also be sure that the environment they start with is consistent and reliable, without chance of it being disrupted by a previous test run by another team.

     
  • Repro environment
    Isn’t it awkward when you have a problem in a production environment and can’t reproduce it in a test environment, just to find that the configuration isn’t the same, or a webMethods fix is missing? So why not use template-based provisioning to create your repro/test environment as a clone of your production system? Saving the template from a production server does not require it to be stopped and doesn’t affect performance. So creating a reliable copy of a production system has never been easier.

     
  • Applying fix sets
    Templates can contain products, fixes and configuration, but it is also possible to save a template only containing fix information. So if you have a regular fix schedule, you can install the candidate fixes as usual using Software AG Update Manager (SUM) on a development server. When you are ready to roll them out to the rest of your landscape, save the fixes as a template and then apply it to all your test and production servers. All this happens remotely, so there is no need to manually run SUM on each and every server.

What’s Next?

Command Central 9.5 provides template-based provisioning through command-line and API. In the coming releases, we plan to make these functions available through the Web UI, also adding cloud factory and repository management capabilities, as well as extending the set of webMethods products that can be managed through Command Central.