Nati Shalom's Blog

Need scalability? Don't forget pricing

In most discussions about scalability, we often approach the topic as a pure technical/architecture challenge, and ignore cost issues. The problem is that when we truly scale our application, and want to benefit from economies of scale, we're going to end up with scale limitations, not because of technical issues, but because of the pricing  and licensing models.

Scalable pricing

Scalable pricing means a pricing scheme that provides the benefits of economies of scale. Below are pricing models commonly used for software products and how they fit in the new dynamically-scalable world.

• Free - while this certainly sounds like the best option (and may very well be) the customer needs to be aware of the following:

- The free license of a software product typically does not include support: not an option for most mission critical applications.
- When you do pay extra for support, you will typically be charged just like any other run-time license on a per CPU basis.
- Make sure that the company behind the product has a sustainable business model, otherwise there is a good chance that it will either die when its funding dries up or change its license model to monetize its user base. That's fine, but all it means is that it's not really a free offering in the long run, and you don't know what the pricing model will be exactly.
- In terms of total cost of ownership (TCO), free products are not necessarily the cheapest option. TCO is dependent on many factors, for example, dependency on other products (and their license costs), the need for integration and maintenance, etc. See my post, Economies of non scale, for more on the topic.

• Subscription model - With a subscription model you pay a fixed periodical fee, typically on an annual basis for infrastructure software, and on a monthly basis for SaaS. Subscription pricing is suitable for on-demand scalability as it provides the flexibility to grow or reduce cost based on the annual use of the product.
• Pay per use - this model is even more flexible then subscription model as it gives you higher granularity. Pay per use is provides in various forms where the usage can be a measure of CPU utilization or bandwidth utilization. Amazon for example charge per machine utilization for its EC2 services and data-utilization for its data services.
• Perpetual license - This model is used to buy licenses in advance and pay for support separately (normally 15-20% on top of the per CPU license). This is the most commonly used model with commercial software products, however, due to the large initial investment required by this model, it doesn't fit well with on-demand environment.
• Enterprise unlimited license - This model enables you to pay premium price in advance (based on potential future usage) and gives you the freedom to use the software without any limit. This model fits to environment where you anticipate that over a fairly short period of time the usage of the product will become wide and therefore the pay-per use or any of the other models mentioned above will become more expensive.

Which model to choose?

Each of the models has pros and cons and therefore the answer depends on your situation. Also, over time, as the situation changes, you will probably realize you need a different license model, and so it becomes equally important that the product you choose will give you the freedom to move from one model to another in the future.

GigaSpaces scalable pricing

With GigaSpaces we continuously look into ways to make our software license cost fit the on-demand world. For example, we launched a free Start-Up program that provides a totally FREE version of GigaSpaces for startups (hundreds of start-ups have already signed up for this program since we launched it last year). We also provide a Pay-Per-Use model for those running on Amazon EC2.

We felt that even though this is a fairly flexible pricing, we could do better. As of our 6.6 release, we added the option to buy our software at a yearly subscription price, and we also launched a new package called XAP Standard Edition, which is sold at a very low price of $9,500k per package (not CPU) where the package includes two servers, 4 GigaSpaces nodes and up to 50 clients or remote servers.

These changes were designed to address the needs of developers looking to start running their applications at a relatively low scale, who need the full functionality of the product, but cannot afford the full XAP price. Another principle that we kept when we designed this package is that moving from Standard to Premium edition wouldn't require any change in your architecture or code - which means that you could always scale to the premium edition just by changing the license key.
More details about the new pricing model is available here

Other references:
GigaSpaces and the Economics of Cloud Computing

Economies of Non-Scale

Testability – the orphan child in distributed systems – Part II

In Part I of this post-series I discussed the importance of testability in distributed systems and outlined a set of key principles for addressing the issue.

The truth is that testability is often constrained by the products that we're using. In this post I wanted to outline how we at GigaSpaces address these issue with OpenSpaces, our new Spring-based development infrastructure:

Start with the architecture

There are a few components in OpenSpaces and Space-Based Architecture that significantly simplify the distributed architecture complexity:

Processing-Unit: unifies the deployment, scaling and fail-over behavior semantics of both the middleware and business logic components.

In-Memory Middleware: OpenSpaces takes advantage of the fact that space-based middleware can address both messaging and data using the same underlying technology. That in itself reduces a large part of the complexity, because we reduce the amount of moving parts in our architecture.

The fact that "spaces" can be collocated in-memory reduces the runtime footprint and provides a simple way for running the entire application in a single process environment.

Spring Abstraction – The Spring Framework was primarily designed to address the complexity of J2EE applications. OpenSpaces utilizes and extends many of the principles introduced by Spring, such as dependency injection and separation between the business logic and the underlying implementation through abstraction, remoting, etc. This simplifies the architecture and configuration of an OpenSpaces-based distributed application.

Measure scalability and fail-over as part of the unit-test environment

Because OpenSpaces is a relatively lightweight framework, it is easy to start an entire cluster within a single Eclipse session. This allows to very easily measure the behavior of the application in fail-over and scaling scenarios.

Enable fast iterative development 

The concept of the Processing Unit allows developing all of the business logic in a single VM and running it locally.  Moving it to a cluster, and scaling it, only requires to run that *same* processing-unit multiple times. This makes the production and unit-testing environments pretty much one and the same, and therefore, enables testing 90% of the functionality in a single environment. OpenSpaces helps you to take advantage of that and enable the developer to deploy the application from his or her testing environment to the production system by a click of a button, knowing that it's going to behave the same as in the local environment.

Keep the configuration consistent

In this respect, OpenSpaces provides a standalone container that is tuned to run within an Eclipse environment. Using this approach, a user changes only the container used between the development and production testing environment, while the rest of the code and configuration remains the same.