Elastic Billing — One Size Does Not Fit ALL

Scalability and elasticity are terms often used interchangeably even though they have very important differences. With all of the talk about the cloud, its important to understand what is a true elastic architecture and how customers benefit from it.

Scalability vs Elasticity

Scalability simply means that you can add more capacity to improve performance and load handling capability of a software application. In the move towards cloud enabled solutions, more shared applications are being deployed that receive variable work loads which can be based on time of day, day of week, end of month, end of quarter and end of year. For these types of applications, there has to be enough capacity in place to handle all the load on the system at any given point in time. The highest point of these is known as “peak load”. The varying workload patterns will differ by application type, and matching capacity to peak load is crucial.

The traditional mechanism for scaling a shared software application is to add more or larger components to support the increase in demand on the application driven by these peak load conditions. In traditional scalability, this requires that the software provider add more fixed capacity by purchasing additional hardware and software which in turn impacts the cost structure through higher fixed costs. There can be significant lead times and costs associated with this approach and once put in place, it can be very difficult to remove this capacity. Given these factors, the decision itself to add capacity can take days, weeks or months in addition to the time to procure and enable the new capacity.

Often times, the installed capacity is significantly under utilized when loads are low during the non peak periods. However, the need to maintain excess capacity to handle the peak load conditions means higher than necessary ongoing operational costs and excessive waste. The larger the difference between the non-peak and peak loads, the more waste is present.

Enter elasticity, where capacity can be not only added, but also removed. And, instead of having to wait days, weeks or months to add capacity, it can now be managed on-demand. In addition, instead of having to invest up front in fixed capacity, elastic capacity can be rented. An elastic architecture typically has a nominal amount of fixed capacity to handle the steady state load on the system, while incremental capacity can be added or removed on a pre-determined schedule or in response to load conditions.

Elasticity == No Upper Boundaries on Growth

While traditional scalability has been around for many years and is well understood, the financial burden of justifying the return on investment to add fixed capacity has always placed an artificial limit on the total performance of a system. Since the company is having to make capacity investment decisions based on the peak loads, at some point an upper-bound has to be established to maintain financial responsibility.

In the elastic model, there is no artificial limit placed on the total performance of the system since incremental capacity is a marginal-cost. With an elastic approach, the appropriate amount of capacity can be provisioned as necessary to match both the steady state and fluctuating load patterns. Instead of a customer asking “what is your upper performance limit”, the question becomes “how much performance do we need to provision for you”.

Cloud != Elastic

While a good cloud infrastructure can provide the tools needed for elasticity, it is critical to understand that not all cloud providers are elastic. Many of the leading cloud applications in the market today are not built with an elastic architecture that is designed to scale quickly and easily. Salesforce is perhaps one of the most well-known cloud business platform in the world. However, it is a prime example of a cloud solution that is currently NOT elastic. Not only are users locked into tiers based on pricing models, but the underlying infrastructure of the platform does not allow for agile scaling to accommodate burst processing or unexpected growth.

Additionally, there are many on-premise solutions which are being virtualized and hosted in an “internal cloud” like manner. But, this doesn’t mean they have the ability to quickly scale up and scale down their capacity, either.

Even with an elastic capable provider such as AWS or similar service, the solution itself must be designed to horizontally scale, and automatically manage capacity as needed. Not only must businesses be utilizing an inherently elastic hosting provider, but the software itself must also be architected to take advantage of elastic design.

Why Elastic Billing is Important

Applications like TRACT are particularly well suited to the elastic model with their “bursty” load patterns. As such, TRACT is not only architected to take full advantage of this model, it is deployed at hosting providers that excel in elastic infrastructure. This provides a more efficient cost structure for Gotransverse that can also scale to the most demanding workloads that are becoming prominent in the increasingly connected world.

Analysts agree the ability to agilely scale services in the cloud is crucial to success. “…[T]oday we see most of the new demand for billing solutions gravitating towards cloud-based solutions. Increasingly this has little to do with economics and more a function of increased agility and flexibility and the fact that by now many companies have most of their key customer and sales force facing applications in the cloud,” says MGI Research in their latest MGI 360 Ratings - Agile Billing Market Rating Report. "Requirements of a company that needs to handle a few hundred monthly transactions of any complexity are likely to be very different from a company that handles a billion transactions a day in near real-time.”

A truly elastic billing solution, such as TRACT, can manage capacity on-demand to meet customers’ initial needs, as well as their future growth.