Cloud Computing Strategies for the CIO
Nati Shalom, CTO of GigaSpaces Technologies and Argyn Kuketayev, Project Manager at Primatics discussed how to bridge the benefits of the Google App Engine (GAE) and Amazon Web Services (AWS) paradigms.
"What we really want is the flexibility and performance of AWS and the simplicity and ease of use of GAE," Shalom said. "We need to abstract the code like GAE from the infrastructure. We don't want to know that our messaging is now running on a cluster of X virtual machines. We just want to be able to send a message to a queue even though it is partitioned across tens or hundreds of machines."
AWS pros and cons
With AWS, the main focus is on allowing a developer to create applications on any common server and application stack. The developer creates an image of the desired OS and application stack, which they can bring up on demand. But such comprehensive low-level control opens up a lot of complexity.
The strengths of the AWS approach is flexibility. The developer gets full control of the environment, storage, and networking, and can run it in the same way as an application in a local IT
Requires Free Membership to View
environment. It can also provide performance and the flexibility to scale up as required.
On the downside, load balancing is often tightly bound to the application server it is running on. As the application moves to AWS, the developer does not know how many servers he needs until he tests the application, and then someone will have to monitor it to scale up during moments of peak demand.
 |
||||
|
|
|||
|
||||
Google App Engine pros and cons
With the Google approach, the main attraction is simplicity. Shalom noted, "While it is not trying to provide the same solution to all applications, it is very tightly controlled, which can prevent you from doing the wrong things. But it can also prevent you from doing the right things, and in some cases if you want to build an enterprise application, you need that level of control."
For a Java developer some of these limitations include sandboxing, which can limit network applications and make it difficult to run sever side components, or implement your own caching or messaging system. A developer can only run hosted code in a Google container and user services provided by Google.
Both AWS and GAE approaches can create problems when an organization attempts to port a multi-tiered application to the cloud. In many cases the application will have to be rewritten using a different architecture. There is no out of the box infrastructure for J2EE, and a new distributed programming model is needed. The developer has to think about the whole application stack, and not just the code.
The answer?
GigaSpaces approach to this problem was to split the deployment infrastructure across three parts: 1) a repository; 2) an XML-based application deployment descriptor; and 3) and an application provisioner. The XML-based descriptor allows the developer to programmatically scale up the application by turning servers on and off and manage load balancing across multiple servers.
|  | ||||||||||||||||
| |||||||||||||||||
Primatics wrote the first version of EVOLV:Risk as a hosted web application for a regional bank.. The application needed to be fault tolerant so that if one node crashed, they did not have to restart the application over again from the beginning. Kuketayev said that it is not just about the loss of four hours, but the office is trying to close out the month and needs to access data to end the monthly cycle so they can go home.
Using GigaSpaces' toolset they rewrote the entire application infrastructure in about four-months to run on top of AWS. Now they can kick off as many instances as required for different banking customers, and each instance runs significantly faster than before. Kuketayev said that it is important for banks that none of their applications run on the same infrastructure as another bank.
Kuketayev said that one of the biggest lessons is that you need to have your infrastructure do the provisioning for you automatically, or otherwise you end up spending a lot of time just turning things on and off. He said they are now using configuration APIs to automate this process, whereas before they were using scripts. This allow for automatically throttling and failover recovery without human intervention.
Kuketayev advised "You need to make sure you use the right tools … You don't want to have to worry about provisioning and reliability. Make sure you have provisioning, failover, monitoring and SLA out of the box."
At the moment, the GigaSpaces infrastructure only runs commercially on AWS, but Shalom expects to support other providers over time. Shalom noted that currently developers need to get both a GigaSpaces account and AWS account and pay for their services separately. Although GigaSpaces has tried to streamline the process, it is still a slight hassle.
Join the conversationComment
Share
Comments
Results
Contribute to the conversation