Browse Prior Art Database

Flocking Cloud Server

IP.com Disclosure Number: IPCOM000236329D
Publication Date: 2014-Apr-21
Document File: 7 page(s) / 45K

Publishing Venue

The IP.com Prior Art Database

Abstract

A look at some of the chanllanges of managing an application spread over multiple clouds and a proposal for a self managed model which will automatically handle distribution, recovery, maintenance and support of such a distributed cloud application.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 18% of the total text.

Page 01 of 7

Flocking Cloud Server

Background

In a few years time we are going to have numerous cloud service providers, and the services they provide are going to be standardised and interchangeable.  This means that applications will be written to the standard interfaces, not to platform specific rules.  This in turn opens up the possibility of applications being moved between different cloud service providers or different clouds within the same provider.

So, given a plethora of cloud service providers that are actively seeking to host your workload, how do you find the provider that best meets your current business needs?  And having done that, how do you ensure that you're still getting the best deal tomorrow?  While the cloud providers would love to lock you into long term, fixed price provisioning deals, you may be able to do a lot better on the 'spot' market - basically buying short term hosting leases and shifting your application to the cloud that's cheapest today.  As there is some complex and non-trivial work involved in moving an application from cloud to cloud, naturally you would want to automate it...

Basically you add an application management layer to the application itself, essentially making it self managing.  It needs to disperse itself over a number of different cloud service providers for resilience, locality and service optimisation.  As it is making the moves automatically, it needs a mechanism by which it can obtain hosting quotes and acquire cloud performance and descriptive data to enable it to choose the best hosting locations.  It also needs to be aware of the ownership and nationality of the systems that are offering to host it's data as there are laws concerning who it is allowed to trade with and where it is allowed to move data.  Then there is the matter of trust - some clouds may be trusted, others may not.

Self Managed Cloud Applications

In a simple implementation, the application management layer would have a list of trusted cloud and data hosts.  These are the only ones it would be allowed to use.

Each trusted cloud host would have implemented a 'Cloud Market API' which would let it provide spot quotes for cloud and data hosting services.  They would also have implemented a 'Synopsis API' that returned information about each

1


Page 02 of 7

cloud or data hubs clusters location, ownership, nationality, and recent performance.

The flock would initially be uploaded to a single cloud, chosen by a human, along with a profile of their expected workload and a set of business constraints/objectives for the flock to satisfy.  One of the systems would become the flock leader and then query the trusted service providers for quotes for its expected run time needs for the next few days.  It would use the information retrieved by the Cloud Market and Synopsis API calls to pick a set of systems that best satisfied its business goals/constraints.  It would then finalise the contracts, pay for them and begin s...