In this first part, we introduce hybrid cloud computing, then relying on Amazon Web Services we will try to provide answers to questions related to hybrid infrastructures.

Why an hybrid Cloud ?

Among the reasons to set up an hybrid Cloud, we distinguish:

• optimization of an existing structure : no need to permanently maintain a set of machines sized to support temporary peak loads
• on demand provisioning : enhance providing delays for new material ressources
• starting a backup infrastructure : in case of a Disaster Recovery Plan (DRP)

To these elements, we must add the necessity for a company to be convinced by the maturity of public Cloud. This problem of trust is one of the main obstacles (in French) to the adoption of public Cloud by companies. In this case, the idea is to make a first sketch of an hybrid infrastructure to acquire the required skills (ownership of the platform), gain insurance and trust before performing more important deployments.

Nevertheless, all the applications are not good candidates to be moved from the internal IT infrastructure to a public Cloud:

• For hardware reasons: for example case of Mainframe systems.
• For strategic reasons: data are perceived as too important to be hosted outside the company. Or the application is too critical to risk an "adhesion" against the Cloud provider.
• For financial reasons: architecture of the application relies on building blocks which are not yet available in Cloud offers - the migration would need such adaptations that it is not interesting.
• …

Thus, except small "standard" IT which may be fully migrated, hybrid cloud has interest for companies trying to test public Cloud or having to amortize a previously made infrastructure investment.

Hybrid Cloud typologies

In the rest of this article and the forthcoming ones, we define hybrid Cloud as the necessary cohabitation between an "on-premise" IT of a company A and a service proposed by a public Cloud. Moreover, we establish third party applications/services/infrastructure must be administered by company A. This make us compliant with people who think usage of public APIs like Google Maps or Twitter from an on premise IT does not constitute an hybrid cloud.

Hybrid Cloud can be declined in three models

• Outsourcing applications

• Usage of  technical services

• Outsourcing infrastructure

In addition, applications for enterprises can be segmented in three main categories according to their specificity : shared by all companies (mail, calendar, timesheets, ...), common to distinct business lines but without differentiating issues (middleware, storage services, ...) or strategical within a same activity domain (computation library, algorithm, innovating services, ...). For more information on this subject, see USI session of Julien CABOT (again in French!).

We will see that the base of the pyramid is adapted to application outsourcing whereas the top is more suitable for infrastructure outsourcing.

Application outsourcing

In this model, whole applications - not only components - are outsourced to the public Cloud. Even though the used Cloud  can be IaaS or PaaS if the company decides to keep a full control on its software, a SaaS offer is the best choice for applications common to all companies. No need of specific to insure standard functionalities like mail or room booking.

The main architectural issues are provisioning and unprovisioning of users, choice of partners according to their SLA and service propositions. In addition, we  must adress integration strategies

• at data level : must we duplicate data ? what are the possibilities to get back data from the outsourced application ?
• by services : which interconnection must we set ?
• by MMI – setting up a portal
• …

Usage of technical services

In this case, we are not dealing with whole applications but only technical components which are located on the public Cloud. Usually, we find services like CDN (Content Delivery Network), MOM (Message Oriented Middleware), storage (like S3 for example) ...

Il ne s’agit plus d’applications entières, mais uniquement de briques techniques qui sont situées sur le cloud public. On retrouve classiquement des services de CDN (content delivery network), des middlewares de type MOM, du stockage (comme S3 par exemple) …

This approach of hybrid Cloud is suitable for PaaS offers. Key points must concern latency and "adhesion" to API.

Outsourcing infrastructure

Finally, we consider running Virtual Machines outside of the on premise IT. In this case, we needto use more CPU, RAM - hardware ressource for a given timestamp.

As they are low level services, they offer the highest flexibility. Thus, they are interesting for specific and innovating applications.

Challenges are to keep control of the infrastructure (bandwidth, latency) and succeed to industrialize it (are format of disk images suitable for a later internalization ? appropriating control API, ..).

Setting up a outsource infrastructure requires studies like

• What connection between on premise IT and public CLoud infrastructure ?
• What policy must be enforced to manage VM images ?
• How to proceed for licensing ?
• What are the ways to manage Cloud plateform access ?
• Is data compression usefull ?
• Where data must be placed ?

Considering the Amazon case – Amazon Web Services - one of the main actor of IaaS, we will try to answer these questions. Some of them are adressed in the migration document edited by Amazon.

To be followed …