Cloud Agnostic Architecture?

Question

Hi,

I'm doing some architecture work on a new solution which will initially run in Windows Azure. However I'd like the solution (or at least the architecture/design) to be Cloud Agnostic (to whatever extent is realistic). Has anyone done any work on this front or seen any good white papers/blog posts?

Our highlevel architecture will consist of a payload being sent to a web service (WCF for instance), this will be dumped on a queue (for arguments sake) and a worker process will grab messages off this queue and proccess them. There will be a database of customer information which we'd ideally like to keep out of the cloud however there are obvious performance considerations.

Keen to hear other's thoughts.

Cheers Dave

Answer 1

I'd say that this is a pretty good match for Java Enterprise Edition. Although this means that you will be stuck with Java, at least you will then have several commercial solutions available for most of the services you describe.

Answer 2

I assume by cloud agnostic you mean agnostic to the particular platform you're running on, such as GAE, Amazon EC2 or Azure and you wish to write one, deploy anywhere.

In theory, that should be possible if all cloud providers support the same languages. As far as I know GAE supports Python and Java. Amazon EC2 can use just about anything on the actual server itself and Azure is a wholly .net platform. So the actual processing side of things i.e. writing the queue web service and processing unit(s) might be difficult.

Another barrier is that there isn't a common unified API for calling on cloud computing services. The implementations are different across GAE/Azure/EC2 anyway, so the methods their API exposes are all different and to that end, your front line code will need to know which type of API it is calling to control the cloud computing resources.

However, by nature web services are loosely coupled. Meaning provided you go to the effort to abstract the resource control so that you can create an instance on whatever cloud you want, if that new instance is yet another unit handling a web service's input / computation and the web service exposed is the same on GAE as EC2, for example, there is nothing stopping the two talking. Similarly, provided you use some form of web service / protocol between instances, you should still be able to talk to other instances over the internet across computing platforms. That said, in doing so you'd expose your internal application's data to the world at large and thus introduce a security risk.

I'd agree with disown: Java is a pretty good way to go. There are a huge number of EJB containers out there and even more web service servers like Tomcat. I'd guess EC2 supports it (well, it definitely does but whether they run Tomcat/Geromino rather than the IBM editions and what the charges are like I don't know). GAE sounds limited based on this blog post - whatever Google are doing on the backend they've engineered something very strange.

Answer 3

SOA is a perfectly fine way of abstracting the implementation of a subsystem. As long as the responsibilities of the service are clearly defined, and interoperability is prioritized, it should be theoretically possible to swap out an alternate cloud-based implementation later on. EC2 supports Windows so the Azure implementation would be highly-reusable. However, App Engine is Java/python based, meaning all that can be re-used are your messaging and RPC contracts. Therefore, a WCF implementation should be schema-first contract-first.

As far as performance is concerned, my standard approach is to

1. work with business customer to define acceptable performance,
2. implement a prototype of what you believe to be the most performance-critical aspect(s) of the system, and
3. measure performance.

If performance is unacceptable, it becomes a business decision to determine the greater risk: not being able to switch to another cloud provider, or dealing with potential performance problems. However, I would be careful to keep the performance standards realistic. For start-ups, over-emphasizing extreme performance in anticipation of growth is a waste of effort. IMO, that effort would reap greater rewards if directed toward feature-differentiation, marketing, user feedback, etc. Optimize only when necessary, and only with a plan.

By the way, I would also suggesting looking into protocol buffers as your messaging format, for greater performance at low project risk.

Answer 4

We're mostly an MS shop at this stage or at least that's the direction we're looking to take (compelling business reasons for a start-up) but are wanting to avoid any lock-in. One approach I'm looking at is having a middleware framework that abstracts away the cloud specifics. The middleware would comprise of two primary layers, the lower layer would a Cloud Adapter to abstract away the nuances and API of the specific cloud. The upper layer would provide general framework services.

The middleware would be responsible for:

• User, Credentials etc: Should provide any user information, profiles, and authorisation etc.
• Security: Should provide any security implementations and enforce any restrictions.
• Cloud Provider specifics: Instance and storage management. Measuring usage and cost of cloud usage.
• Instance services: Lower-level services within an instance e.g. CPU, memory, local storage. Provide Parallel processing implementation. Creating endpoints/ports etc.
• Abstract away access to cloud storage (e.g. tables, queues, blobs in azure).
• Configuration of application services.
• Deployment: Any specifics required for deployment to a cloud - would attempt to automate cloud-specific deployment.
• Logging: Should be a comprehensive logging framework that allows performance measurement across the cloud.

Comments welcome.