views:

78

answers:

2

We are working on a project to develop a platform that will allow us to easily add multiple applications onto a cloud platform so that the applications can be offered on a SaaS basis. There will be single sign on access to all the apps (likely through Open SSO).

We are thinking of: 1. Mule ESB (to integrate apps developed in different languages) 2. GigaSpaces XAP (for scalability) 3. Appistry Cloud IQ Platform (to upload applications) 4. GoGrid for Hosting

Is this the right combination of tools? Can you recommend other combinations?

A: 

You are actually choosing an very good stack. Mule and Gigaspaces are frequently used together and Mule ESB Enterprise (not the open source version) actually embeds Gigaspaces technology to provide high availability.

GoGrid has an excellent platform and the companies that support Mule ESB, GigaSpaces, and Appistry are all GoGrid partners, so you can expect good support using that stack. I'm not too familar with Appistry, so I can't comment directly on them.

Ken
+1  A: 

I'll state up front that I'm one of Appistry's original engineers, and now product manager. I'll stick to the technical facts. :-)

As you mention, you can use Appistry CloudIQ Manager to simplify deploying, managing and life-cycling your applications and associated services across your cloud servers. Manager can do this with any arbitrary service or service/application combination, and make sure they stay up and running on each server. Manager scales applications up and down as servers come and go. CloudIQ Manager will work fine with Mule and GigaSpaces.

As for other combinations, particularly for your requirements of scalability, and integration of apps developed in different languages, you could consider CloudIQ Engine as an application platform. Engine could be used in the place of GigaSpaces, or working in combination with them, depending on which piece you are addressing.

CloudIQ Engine is a fully decentralized application container. Engine supports multiple languages for integration, both on the client-side and the cloud-side.

On the client-side, you can use Spring and .NET remoting to call Engine-hosted objects (caller and callee must be in same language) or use the CloudIQ client API (C/C++/Java/.NET/SWIG-wrappable) to submit requests with user-defined process flows, possibly eliminating the need for the ESB. Flows execute in the cloud on Engine, and allow a single request to orchestrate calls across multiple methods. The methods can be in different languages.

On the cloud-side, you can deploy Java objects (POJOs and Spring Beans) and .NET objects (PONOs), as well as C/C++ libraries as Engine applications. Java and .NET objects can be deployed unchanged. C/C++ (and other binary libraries) likely require some wrapper code. Meta-data describes workload policies and other cloud-side behavior for your code.

Engine applications are fully symmetrical. Every server in the cloud runs your application code. Built-in, software-based load balancing directs requests to the server best able to handle the job. Your code inherits scalability from the platform without code changes. Beyond scale, your application also gets reliability and automatic fail-over for free, along with the ability to define in metadata how you want your application to act in response to failures. Engine automatically scales your code, unless it is non-thread-safe, across all available CPU cores. If your code is not thread-safe, CloudIQ can run it efficiently, but at a cost of not utilizing all cores.

You can easily try it out. CloudIQ Platform Community Edition allows free, unlimited use of the software on up to five servers and/or ten processing cores (including production). The community edition is available at Appistry Peer2Peer (registration required): Appistry Peer2Peer

Appistry customer Presidio Health is running Java-based CloudIQ Engine applications on GoGrid with great success. There is a webinar and case study with technical discussion here (registration required): Appistry Resource Library

Guerry
Hi. Thanks for a fantastic answer. Some follow-up: 1. Using Appistry, how quickly can an application be onboarded (approximate time for one developer -- is it one hour, one day or more?). 2. If we on board a partner's application, do we need their source code? 3. Once an application is linked, do you have a subscription management tool to allow an end user to quickly subscribe to an application? Thanks again for a great answer!
kburke
With CloudIQ Manager, porting services/apps can take less than a day. This becomes more complex if a service can't run in a distributed manner or is manually configured. We have templates for things like Tomcat, Jetty, IIS, etc. and so those can be less than an hour. CloudIQ Engine applications vary. We've had users port thread-safe business logic (dll/so/jar) or command line exes into a fully distributed cloud application in anywhere from an hour to a day. As for #2, we just deploy and run binaries, so you could include them. I can answer more questions here: http://www.appistry.com/community
Guerry