Earlier this week, I gave a joint webinar with James Liddle, where we outlined
practical guidelines for saving costs using middleware and application-level Virtualization:
- Saving the cost of peak/static provisioning using on-demand scaling
- Saving the downtime cost
- Saving costs through outsourcing part of our application and operations to the cloud
- Saving costs using application level optimization (doing more with less)
- Saving costs using platform consolidation to reduce the number of software components as well as utilize OpenSource and more commodity Software packages
Towards the end (Slide 20), Jim Liddle presented real life case studies from the iPhone launch in the UK and how some of hose principles have been applied to enable a successful launch in the UK.
Additionally, Jim went through some of the motivations and case studies that led different Telco, Online Gaming and Start-up companies to utilize our cloud, offering to gain better cost effectiveness.
For those who did not have the chance to participate in the webinar, we uploaded a recorded version of that presentation for you to view.
I would like to point out a few specific items from this presentation:
Beyond Server Side Consolidation (Slide 5)
Server-Side-Consolidation (SSC) played an important role in bringing the concept of virtualization to mass adoption. It forced organization to be able to map their application into concrete packages and look at machines as a logical entity rather then just a physical entity. Server-Side-Consolidation also brought a relatively simple model for cost saving: Instead of running applications on dedicated HW you can consolidate them into one machine. By doing so, you can reduce the number of servers and save the hardware and the operational costs associated with that.
Having said that, SSC is only one *very narrow* aspect of virtualization that unfortunately became too coupled with Virtualization.
The next step is obviously to move from SSC to application and middleware level Virtualization. Application Virtualization refers to the opposite scenario. Instead of putting multiple applications on the same hardware, we are taking a given application and spreading it on a pool of machines. This holds significant potential for making applications more efficient. For example, just think of the saving potential gained by moving applications from static peak-load provisioning to on-demand provisioning. In addition to that, we can utilize commodity hardware resources to get the power of high end machines.
Practical steps ( Slide 19)
One of the main concerns that most people have WRT to application level virtualization is the effort associated with applying those principles.
The table below captures the value vs effort that we can receive with each part of our middleware and application level virtualization.
As you can see, there are steps that require non or very little changes to our application:
For example, taking an existing web application that requires 10 machines to meet certain peak load, however on average it needs only 3 machines. Normally we would statically provision 10 machines to meet the peak load which means that on average those machines would be poorly utilized. . Instead, we can provision our web container on-demand and use Pay-Per-Use model to pay only what is consumed. This will enable us to save roughly 7 machines (10 - 3 ) and wouldn't require any changes to our code. (You can learn how you can do that with GigaSpaces here)
If we have a computational business logic or even a rendering application (a good example of that is Slideshare or Yutube). Those type of applications tend to deal with fluctuating loads. So if on average we consume 10 machines and for peak we need up to 90 machines - you will be able to save ~80 machines! by provisioning the computational/rendering machines on-demand. (See here on how to use GigaSpaces for MapReduce computation and here to learn on how to use the Actor model)
On the messaging and data side, we can reduce the amount of machines and the cost of scaling by partioning our messaging or data thus enabling linear scaling of those layers. In addition to that utilizing memory resources instead of files provide a significant boosst in performance. The combination of the two enables us to utilize commodity software and hardware resources instead of high-end resources - for example we don't need to rely on high-end databases, we can simply use MySQL.
Final Words
In this presentation we tried to gather most of the knowledge based on our past experience. Most of these lessons are generic and not necessarily specific to GigaSpaces.
I also tried to provide some practical implementation guidelines (Slide 19):
- Avoid radical change, enabling a gradual process
- Choose an architecture supporting linear scalability
- Minimize vendor lock-in
- Enable application portability and freedom of choice of:
- Cloud provider, Web container, Programming language, Database
- Minimize API lock in:
- Use of standards
- API Abstractions – when standards are not available
- Future proof your application
- Don’t make decisions today, but be ready to make one without major effort
- Avoid long-term commitment – choose the right licensing model
Real life case studies:
I would like to encourage you again to listen to the case studies (Slide 20) and learn how others apply some of those principles in their local-IT and Cloud.
Additional references:
- New quick-start guide shows how you can easily scale your on-demand scaling to your EXISTING web application.
- New whitepaper: Survival Guide for IT During the Economic Meltdown
