|
|
||||||||||||||||||||
| Home > Cloud computing News > Google App Engine plus Amazon AWS: Best of both worlds | |
| Cloud computing News: |
|
||
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 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 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 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?
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.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
|
|||||||