Network and shared resources
The network is an important feature … and in more than one way! Effectively, the Cloud configuration is already prepared for you, and that’s convenient. But that also means that you don’t control it, and consequently you cannot monitor it yourself and therefore diagnose, for example, the causes of a slow-down. There is a similar lack of transparency concerning the shared resources at Cloud: at our level it is impossible to estimate the impact of other people using the resource we are sharing (such as the physical computer on top of which is based our EC2 instance, the physical device we use as an EBS network-attached device, the network bandwidth, etc.). The only network monitoring possible is limited to input/output on the instance (for example, an EBS is a network-attached device, so … there is no means of verifying the connectivity conditions, you will have to do with the I/O disks). The monitoring you can do is concentrated on the EC2 virtual instance itself (the instance is managed by a hypervisor and based on a Xen virtualization). Total visibility of our infrastructure is therefore not possible on Cloud. This must be taken into account… and accepted, if you wish to implement your architecture on Cloud. You must also weigh up the same lack of transparency for other shared resources as previously mentioned (EBS use, etc.).

AWS : Isolation of the EC2 Instance (from aws.amazon.com)

Likewise, a multicast is not possible when it comes to communication protocols: bear that in mind for certain clusters. This constraint is understandable, given the far-reaching impact that a mismanaged multicast can have.

That is due to Cloud’s own way of operating: it has easy ways which mask a certain number of elements you no longer control.

On-call support, monitoring, BCP (Business Continuity Planning) and penalties
One question I’ve been asked frequently is “Does Amazon provide on-call support (regarding your own application/infrastructure your are running on top of the AWS) ?” The answer is no. AWS must be seen as a set of tools offered by Amazon which ensures that these tools are always up and well working. They maintain these tools and the development of their various functions. However, you are responsible for your use of the tools (in any case they do not possess the private keys of your EC2 instances…), so there is no monitoring / on-call support / BCP (Business Continuity Planning) package.

Unlike the specific contracts you may sign with your hosting providers, you must provide for these elements yourself, or regarding on-call support for example, you could out-source it to a facilities management company. Ditto for monitoring: Amazon offers Amazon CloudWatch, but the information (% of CPU, read/written bytes onto disk and in/out bytes on the network) is too brief for genuine monitoring as provided by Centreon/Nagios, Cacti, Zabbix or Munin. The CloudWatch information is used by the Auto Scaling function, but does not replace true monitoring. Some traditional hosting providers offer packaged monitoring with their services.

AWS CloudWatch

As far as the BCP and penalties are concerned, it amounts to being internally hosted: you are responsible for your resources and you manage failure / disaster recovery in line with the tool’s capacities (the AWS). This is where it’s important to understand the global nature of the architecture of Amazon services: if you don’t understand how the tool works, you will not be able to implement an effective BCP. As for penalties, there’s nothing unusual: it simply means a smaller bill for the month when you come under the ‘Service unavailable’ category as defined by Amazon criteria. This has nothing to do with the penalties based on the amounts lost due to unavailability.

It is imperative to consider Amazon web services as a tool. In spite of it being an accessible AWS support (that you can call for tools’ level questions and issues) that you can pay for, you will not get the full contractual potential you would have with a more traditional hosting provider, and broadly speaking, you will be responsible for your architecture on all levels (including the security of your instances: don’t lose your keys! ;ob).

Security
Security…  frequently a taboo topic, as soon as we start talking about Cloud computing. I don’t mean the integrity of stored data or even access management on the virtual instances we are responsible for, I’m talking about the confidentiality of the stored data on the different services (S3, EBS, EC2, SQS, etc.) or data which transit between those services.

The first key point is that the level of security supplied in Amazon datacenters, not just physically but – equally importantly – in programmatically terms, will still be streets ahead of your average corporate computer room, even the datacenters of the smallest hosting providers. Firstly because that is Amazon’s business: a security problem revealed in their infrastructure would have immediate implications in terms of user reactions (and thus in terms of business ;ob). It is therefore an essential detail, especially as Amazon have to prove themselves in this sensitive area and they are therefore obliged to do their best to win their customers over. Furthermore, the sheer size of their structure enables them to pool their investments in security and make them pay for themselves: this is not conceivable for the smallest companies, or companies who do not specialize therein. Amazon therefore has the means and the obligation to ensure security.

What provokes my scepticism is that Cloud is not easily audited. You have to have faith. It is no more risky than placing your trust in a traditional hosting provider, or in your own internal teams… But it’s brand new! So be careful! A normal reaction. But perhaps this is exactly an opportunity for us to work on security at our own level, something often neglected, due to over-confidence or lack of interest. The first task is to encrypt the information: for stored data as well as data in transit. Remember to take into account the CPU overhead encryption/decryption procedures. The second is to fully understand the various security mechanisms of Amazon’s services:

AWS Multi-Factor Authentication

• Access Credentials: Access Keys, X.509 Certificates & Key Pairs
• Sign-In Credentials: E-mail Address, Password & AWS Multi-Factor Authentication Device
• Account Identifiers: AWS Account ID & Canonical User ID

Next you must select the people who’ll be authorized to access the different security keys.

Conclusion
The facilities provided by Cloud Computing inevitably come with some measure of reduced control and visibility on certain parts of the infrastructure, especially on the network. That’s the price you pay, be it quite negligible, or truly problematic: it all depends on your requirements.

AWS should be viewed as a complete tool, but one which does not excuse you from performing all the best practices or obtaining all the standard components of an infrastructure: log server, monitoring, BCP, configuration manager, etc. All these elements are and will continue to be your responsibility. One mustn’t have too naïve an expectation: as AWS offers HaaS and IaaS, you will still need a competent systems administrator, and particularly one who fully understands the AWS architecture (otherwise you might be disappointed) – if you switch to GAE (Google App Engine), you will still need an architect who fully understands GAE architecture, etc. The business is constantly evolving.

As for AWS security, I am reasonably confident. It must be emphasized firstly that information and data are probably less secure within your own company than entrusted to Amazon (in most cases anyway – I shouldn’t generalize ;ob).  AWS’ exposure on the Net and Amazon’s commitment to the business imply that Amazon take security very seriously. Furthermore, you are responsible for a large part of this security (management of the keys, etc.) and believe me, that is surely the most risky feature. When it comes to transferring and storing data, think “encryption”.

Frédéric FAURE @Twitter @Ysance

One year already!
Firstly allow me to direct you to a previous article I wrote on this subject nearly a year ago: Outlook is Cloudy … So much the better! (French version). I won’t paraphrase what I have already explained, purely in the spirit of DRY (Don’t Repeat Yourself :o))  and I will capitalize on the experience I have gained in this topic over the past year (Cloud Computing in general and AWS – Amazon Web Services – in particular), to answer some legitimate questions I have encountered since then.

The Framework

Cloud
As a reminder, there are several types of Cloud possibilities and I will stick with the AWS types which are infrastructure-oriented services, rather than the Google-type services (GAE – Google App Engine), to mention just one, which offers a running environment for your web applications developed with the APIs provided (similar to a framework). In fact, regarding the latter, we can’t speak for clients (they are the ones holding the credit card) about infrastructure management, because we upload our application using the APIs provided and leave the entire infrastructure management to the service provider. It doesn’t mean it’s less about Cloud computing, but simply about a Cloud service that’s more PaaS-oriented than infrastructure-oriented.

Several abstraction layers: each editor directs its service to one or more layers.

Physical infrastructure
As far as physical infrastructure is concerned, I will examine the notion of self-hosted infrastructure and equally the notion of infrastructure supported by a hosting provider. Similarly, I’ll also look at infrastructures based directly on hardware, as well as those based on virtualized environments. Cloud computing is also based on virtualization, but we are not so interested in that technology here, rather the way in which it is provided to clients (you). In fact, you can simply start up instances via a console, as you do for EC2s if you have an ESX (VMware) for example, but it involves “only” a hypervisor which partitions the physical servers into several virtual computers. You will still have to take care of buying equipment (blades, etc.), configuring the network, etc. But we will come back to these details later.

Cloud computing = Systems administrators marked down?
Yes, the sales are on! Are you looking for a sweater, a jacket, … a systems administrator? I have often come across people who think that Cloud (in the case of AWS) will enable them to get by without an experienced systems administrator, and to build an infrastructure with inferior competence. The answer is obvious: WRONG!

Perhaps a clever sales pitch can convince you that the various services are so user-friendly, you can do it all yourself, and that prepackaged AMIs (Amazon Machine Image) will make life easy, but it goes without saying that once you have started up the EC2 instances, you connect to the computers (SSH / port 22 for Linux and TSE / port 3389 for Windows), then you have to set the parameters, do the fine-tuning, etc.

What applies to systems administrators faced with AWS applies equally to systems architects in the context of Cloud computing services providing access to higher layers (PaaS like Google App Engine). A person with experience in the field, able to set up the infrastructure requirement is needed: the tool may change but the skills must still be available. Note however that if you use GAEs, you don’t need a systems administrator for the application. If the Cloud service editor is offering a service in a given layer (HaaS, IaaS, PaaS, etc.), there is no longer any need for people to deal with the lower layers. However, we do accept the framework supplied by the Cloud editor.

The systems administrator cannot be done away with, but his role is changing: he is becoming more and more of a developer. Indeed, being able to pull up resources on the fly will enable infrastructure management to be scheduled and automated via scripts which will call up the APIs provided by Amazon enabling communication with its web services. Everything at Amazon is web service: EC2, EBS, SQS, S3, SimpleDB: the only non-SOAP or REST operations that exist are when you connect directly to EC2 instances that you called up via web service or when EC2 instances dialogue with the EBS that you called up via … I’ll let you guess.

The administrator can then, rather than going into the computer room, add a disk, connect a server (which would be the case with a physical architecture) or else pick up the phone and ask the host to do it (fetch a coffee… call again… take a Xanax or a Prozac pill…  ;ob), request resources via a script in Ruby or Python… You can then take automation of a Cloud infrastructure much, much further, with a set of scripts and tools (see Installing an infrastructure on AWS: Best practices! (French version)).

The systems administrator’s craft is therefore evolving between a physical infrastructure and an AWS-type Cloud infrastructure: he is becoming more and more of a developer. But the systems administrator remains essential nevertheless.

Elastic is fantastic!
As I mentioned earlier, one of the crucial differences between the two types of infrastructure is the flexibility and dynamism provided by the Cloud solution, compared to a traditional physical architecture (whether it is based on virtualization or not). That means the elimination of the time it takes to install and set up the logistics (equipment purchase, installation of the OS, connecting to the network – the physical network and the configuration of the interfaces, etc.). Likewise, when you no longer need an item of hardware (EC2 virtual instance, EBS volume, S3 object, etc.), you return it to the resource pool: it will be reinitialized so that none of your data can be retrieved, and made available again until the next web service call.

You also have complete access to certain elements such as security groups (firewall) set for each instance… And that’s very useful. It’s very practical, particularly compared to a traditional hosting provider: do you remember the last time you had to change the firewall rules?  Would you like a Xanax? Are you sure?  ;ob

But it’s not simply about the pros and cons of purchasing servers versus running instances. AWS are backed by datacenters which are already industrially organized and tested. All the safety standards that need to be met in terms of fire protection, computer cooling, redundant electrical power supply, physical security against break-ins, distributing the hardware across 2 or more physical datacenters for disaster recovery, etc. entail a colossal initial investment and even when everything is installed, you still won’t be able to recreate the same quality within your company (99% of the time, in any case). You can get all that however, or part of it, with a traditional hosting provider.

But there are also all the more software-like services, such as data durability management (redundancy/replication as on the EBS and on S3), accessibility or high availability, monitoring hardware (to be alerted when physical components are showing signs of weakening), procedures for breakdowns, etc. I will let you read The 9 Principles of S3 (French version), so you understand just how many concepts are included. You won’t get all that with a traditional hosting provider (and forget about having it @Home ;ob). The quality of the S3 service is effectively a huge advantage, especially compared to current pricing… Let’s talk about prices!

The cost
There are no fixed rules. With Cloud, you pay for the resource by the hour and when you stop using it, you stop paying. Instances (Linux at the time I’am writing the article, but Windows will come soon) can also be reserved on the AWS for one year or for three years: this is known as Reserved Instances: you pay a one-time fee at the start, and afterwards you pay the hourly usage charge at a discounted rate, which leads you to a tipping point starting from a certain percentage of the resource use over the year (or three years). For more information, click here. To easily calculate how much your infrastructure will cost you, take advantage of the new calculator provided by Amazon: Simple Monthly Calculator. In all cases one part is related to the hourly usage and another to your traffic/volume stored.

Simple Monthly Calculator

You can do the comparison with the cost of your local infrastructure or with that of your hosting provider. The Cloud set price is particularly attractive in the following cases:

• The set price is unbeatable for POCs, demonstrations/presentations or architecture load/validation tests.
• It is very attractive for applications or APIs mounted on an SaaS-type economic model and for which you need to spend money on their resources only when the clients pay to use the abovementioned APIs.
• It is a good price for the social applications found on Facebook, for example, and which can take off overnight thanks to the social media phenomenon and may experience a boom (or a drop) in hits.
• It is also cost-effective when you are launching a new company, or a specific project within a larger entity and you do not wish to invest heavily in logistics right at the start.

For all the many other specific cases among you, you’ll have to do your own calculations.

Slacking off? No, of course not …
Usually, no matter what type of infrastructure you have, the same components and mechanisms should be installed. However, it must be acknowledged that often the cosy aspects of “home”-hosted infrastructure can lead to a certain lack of rigor on many issues. The fact that Amazon, with its AWS, offers a dynamic and volatile solution for these EC2s, compels you to install mechanisms (which should be standard) in order to consider failure or disaster recovery plans more seriously, given the volatile nature of the tool, and to identify the important data with the aim of ensuring data durability (EBS, S3 backups, etc).

Conclusion
The evolving duties of infrastructure management can be clearly seen in this first part: from handling physical resources by means of APIs, underlying mechanisms ensuring data durability, availability of services, etc. right up to server power supply and the physical security of datacenters, all of which are supported transparently. The end result: one should “only” see the API which dialogs with a distant server. That is the difference with physical infrastructures. The virtualization (which is one facet of AWS) that we know and have already been using for some time now, is used by Amazon: it’s not so much a technical revolution  - even though I don’t deny the complexity of the implementation and support that goes into it – as the service offered with it, which provides the real added value.  It is matched with a new ‘pay-as-you-use’ aaS (as a Service) economic model. This has enabled the emergence of some applications (such as the games found on social networks), which only a few years ago would otherwise have been compromised by the initial investment.

We will examine the other aspects differentiating these architectures in my second article on the subject.

Frédéric FAURE @Twitter @Ysance

Réseau et ressources partagées

Un point important que le réseau… Et à plus d’un titre ! Effectivement, la configuration sur le Cloud est déjà prête, c’est commode. Mais cela implique que vous n’ayez pas la main dessus et par conséquent vous ne pourrez pas le monitorer vous même et donc déceler, par exemple, les causes d’un ralentissement. On note la même opacité en ce qui concerne les ressources partagées au niveau Cloud : il n’est pas possible de définir à notre niveau l’impact que peut avoir l’utilisation par d’autres personnes de la ressource que nous partageons (machine physique sur laquelle repose un EC2, partition d’un disque réseau EBS, bande passante réseau, …). Le monitoring réseau possible se limite en entrée/sortie de l’instance (par exemple un EBS est un disque réseau donc… pas moyen de vérifier l’état de la connectivité, on se contentera des Disk I/O). Le monitoring possible est concentré sur l’instance virtuelle EC2 elle-même (instance gérée par un hyperviseur et reposant sur une virtualisation Xen). La visibilité complète de notre infrastructure n’est donc pas possible au niveau Cloud. Cela est à prendre en compte… Et à accepter si vous souhaitez implémenter votre architecture sur le Cloud. La même opacité est à prendre en compte pour les autres ressources partagées comme citées précédemment (utilisation EBS, …).

AWS : Isolation des Instance EC2 (from aws.amazon.com)

De même, au niveau des protocoles de communication, il n y’a pas de multicast possible, pensez-y dans le cas de certains clusters. C’est une limitation qui se comprend du fait de la portée que peut avoir un multicast mal maitrisé.

C’est le fonctionnement même du Cloud qui veut ça : il y a des facilités qui masquent un certain nombre d’éléments dont vous n’avez plus le contrôle.

Astreintes, monitoring, PRA et pénalités
Une question qui m’a été posée plusieurs fois : « Amazon prend-il en charge des astreintes ? ». La réponse est non. Il faut voir les AWS comme un outil proposé par Amazon qui en assure le fonctionnement et l’évolution des fonctionnalités. En revanche, l’utilisation que vous en faite est à votre charge (de toute façon ils ne possèdent pas les clés privées de vos instances EC2, alors…) : pas monitoring, pas d’astreinte, pas de PRA (Plan de Reprise d’Activité) packagés.

Contrairement aux contrats spécifiques que vous pourrez passer avec vos hébergeurs, il faudra assumer vous même ces éléments, ou, pour des astreintes par exemple, les dédier à des sociétés faisant de l’infogérance. Pour le monitoring idem : le monitoring proposé par Amazon, Amazon CloudWatch, propose des informations (%CPU, bytes read/written sur disque et bytes in/out sur réseau) trop succinctes pour un réel monitoring tel que le ferait un Centreon/Nagios, Cacti, Zabbix ou Munin. Ces informations (celles de CloudWatch) sont utilisées par la fonctionnalité Auto Scaling, mais ne remplacent pas un vrai monitoring. Certains hébergeurs classiques proposent du monitoring intégré à leur prestation.

AWS CloudWatch

Concernant le PRA et les pénalités, cela revient à un hébergement en interne : vous êtes responsables de vos ressources et gérez les reprises sur incident en fonction des possibilités de l’outil (les AWS). C’est là qu’il est important de comprendre l’architecture des services Amazon dans leur globalité : si vous ne comprenez pas le fonctionnement de l’outil, vous ne pourrez mettre en place un PRA efficace. Concernant, les pénalités, rien de notable, il s’agit d’un allégement sur la facture du mois quand vous rentrez dans le cadre de l’indisponibilité du service selon les critères Amazon. Rien à voir avec des pénalités basées sur les montants perdus dûs à l’indisponibilité.

Il faut voir les services web Amazon comme un outil. Malgré, un support payant accessible, vous n’aurez pas les possibilités contractuelles que vous pourriez avoir avec un hébergeur plus classique et, de manière générale, serez responsable de votre architecture à tous points de vue (y compris au niveau de la sécurité de vos instances : ne perdez pas vos clés ! ;ob).

La sécurité
La sécurité… Un point souvent tabou dès que l’on commence à parler de Cloud Computing. Je ne parle pas de l’intégrité des données stockées ou bien de la gestion des accès sur les instances virtuelles à notre charge, je parle de la confidentialité des données stockées sur les différents services (S3, EBS, EC2, SQS, …) ou qui transitent entre lesdits services.

Tout d’abord, le premier point à noter est que le niveau de sécurité dans les datacenters d’Amazon, que ce soit physiquement ou bien informatiquement parlant, sera de toute façon meilleure que dans bons nombres de salles machines d’entreprises, voire de datacenters d’hébergeurs plus petits. Tout d’abord parce que c’est leur fond de commerce : un problème de sécurité dévoilé sur leur infrastructure aurait des implications immédiates en termes de « ressenti utilisateur » (et donc de business ;ob). C’est donc un point essentiel, surtout qu’ils ont tout à prouver dans ce domaine sensible, ils sont donc obligés de faire le maximum pour convaincre. En plus, l’importance de la taille de leur structure leur permet de mutualiser et de rentabiliser les coûts investis dans ce domaine, ce qui n’est pas envisageable pour de plus petites entreprises, ou des entreprises dont ce n’est pas le métier. Amazon a donc la possibilité et l’obligation de se soucier de la sécurité.

Ce qui amène ce scepticisme, c’est que le Cloud est difficilement auditable. Il faut faire confiance. Ce n’est pas plus risqué que de faire confiance à un hébergeur classique ou bien de faire confiance à ses équipes en interne… Mais c’est nouveau ! Alors méfiance ! C’est une réaction normale. Mais c’est peut-être l’occasion de travailler justement sur la sécurité au niveau sur lequel nous avons la main, chose qui est parfois laissé de côté par excès de confiance ou désintéressement. La première chose est de crypter les informations, autant celles stockées que celles qui transitent. Attention à prendre en compte le surcoût CPU des traitements liés au cryptage/décryptage. La seconde est de bien comprendre les différents mécanismes de sécurité des services Amazon :

AWS Multi-Factor Authentication

• Access Credentials: Access Keys, X.509 Certificates & Key Pairs
• Sign-In Credentials: E-mail Address, Password & AWS Multi-Factor Authentication Device
• Account Identifiers: AWS Account ID & Canonical User ID

Il faut ensuite identifier les personnes qui pourront avoir accès aux différentes clés de sécurité.

Conclusion
Les facilités apportées par le Cloud Computing sont obligatoirement accompagnées d’une maitrise et d’une visibilité moindres sur certaines parties de l’infrastructure, surtout au niveau réseau. C’est le prix à payer qui peut être tout à fait négligeable ou réellement problématique : tout dépend de vos besoins.

Il faut voir les AWS comme un outil complet, mais qui ne vous exemptera pas de toutes les bonnes pratiques et de tous les composants standards d’une infrastructure : serveur de logs, monitoring, PRA, gestionnaire de configuration, … Tous ces éléments sont et resteront à votre charge. Il ne faut pas avoir une vision trop naïve : les AWS proposant des services HaaS (Hardware as a Service) et IaaS (Infrastructure as a Service), vous aurez toujours besoin d’un administrateur système compétent et surtout qui aura bien compris l’architecture des AWS (ou vous risquez d’aller vers des déconvenues), si vous passez à GAE (Google App Engine), vous aurez toujours besoin d’un architecte qui aura bien compris l’architecture des GAE, … Le métier évolue.

Concernant la sécurité, je suis plutôt confiant. Il faut souligner d’abord que les informations sont probablement moins sécurisées chez vous que chez Amazon (enfin bien souvent, pas de généralités ;ob). L’exposition des AWS sur le Net et l’engagement d’Amazon dans ce business impliquent qu’Amazon prenne ce sujet très au sérieux. De plus, vous êtes responsables d’une bonne partie de cette sécurité (gestion des clés, …) et, croyez moi, c’est sûrement le point qui sera le plus risqué. Concernant le transfert et le stockage des données, pensez chiffrement.

Frédéric FAURE

Déjà un an
Je me permets tout d’abord de vous orientez vers un précédent article que j’ai écrit il y a maintenant près d’un an sur le sujet : Un avenir nuageux… Et c’est tant mieux !. Je ne paraphraserai pas ce que j’ai déjà expliqué précédemment dans une optique purement DRY (Don’t Repeat Yourself :o)) et profiterai de cette année d’expérience supplémentaire sur le sujet (le Cloud Computing en général et AWS – Amazon Web Services – en particulier) pour répondre aux interrogations légitimes que j’ai croisées depuis.

Le cadre
Le Cloud
Pour rappel, il y a plusieurs types d’offres au niveau du Cloud et je vais m’attacher à celles de type AWS qui sont des offres orientées infrastructures plutôt que des offres de type Google (GAE ou Google App Engine), pour ne citer que lui, qui propose un environnement d’exécution pour vos applications web développées avec les APIs mises à disposition (un framework en quelque sorte). En effet, dans le dernier cas, on ne peut pas parler au niveau client (nous qui mettons la carte bleue) de gestion d’infrastructure puisque nous uploadons notre application utilisant les APIs fournies et laissons l’intégralité de la gestion de l’infrastructure au fournisseur du service. Il ne s’agit pas moins de Cloud Computing, mais simplement d’une offre de Cloud orientée « PaaS » plutôt que infrastructure.

Plusieurs couches de virtualisation : chaque éditeur oriente son offre vers une ou plusieurs couches.

L’infrastructure physique
Concernant l’infrastructure physique, je considère autant l’infrastructure hébergée soi-même que celle prise en charge chez un hébergeur spécialisé. De même, je considère autant les infrastructures reposant directement sur l’OS de la machine que celles reposant sur des environnements virtualisés. Le Cloud repose également sur de la virtualisation, mais ce n’est pas la technologie qui nous intéresse ici, mais la manière de la mettre à disposition des clients (vous). En effet, vous pourrez démarrer simplement des instances via une console, comme pour les EC2, si vous avez un ESX (VMware) par exemple, mais il s’agit « uniquement » d’un hyperviseur qui partitionne les serveurs physiques en plusieurs machines virtuelles. Vous aurez donc toujours les problématiques d’achat de matériel (lames, …), de configuration du réseau, … Mais nous entrerons dans ces détails plus tard.

Le Cloud Computing = Administrateurs Systèmes en solde ?
Et oui, c’est la période des soldes ! Un pull, une veste, … Un administrateur système ? Plusieurs fois, j’ai croisé des gens pensant que le Cloud (dans le cas des AWS) allait permettre de se passer d’administrateurs systèmes expérimentés et de pouvoir monter une infrastructure avec des connaissances moindre. La réponse est claire : C’est complètement faux !

Peut-être qu’un discours commercial mettant en avant la facilité d’utilisation des différents services laisse envisager cette éventualité et que des AMIs (Amazon Machine Image) déjà prépackagées vont nous faciliter la vie, mais il n’en reste pas moins que une fois les instances EC2 démarrées, vous vous connectez aux machines (SSH / port 22 pour Linux et TSE / port 3389 pour Windows) et vous devez les paramétrer, les tuner, …

Ce qui est vrai pour l’administrateur système dans le cadre des AWS est aussi vrai pour les architectes dans le cadre de services de Cloud Computing proposant l’accès à des couches plus hautes ( « PaaS » comme Google App Engine, …). Il y a besoin d’une personne connaissant le métier et pouvant mettre en place le besoin en termes d’infrastructure : l’outil change, mais les compétences doivent toujours être là. A noter tout de même que si on utilise les GAE, il ne sera pas nécessaire d’avoir un administrateur système pour l’application elle-même. Si l’éditeur de service Cloud propose un service dans une couche donnée (HaaS, IaaS, PaaS, …), il n’y a plus besoin des personnes s’occupant des couches inférieures. Cependant, on accepte le cadre fournit par l’éditeur de Cloud.

L’administrateur système reste incontournable, mais il évolue : il devient de plus en plus un développeur. En effet, la possibilité de lever des ressources à la volée va permettre d’ordonnancer, d’automatiser, la gestion de l’infrastructure via des scripts qui feront appel aux APIs mises à disposition par Amazon permettant de communiquer avec ses services web. Tout est service web chez Amazon : EC2, EBS, SQS, S3, SimpleDB, …), les seules opérations non SOAP ou REST est lorsque vous vous connectez directement aux instances EC2 que vous avez levées via service web ou que les instances EC2 dialoguent avec les EBS que vous avez levés via… Je vous laisse deviner.

L’administrateur peut alors, plutôt que d’aller en salle machine, ajouter un disque, brancher un serveur, … (ce qui serait le cas dans une architecture physique) ou bien prendre le téléphone et demander à l’hébergeur de le faire (prendre un café… Appeler de nouveau… Prendre un Xanax ou un Prozac… ;ob), demander l’obtention de ressources via un script en Ruby, Python, … Il est ensuite possible de pousser beaucoup plus loin l’automatisation d’une infrastructure Cloud via un ensemble de scripts et d’outils (Cf. Mise en place d’une infrastructure sur AWS : best practices !).

Le métier de l’administrateur système évolue donc entre une infrastructure physique et une infrastructure Cloud type AWS : il devient de plus en plus un développeur. Mais il n’en reste pas moins indispensable.

L’Elastic c’est fantastique !
Comme évoqué précédemment, une des différences cruciales entre les 2 types d’infrastructures, c’est la souplesse et le dynamisme apporté par la solution Cloud par rapport à une architecture physique classique (qu’elle repose sur de la virtualisation ou non). C’est à dire la suppression du temps de mise en place de la logistique (achat de matériel, installation de l’OS, raccordement au réseau – physique et configuration des interfaces -, …). De même, quand vous n’avez plus besoin du matériel (instance virtuelle EC2, volume EBS, objet S3, …), vous le rendez au pool de ressources : il est alors réinitialisé afin qu’aucune de vos données ne puissent être récupérées et remis à disposition en attendant un autre appel web service.

Vous avez également un accès total à certains éléments comme les security groups (firewall) appliqués pour chaque machine, … Et c’est très utile. Cela est très pratique, notamment par rapport à un hébergeur classique : rappelez-vous la dernière fois que vous avez dû faire modifier les règles de firewall… Un petit Xanax ? Sûr ? ;ob

Mais il ne faut pas s’arrêter simplement à la notion d’achat de serveurs Vs démarrage d’instances. Derrière AWS, il y a des datacenters déjà montés et éprouvés de manière industrielle. Toutes les normes à respecter en terme de protection contre les incendies, le refroidissement des machines, les alimentations électriques redondantes, la sécurité physique contre les intrusions, la répartition des locaux physiques, … comportent un prix initial colossale et même une fois mises en place, vous ne pourrez reproduire une telle qualité chez vous (en tout cas dans 99% des cas). Vous pourrez cependant retrouver cela pour tout ou partie chez un hébergeur classique.

Mais il y a de plus tous les services plus « logiciels » comme la gestion de la durabilité des données (redondance/réplication comme sur les EBS et sur S3), l’accessibilité ou haute disponibilité, le monitoring hardware (à savoir quand est-ce que les composants physiques montrent des signes de faiblesse), les processus en cas de panne, … Je vous laisse lire Les 9 principes de S3, pour comprendre l’exhaustivité des notions que cela regroupe. Tout cela, vous ne le retrouvez pas chez un hébergeur classique (et oubliez cela chez vous ;ob). La qualité du service est en effet un plus incomparable, surtout par rapport aux prix pratiqués… Les prix parlons-en !

Les coûts
Il n’y a pas de règle figée. Au niveau Cloud, vous payez la ressource à l’heure et lorsque vous la relâchez, vous ne payez plus. Il y a également la possibilité de réserver des instances (Linux pour l’instant) sur les AWS à l’année ou pour 3 ans, c’est ce que l’on appelle les Reserved Instances : vous payez un forfait tout de suite et ensuite vous payez le coût horaire moins cher, ce qui vous amène à une bascule à partir d’un certain pourcentage d’utilisation de la ressource sur l’année (ou les 3 ans). Pour plus de détails, allez ici. Pour un calcul simple de combien vous coûtera votre infrastructure, profitez de la toute nouvelle calculatrice mise à disposition par Amazon, le Simple Monthly Calculator. Dans tous les cas il y a une par liée à l’utilisation horaire et une autre liée au trafic.

Simple Monthly Calculator

Vous pouvez effectuer la comparaison avec le coût de votre infrastructure locale ou bien avec ce que vous coûte votre hébergeur. La formule Cloud est notablement intéressante dans ces cas là :

• La formule est imbattable pour les POCs, les démonstrations/présentations ou bien les tests de charge/validation d’une architecture.
• Elle est très intéressante pour les applications ou APIs montées elles mêmes sur un modèle économique de type SaaS et qui ne nécessitent de dépenser de l’argent pour leurs ressources qu’à partir du moment où des clients paient pour utiliser lesdites APIs.
• Elle est intéressante pour les applications sociales que l’on trouve sur FaceBook, par exemple, et qui peuvent connaître un succès du jour au lendemain en profitant de phénomènes de viralité et voir leur fréquentation exploser (ou baisser).
• Elle est intéressante également lorsque l’on lance une société ou que l’on débute une activité ou un projet spécifique au sein d’une entité plus importante et que l’on ne souhaite pas un fort investissement immédiat dans la logistique.

Il vous faut pour les nombreux autres cas propres à chacun, faire votre calcul personnel.

Laxisme ? Mais noooooooon…
Normalement, quelque soit le type d’infrastructure, les mêmes composants/mécanismes devraient être mis en place. Cependant, force est de constater que bien souvent le côté plus douillet de l’infrastructure hébergé « à la maison » pousse à une certaine forme de laxisme sur un certain nombre de points. Le fait que Amazon, avec ses AWS, propose une solution volatile et dynamique au niveau de ces EC2 oblige à mettre en place des mécanismes (qui devraient être standards) afin de prendre en compte plus sérieusement, du fait de la volatilité de l’outil, les plans de reprise sur incident et identifier les données importantes afin d’assurer leur durabilité (EBS, backups sur S3, …).

Conclusion
On perçoit dans cette première partie l’évolution du métier de responsable d’infrastructure : la manipulation des ressources physiques se fait par le biais d’APIs, les mécanismes sous-jacents assurant la durabilité des données, la disponibilité des services, … jusqu’à l’alimentation électrique des serveurs et la sécurité physique des datacenters sont pris en charge de manière transparente. Au final, on ne voit « plus que » l’API qui dialogue avec un service distant. C’est là qu’est la différence avec les infrastructures physiques. La virtualisation (qui est une des facettes des AWS), que nous connaissons et utilisons déjà depuis quelques temps maintenant, est utilisée par Amazon : ce n’est pas tant une révolution technique, même si je ne doute pas de la complexité de mise en oeuvre derrière, c’est surtout le service offert qui est la vraie valeur ajoutée. Cela est accompagné d’un nouveau modèle économique aaS (as a Service) qui nous fait payer à l’utilisation. Cela permet à des applications (par exemple de type jeux que l’on retrouve sur les réseaux sociaux) de voir le jour, alors qu’il y a quelques années, leur émergence aurait été compromise par l’investissement initial.

Nous verrons les autres aspects différenciant ces architectures dans un second article sur le sujet.

Frédéric FAURE

Le Cloud Computing vu par Amazon est promis à un bel avenir. Il s’inscrit en effet dans la démarche en vogue de restructuration des infrastructures et de réduction des coûts. Il rejoint de plus le modèle économique SaaS par ce que l’on pourrait appeler le modèle HaaS (Hardware as a Service). Ce modèle économique s’inscrit dans l’évolution naturelle des architectures vers les SOA (Services Oriented Architecture) et répond aux besoins des consommateurs.

Version IPhone
Version IPod

Quelques précisions concernant des questions qui m’ont été posées :

Le SLA
Chaque service a son propre SLA qu’il faut bien lire, par exemple pour EC2 le SLA est de 99,95% par région sur une année glissante. Ce que Amazon entend par service inaccessible est que vos instances n’ont plus d’accès externe pendant une période de 5 min et que vous êtes incapables d’en relancer. Cela doit se produire sur plus d’une zone d’accessibilté (donc au moins 2) dans laquelle vous avez des instances. Cela veut donc dire que Amazon part déjà du principe que vous avez redondé votre infrastructure sur 2 zones afin de faire de la haute disponibilité.
Il faut donc bien lire et comprendre les termes du SLA par rapport à l’infrastructure Amazon.
Dans la pratique, je travaille sur une infrastructure non redondée exclusivement sur une zone d’accessibilité et sur 8 mois d’utilisation, je n’ai rencontré un problème d’accessibilité de quelques minutes qu’une seule fois. Je n’ai rien à redire sur le service.

La durabilité d’EBS, EBS/S3 et la fiabilité en général
La durabilité des EBS est assurée par réplication réseau dans une zone d’accessibilité donnée (cela ne sert donc à rien de monter plusieurs EBS dans une zone donnée et de dupliquer les données ;ob Amazon le fait déjà !). Selon Amazon, cela donne une fiabilité de 10 fois supérieure à celle d’un disque standard dans un data center. Il est vrai que je n’ai pas rencontré de problème sur 8 mois d’utilisation avec un parc d’environ 25 EBS.

Par rapport à S3, la différence est que S3 accroit la durabilité, donc faire un backup de vos EBS par snapshot ou bien en effectuant un dump des données est une très bonne pratique de backup. Aucun problème rencontré avec S3 à ce jour pour ma part. Deux différences entre EBS et S3 : la portée, régionale pour S3 et dans la zone d’accessibilité pour l’EBS, et la capacité en I/O optimisée pour l’EBS. Chaque outil de stockage a son rôle !

Sur une quarantaine d’EC2, j’ai perdu 3 instances en 8 mois. Mais comme aucune donnée sensible n’est stockée dessus et que l’infrastructure est automatisée (Cf. Puppet et Capistrano : la clé de l’automatisation), l’intégration d’une nouvelle instance, entre la survenue du problème, la détection, la réparation et la reconfiguration des outils de monitoring/backup, n’a pas excédé une heure. La remise en ligne, elle-même, d’une nouvelle instance (réparation) n’a pris que 10 min !

Pour plus d’info, n’hésitez pas à consulter les article précédents sur le sujet et notamment Conception d’une infrastructure sur AWS : best practices !.

MapReduce… QUID ?
Qu’est ce donc ? Je compare ça à un ETL puisque le but de la manipulation est de partir d’une source de données, un fichier de logs par exemple, d’extraire les éléments que nous souhaitons traiter (fonction de mapping) et de les transformer (fonction de réduction) avant de les remettre à diposition sous forme d’un fichier et de les charger sur S3. Ce qu’il faut, c’est écrire ces fonctions de map et de reduce à appliquer sur vos fichiers pour obtenir ce que vous voulez en sortie (des statistiques par exemple). Pour plus d’infos, MapReduce

Comment calculer l’utilisation de son application avec DevPay ?
C’est Amazon qui s’occupe de calculer l’utilisation, vous avez juste à définir le coût fixe (one-shot ou mensuel) et le coût variable lié à l’utilisation (trafic, …). Et bien sûr mettre à disposition votre application ou votre AMI ! ;ob

Mechanical Turk, comment ça marche ?
Pour ça je vous invite à regarder le site d’Amazon, rubrique Mechanical Turk, qui explique très bien le concept. Mais dans les grandes lignes des personnes souhaitant effectuer ces tâches (tagging d’images, reconnaissance video, transcription de podcast, traduction, enquêtes d’opinion, dédoublonage catalogue produits online, …) se connectent sur le site d’Amazon, sélectionnent et effectuent les tâches que vous avez proposées via l’API web service d’Amazon intégrée dans votre application. L’intégration de la réponse peut être automatique, ou soumise à validation. La validation peut être effectuée sur plusieurs résultats identiques pour une même tâche distribuée à plusieurs personnes et le paiement découle de votre acceptation ou non du travail résultant en fonction de sa qualité. La personne ayant effectué le travail voit donc ses statistiques d’acceptation de travail évoluer et donc obtient un indicateur de compétences.

Frédéric FAURE

Différence avec une infrastructure standard
Tout d’abord il est normal de se poser la question. La réponse devrait être : « aucune ! ». Cependant, force est de constater que bien souvent le côté plus douillet de l’infrastructure hébergé « à la maison » pousse à une certaine forme de laxisme sur un certain nombre de points. Le fait que Amazon, avec ses AWS, propose une solution volatile et dynamique au niveau de ces EC2 oblige à mettre en place des mécanismes qui devraient être standards afin :

• de tirer profit des possibilités, du dynamisme, de la solution,

• de prendre en compte plus sérieusement, du fait de la volatilité de l’outil, les plans de reprise sur incident et identifier les données importantes afin d’assurer leur durabilité.

Le monitoring
Le monitoring est le premier élément à mettre en place. Dans une architecture scalable, il est indispensable d’avoir à disposition des métriques afin de savoir justement quand scaler. C’est le rôle de cet élément. Il permet de plus d’identifier les points d’engorgement de l’infrastructure, analyser l’évolution du trafic sur votre site et en déduire les comportement des utilisateurs et dans le cadre d’un monitoring actif, permet également de déclencher des alertes qui servent de base aux astreintes.

Il n’y a pas d’outil miracle pour le monitoring et un certain nombre existent sur le marché avec leurs avantages et inconvénients. Nous pouvons citer Nagios, Cacti, Zabbix, Munin, … Nous avons choisi Cacti pour notre infrastructure du fait de la qualité des courbes qu’il propose. Il est vrai que le packaging de cet outil manque, à mon avis, de rigueur et que les métriques manquent, sur certains templates, de précision, cependant la qualité des courbes, basées sur RRDtool, et leur diversité permet d’effectuer un suivi complet de notre infrastructure et de comprendre les impacts de l’évolution des composants de ladite infrastructure ou bien des applications supportées au fur et à mesure des livraisons des différentes releases.

Nous avons installé également la « plugin architecture » de Cacti qui nous permet d’installer, comme son nom l’indique, des plugin sur l’outil et notamment « Thold », nous permettant de déclencher des trigger sur l’atteinte d‘une valeur sur une courbe ou bien sur une variation afin d’effectuer du monitoring actif. Bien entendu, cela est le prélude à une gestion des astreintes et à chaque alerte remontée doit correspondre un mode opératoire de reprise sur l’incident mis en lumière via Cacti.

Le monitoring est positionné sur une machine EC2 pour des raisons évidentes de coût (le coût des échanges sur l’IP interne est nul) et de sécurité (inutile d’ouvrir plein de ports et donc autant de failles à l’extérieur).

Cacti - Apache Statistics - Thread scoreboard

La gestion de configuration centralisée
La notion de scalabilité rendue accessible par l’infrastructure des services Amazon, nous oblige à utiliser un outil de gestion centralisé de la configuration. L’utilité est multiple :

• instancier rapidement une machine correspondant à un type prédéfini : serveur SQL, serveur de cache, serveur Web, …

• assurer l’homogénéité de la configuration des instances d’un même type,

• capitaliser un savoir faire.

Nous utilisons Puppet dans notre infrastructure. Nous avons installé le Puppet Master sur le serveur de monitoring. Le Puppet Master contient les descripteurs des installations et configurations à apporter à une nouvelle machine afin de la préparer suivant le type de machine (nœud) auquel on l’a associé. Régulièrement, le client pull le master afin de vérifier que sa configuration est à jour. Il est également possible de faire du push sur les clients à partir du master pour déclencher une mise à jour urgente.

Il est ainsi très simple de monter une nouvelle instance d’un type donné et d’être sûr que, d’une machine à une autre, la configuration est complètement iso, configuration qui est centralisée sur notre machine de monitoring et dispatchée sur les instances de notre infrastructure. Il est à noter que le descripteur du Puppet Master fonctionne sur un système de nodes et donc un type de machine peut faire référence à plusieurs nodes et on obtient une configuration très modulaire. Tous nos types de machine, par exemple, utilisent le module Puppet de configuration, que nous avons décrit, du protocole SNMP, indispensable pour que Cacti monitore une machine, et le module de l’outil s3cmd nous permettant de faire fonctionner notre système de backup sur chaque machine. Ensuite, chaque type de machine a ses installations/configurations spécifiques.

Exemple du descripteur de nœuds « nodes.pp » du Puppet Master :

class web-node {
      include snmp-module
      include s3cmd-module
      include web-module
}

Exemple du descripteur « init.pp » du module « snmp » du Puppet Master :

class snmp {
      package {
            « snmpd »:
            ensure => installed;
      }

      file { « /etc/default/snmpd »:
            ensure => present,
            owner => root,
            group => root,
            mode => 0644,
            source => « puppet:///snmp/snmpd »,
            require => Package["snmpd"],
            notify => Service["snmpd"];
      }

      file { « /etc/snmp/snmpd.conf »:
            ensure => present,
            owner => root,
            group => root,
            mode => 0644,
            source => « puppet:///snmp/snmpd.conf »,
            require => Package["snmpd"],
            notify => Service["snmpd"];
      }

      service { « snmpd »:
            ensure => true,
            hasrestart => true,
            restart => « /etc/init.d/snmpd restart »,
            hasstatus => true;
      }
}

Très simple de mise en place, il nous permet de démarrer une machine en un clic sur un pic de charge. « Mais… », me direz-vous, « il faut bien installer le client sur la nouvelle machine ? ». Et oui, d’autant plus qu’il y a un système de requête/acceptation de certificat entre le client et le master afin que n’importe qui ne puisse accéder aux configurations. « Très simple ! », vous répondrais-je, au lieu d’utiliser une IHM, comme Elastic Fox, afin de se connecter aux APIs des services Amazon, il suffit de s’y connecter en lignes de commande via un script qui instancie un EC2, éventuellement crée un volume EBS et l’associe, se connecte en SSH sur la nouvelle machine et installe le client, se connecte sur le master et accepte la requête de certificat, redémarre le client sur la nouvelle machine et « hop ! ». La machine s’installe et se configure toute seule ! « Magique ! » me direz-vous, « Ca devrait être pourtant classique » vous répondrais-je… Les possibilités de réactivité et de dynamisme inhérents à EC2 et les AWS de manière générale nous impose cela, sinon ce serait sous exploiter l’outil, voire més-exploiter.

L’auto-scalabilité, que nous n’avons pas (pour l’instant ;ob) mise en place dans notre cas, consisterait, par exemple, à déclencher ce script sur le dépassement d’une valeur d’un graphe Cacti, instanciant donc une nouvelle machine pour supporter la période de pic, instance qui serait « terminée » suite au repassage en dessous de ce seuil sur le graphe. Les possibilités sont énormes.

Le déploiement automatisé
Du fait de la variation du nombre d’instances en fonction de la charge et surtout du nombre potentiellement important desdites instances, il n’est pas envisageable d’effectuer les opérations de maintenance et de déploiement unitairement sur chaque machine (et encore pire à la main !), ce qui non seulement serait chronophage, mais de surcroît source d’erreurs. Il est alors indispensable d’utiliser des outils spécialisés dans l’automatisation et l’exécution parallèle de tâches, tel que Capistrano, dont les bénéfices sont multiples :

• scripter un certain nombre de tâches (livraisons, backups, publication/maintenance du site, …) et de les exécuter en parallèle sur X machines,

• assurer la reproductibilité d’une tâche,

• exécuter rapidement des tâches complexes sur X serveurs en une seule commande,

• capitaliser un savoir faire.

Cet outil est très simple d’utilisation et très pratique et exécute des tâches en parallèle, sur un groupe de serveurs que l’on définit, en se connectant en ssh :

ssh_options[:keys] = « ~/.ssh/la_cle_privee »
ssh_options[:user] = « le_user »

Il suffit de définir une liste de serveurs correspondant à un groupe, « sql » par exemple :

role :sql, « alias_sql1  » , « alias_sql2  » , … , « alias_sqlx »

Et ensuite il reste à définir les tâches, que l’on peut décrire intégralement dans le descripteur…

task :dump_sql, :roles => :sql do
      run « rm -f /mnt/backup/`hostname`.`date +%w`-* »
      run « mysqldump –pmon_pwd -u mon_user ma_base | gzip -cq6 > /mnt/backup/`hostname`.`date +%w-%y%m%d_%H%M`.sql.gz »
end

… ou bien dans un fichier « .sh » que l’on uploade et que l’on exécute sur la machine distante

task :store_sql, :roles => :sql do
      upload « /root/cap-scripts/cap-backup_sql.sh », « /usr/local/sbin », :via => :scp
      run « /usr/local/sbin/cap-backup_sql.sh »
end

Il suffit ensuite d’exécuter la simple commande « cap dump_sql » ou « cap store_sql ».

Backups
Et oui, mettre ses données de base SQL sur EBS (dans le cas où l’on n’utilise pas SimpleDB du fait du besoin d’un minimum de modèle relationnel) ne suffit pas, parce que :

• EBS assure une durabilité très respectable par réplication réseau, mais reste l’équivalent d’un disque dur, même si plus fiable,

• il n’y a pas que les données de base SQL (ou autres) qui sont importantes, il y a également vos logs principaux et les configurations de vos outils (Cacti, Puppet, Capistrano, …).

Nous utilisons l’outil en ligne de commande « s3cmd » afin de stocker nos backups. Cet outil est utilisé dans nos tâches Capistrano appelées par cron. Très simple d’utilisation, il nous permet d’utiliser les API’s S3 et offre la possibilité de transférer les données en HTTPS et également de les stocker sous un format crypté.

Tips and tricks
DNS
Il arrive de rencontrer quelques soucis DNS au niveau du réseau Amazon pour les instances EC2. Un conseil donc, positionner des hostname plus parlant (au lieu des « domu -xxxx») et utilisez le fichier des « hosts » que vous déployez ensuite via Puppet !

CDN
Nous utilisons S3 dans notre architecture afin de mettre à disposition les images et autres statiques de notre application à disposition de notre Content Delivery Network, à savoir Panther. Inutile, en effet, de maintenir un serveur Web à cette seule fin, S3 est là pour ça pour un coût minime.

Gestion des Logs
Il serait, à mon avis intéressant, de gérer également les logs de manière centralisée. Nous ne l’avons pas mis en place et, par conséquent, je ne ferai pas de recommandations sur un sujet que je n’ai pas testé moi-même. Cependant, pour indication, il est possible de mettre en place un système de logs réseaux, sous Linux par exemple, afin de centraliser et de mutualiser les logs, logs qu’il est ensuite possible d’analyser. Ca vaut le coup pour une infrastructure ou une application distribuée de connaître le comportement ou les différences de comportement des éléments qui la constitue.

Webistrano
Webistrano est une IHM permettant d’accéder aux fonctionnalités de Capistrano et introduisant une notion de gestion de projet par la possibilité de gérer les accès aux tâches en fonction de son profil, de tracer qui a déployé quoi sur quel serveur et d’envoyer des alertes mails sur certaines actions. Nous ne l’avons pas testé en production, mais cela peut s’avérer intéressant à prendre en considération.

Conclusion
Le but de ce post n’est pas de faire la publicité de tel ou tel outil, mais de vous inciter à considérer l’automatisation de votre infrastructure qui, si elle devrait déjà être en place dans vos infrastructures actuelles internes, devient indispensable sous AWS pour peu que l’on souhaite faire de la scalabilité, être réactif ou simplement tirer parti de l’outil mis à disposition.

Je dirais que les principes fondamentaux d’une bonne infrastructure sont au nombre de 3 : KISS, DRY et YAGNI.

• KISS pour « Keep It Simple, Stupid », à savoir inutile de chercher à complexifier l’infrastructure, la plus efficace sera la plus simple.

• DRY pour « Don’t Repeat Yourself » , à savoir ce qu’il est possible de scripter et d’automatiser faites-le ! Ca vous prendra un peu plus de temps la première fois, mais vous aurez une tâche réfléchie, reproductible, et vous n’aurez surtout pas besoin de le faire une seconde fois (quoi de plus ennuyeux que de se répéter).

• YAGNI pour « You Ain’t Gonna Need It », à savoir n’installez sur vos machine que ce dont vous avez besoin. Plus vous installerez d’outils inutiles ou one-shot, plus votre infrastructure aura potentiellement des trous de sécurité et pourra introduire des effets de bords. Sans aller forcément jusque là, disons qu’elle sera moins facilement maintenable.

Ces principes vous paraissent drôles pour certains ou peut-être un peu ringard pour d’autres, mais si avant de faire une tâche sur une infrastructure on se demandait si ce que l’on va entreprendre ne rentre pas dans un de ces cas, je pense que les infrastructures, de manière générale, seraient plus fiables, homogènes et performantes.

Frédéric FAURE

Application sociale / Cloud Computing : adéquation !
Tout d’abord il est important de souligner l’adéquation entre les besoins, en termes d’infrastructure, des applications sociales et le Cloud Computing : le succès des applications sociales est, en effet, basé sur un phénomène de viralité et celles-ci peuvent connaître le succès du jour au lendemain. Il est alors nécessaire de rentrer dans une phase d’extension/paramétrage de l’infrastructure qui doit être rapide pour répondre à la nouvelle fréquentation explosive de l’application et ne pas prendre le risque de voir le succès brisé sur sa lancée, faute d’ infrastructure permettant la montée en charge. Le succès étant difficile à prévoir sur ce genre d’application, il n’est pas envisageable d’acheter et de conserver à disposition un grand nombre de ressources matérielles en attendant l’hypothétique succès. Ca peut fonctionner, comme ça peut ne pas fonctionner : n’investissons pas… Mais soyons prêts ! C’est tout l’intérêt du Cloud Computing !

Il me paraît important de préciser que quand je parle de « ne pas investir », j’entends en termes de logistique. Faire l’économie d’un investissement sur la réflexion lors de la conception de l’infrastructure et, par la suite, lors de la mise en place des composants de base qui vont supporter l’application, reviendrait à ne pas être prêt, donc à un échec… ou bien à un surcoût dans le meilleur des cas !

Application sociale & conception
Une brève digression à ce niveau me paraît indispensable avant d’entamer le vif du sujet sur l’infrastructure. Il est indispensable de savoir qu’un code optimisé et réfléchi permettra d’économiser beaucoup d’argent et de complexité de l’infrastructure par la suite. Pas des choses compliquées, mais juste un minimum de réflexion :

• Quelles sont les informations que nous mettrons à disposition dans des caches et celles accédées en base ?

• Quelles sont les informations volatiles (en générale à destination du cache) ?

• Comment gérer mes connexions aux ressources pour les maintenir un temps minimal : gestion d’un pool de connexions afin d’optimiser les temps d’accès, respect de la cinématique connexion/récupération des données/fermeture de la connexion/traitement des informations récupérées afin de ne pas maintenir de connexions inutiles, groupage des requêtes, …

• Gérer un code modulaire afin de pouvoir le faire évoluer rapidement en fonction notamment des temps de réponse induits par telle ou telle fonctionnalité en fonction de la montée en charge,

• Séparation de l’IHM et du traitement, séparation des fonctionnalité de l’application et des APIs du réseau social, séparation des ressources et du code… On ne sait jamais ! Si ça fonctionne bien, il serait dommage de se priver d’un portage sur une autre réseau social parce que l’application est mal conçue au niveau découpage.

De part mon expérience, les principales optimisations, en termes de temps de réponse, que l’on peut constater sur une application à forte sollicitation sont réalisées au niveau du code de l’application ! Sur une application présentant des problèmes de conception, il apparaît au fur et à mesure de l’augmentation des capacités de l’infrastructure que le bénéfice retiré sera moindre. On peut rapprocher cela d’une courbe logarithmique : au début l’augmentation des capacités de l’infrastructure compensera les problème liés à la conception de l’application, mais arrivé à un certain seuil le bénéfice en termes de résistance à la charge sera faible par rapport aux investissements sur l’infrastructure.

Ce point est à méditer fortement…

Il était une fois…
RDV sur le site http://aws.amazon.com/ , préparez votre numéro de carte bleue, enregistrez-vous… Bravo ! Vous venez d’acquérir votre passe pour les nuages composé d’une « access key » et d’une « secret key ».

Le Cloud Computing AWS est composé comme son nom l’indique de… services web ! Pour y accéder, rien de plus simple : soit vous utiliser des APIs en ligne de commande, pratique pour l’automatisation des tâches à venir par la suite mais rebutant pour une première expérience, soit vous optez pour Elasticfox (Firefox Extension for Amazon EC2) proposant une IHM permettant d’accéder aux fonctionnalités des AWS et d’avoir un tableau de bord de vos instances, volumes, snapshots, groupes de sécurité, … Vous pouvez télécharger la « console élastique » sur http://developer.amazonwebservices.com/connect/entry.jspa?externalID=609 .

Une infrastructure à part entière
La premier piège à éviter est de considérer votre infrastructure comme une sandbox dans laquelle vous pouvez un peu tout tester et puis vous dire que vous pourrez revenir en arrière par la suite, un peu plus tard, si vos choix ne vous satisfont pas quand votre application commencera à fonctionner… Non ! Il s’agit d’une véritable infrastructure où vous devrez faire des choix, faire preuve de réflexion, anticiper,… Le Cloud Computing vous décharge de nombre de problèmes logistiques, vous permet d’être réactif, de disposer de ressources quasi illimitées, de réduire vos coûts, … Mais vous demandera la même réflexion que pour toute infrastructure.

La prise en main
La première étape de la mise en place d’une infrastructure sur AWS consiste en une prise en main. Une journée de prise en main fera l’affaire, c’est pas compliqué !

Documentation
Il est important dans un premier temps de consulter le site d’Amazon et de prendre connaissances des différentes briques/options à votre disposition, de lire la documentation en quelque sorte ! C’est rapide mais indispensable…

Tests
Vous pouvez ensuite effectuer des tests et vous mettre à l’aise en démarrant des instances EC2, en y attachant des volumes EBS, … Rassurez-vous ca ne coûte pas grand-chose !

RAZ
Vous êtes à l’aise ? Supprimez tout ce que vous avez fait et passez à la phase de conception. Supprimez tout ? Oui ! Premièrement, parce que dépenser de l’argent inutilement, même peu, en laissant des instances fonctionner, c’est pas terrible et surtout parce que l’étape de conception va vous amener à faire des choix fondateurs… Donc supprimez tout !

Réflexion macro…
La seconde étape est de décider :

• de leur répartition géographique,

• du niveau de disponibilité que vous souhaitez accorder à vos services en fonction de leur criticité.

Région et répartition géographique
Il faut tout d’abord sélectionner une région, à savoir « us-east-1 » pour les Etats-Unis (service web endpoint : « us-east-1.ec2.amazonaws.com » ou « ec2.amazonaws.com » – pour retro compatibilité) et « eu-west-1 » pour l’Europe (service web endpoint : « eu-west-1.ec2.amazonaws.com »). Il faut savoir que chaque région est totalement isolée. Il faut donc effectuer un choix en fonction de sa localisation ou plus exactement en fonction de la localisation des utilisateurs (humains ou systèmes) potentiels. Lors de la mise en place de notre application sociale, la région européenne était en beta, nous avons donc sélectionné la région « us-east-1 » pour notre environnement de production, même si la cible majeure de nos utilisateurs était européenne.

Zone d’accessibilité et disponibilité des services
Il faut ensuite choisir si il est nécessaire de mettre en place un système de résistance à la panne (fault tolerance) via les zones d’accessibilité à l’intérieur d’une région. Les zones d’accessibilités sont distinctes et isolées les unes des autres au niveau réseau. Il faut savoir que les ressources AWS n’ont pas la même portée : par exemple une instance EC2 et un volume EBS n’ont une portée que sur la zone d’accessibilité et doivent être dans la même bien évidemment pour être attachés. S3, en revanche, à une portée sur la région et permet d’échanger des données et de générer des EBS à partir de snapshots dans n’importe quelle zone d’accessibilité d’une région donnée. Un doublement du service dans 2 zones différentes doit être chapoté par une « Elastic IP » qu’il est possible de mapper à tel ou tel point d’entrée. Il est à noter qu’une « Elastic IP » peut être mappée sur 2 instances d’une même zone, bien sûr, afin de parer à la défaillance d’une instance (en point d’entrée) plutôt que d’une zone complète. Dans le cas de notre application, nous sommes restés dans une seule zone d’accessibilité, sans « Elastic IP ». La criticité d’une application sociale est moindre et la rupture de service acceptable (dans une certaine limite bien sûr). Nous avons en revanche mis en place une architecture solide dans la zone d’accessibilité sélectionnée.

Ci-dessous un schéma tiré du site d’Amazon représentant les régions et zones d’accessibilité.

AWS : Regions et Zones

Le tableau ci-dessous résume la portée (scope) des ressources pour Amazon EC2 (globale, régionale ou zone d’accessibilité) :

Ressource - Portée
Compte AWS - globale
Système d’identifiants EC2 (dont AMI ID, Instance ID, EBS Volume ID, EBS Snapshot ID, …) – régionale
Instances EC2 – zone d’accessibilité
AMIs – régionale
Groupe de sécurité – régionale
Clés SSH (Key Pairs) – régionale
Elastic IP – régionale
Volumes EBS – zone d’accessibilité
Snapshot EBS (stockage sur S3) – régionale

 …Et jeu de Légos !
Le choix des briques est fonction de l’application, dans notre cas nous avons utilisé les composants décrits ci-dessous.

EC2 : instances virtuelles
Il est à noter que les informations sur les instances ne sont pas sauvegardées et sont perdues en cas d’arrêt de l’instance, il ne doit donc pas y avoir de données applicatives stockées dessus ou bien elles doivent être backupées régulièrement. Les instance EC2 sont attachées à une zone d’accessibilité. Il est à noter qu’il est possible sur des instances EC2 de rencontrer des « hardware failures ». Cela nous est arrivé 3 fois sur un parc d’une trentaine d’instances EC2 en l’espace de 5 mois. D’où l’importance de ne pas stocker de données applicatives ou de les backuper, de prévoir une remontée rapide des instances (utilisation d’un gestionnaire de configuration centralisé type « Puppet », utilisation d’AMIs, …) et d’utiliser les composants mis à disposition par Amazon comme les volumes EBS ou bien S3 pour le stockage fiable de données critiques.

EBS : volumes de stockage haute performance pour EC2
Les EBS permettent de stocker les données de notre base de données afin d’offrir persistance (contrairement à EC2) et une bien meilleur gestion des i/o nécessaire pour les nombreuses lectures/écritures sur disque. Un EBS est attaché à une unique instance EC2, il est possible d’attacher X EBS à une instance EC2. Les volumes sont alors perçus au niveau des instances EC2 comme des « devices » qu’il est alors possible de formater et de monter. L’EBS peut être détaché et rattaché à une autre instance EC2 à chaud. Les volumes EBS sont attachés à une zone d’accessibilité, il est alors possible de les attacher à des instances EC2 appartenant à la même zone. Concernant la persistance, et plus exactement la durabilité, les données sur EBS sont répliquées sur différents serveurs dans une même zone d’accessibilité, ce qui permet de prévenir la perte de données. La perte est toujours possible, mais 10 fois moins qu’avec une gestion de disque dur classique selon Amazon. Il est à noter que du mirroring entre EBS dans une même zone d’accessibilité ne va pas servir à grand-chose en termes d’amélioration de la durabilité des données. Dans notre cas, nous avons créé des volumes de 20 Go pour stocker les données de nos bases MySQL, mais il est possible d’en créer de 1 Go à 1 To.

S3 : stockage persistant de données inter zones
S3 peut être utilisé afin de créer des snapshots d’EBS qui seront répliqués et accessibles entre plusieurs zones d’accessibilités, offrant une durabilité accrue et surtout la possibilité de recréer des volumes EBS à partir de ces snapshots sur différentes zones d’accessibilité, S3 ayant un scope inter zones dans une région donnée. S3 permet également de stocker des données et de les rendre disponibles ou non sur le Web via des ACL. Nous utilisons S3, dans notre cas, afin de faire des backups (donc ACL privée et uniquement accessibles par le(s) détenteur(s) de la clé de sécurité) des données des bases (MySQL), mais utilisons un dump standard que nous poussons ensuite sur S3 via un client (s3cmd). Nous préférons cela car ce fonctionnement nous permet d’effectuer si nécessaire un dump « à chaud » sans avoir à locker les tables (même si locker les tables est plus propre et effectué régulièrement lors de la maintenance nocturne) ou plus exactement à freezer l’EBS et préférons en cas de corruption (improbable) de la sauvegarde avoir à traiter avec un dump standard plus simple à « corriger ». Nous stockons également des logs importants et les configurations importantes de nos EC2. Il est à noter que dans le cas de dump, même sans lock, sur des sites très sollicités, cela n’est possible que sur les bases les plus légères et les moins sollicités. Les éléments les plus sollicités ne peuvent être backupés que durant un phase de fermeture du site. Nous utilisons également S3, avec une ACL publique cette fois-ci, afin de mettre à disposition de notre CDN les données statiques (images, bannières de publicité, …). Des clients graphiques simples (comme « Amazon S3 Firefox Organizer » (S3Fox), une extension Firefox sur le modèle de notre « console élastique ») permettent d’interagir avec S3 afin de rendre accessible les buckets (espace de stockage sur S3) aux responsables du contenu du site, par exemple.

Il est à noter que concernant les EC2 et les EBS qu’une limite de 20 instances de chaque par compte utilisateur est positionnée au départ. Ces limites peuvent être augmentées indépendamment l’une de l’autre à 40, puis à 100, … sur simple demande à un contact. La demande est prise en compte dans les 24 heures, prévoyez donc cela un peu à l’avance.

De plus, une offre de support est disponible en version « Silver » ou « Gold » afin de vous accompagner et répondre à vos questions. Vous pouvez consulter http://aws.amazon.com/premiumsupport/ pour plus d’informations.

AMIs
Il faut ensuite sélectionner l’AMI, le système virtuel à installer sur le matériel. Il est à noter qu’en fonction de la configuration matérielle choisie (m1.small, m1.large, m1.xlarge, c1.medium ou c1.xlarge), il y a une architecture sous-jacente (32 ou 64 bits). On ne peut donc pas poser n’importe quel système sur n’importe quelle architecture… Et les services AWS le gèrent bien ! Heureusement !

Il est également possible d’enregistrer vos propres AMIs que vous aurez configurées avec soin afin de les utiliser.

Nous avons opté pour une AMI « ubuntu-8.10-intrepid-base-64 » proposée dans la liste des AMIs disponibles.

Logiciels
Après avoir sélectionné le système, vient la sélection des logiciels. Cette section dépend complètement de l’application que vous allez mettre en place, cependant, sur des applications nécessitant de la scalabilité, on retrouve des axes majeurs et des problématiques récurrentes.

Tout d’abord un balancer Soft (HaProxy, …) distribuant les requêtes sur plusieurs frontaux Web (Apache, lighttpd, …) qui exécutent les traitements dans le cas de langages comme PHP (en CGI ou en mod) ou bien qui eux même redirigent les requête vers des serveurs applicatifs (Tomcat, Jetty, …) exécutants des traitements JAVA par exemple. Il serait possible de faire un post entier rien que sur les optimisations qu’il est possible d’apporter à ces niveaux, sur la gestion des processus et des threads, sur la gestion des piles de connexions, … Nous avons dans notre cas opté pour un HaProxy qui distribue les requêtes sur plusieurs Apache en « mod_php ».

Ensuite vient la base, avec le choix de la base en fonction des besoins (PostgreSQL, MySQL, …) : nous avons opté pour MySQL. A partir de là, les choix clés en termes de stockage : quel stockage ? InnoDB ou MyISAM ? Pour les tables essentiellement accédées en lecture ou nécessitant de la recherche « full text » : MyISAM ! Pour celles accédées en écriture : InnoDB (avec son système de row locking) ! Un mixte des 2 est possible en fonction des données (attention en revanche, les jointures inter stockages sont déconseillées) et pourquoi pas de la réplication sur les données vitales et fortement accédées avec un master InnoDB pour l’écriture et un slave MyISAM pour la lecture ? Non, il y a beaucoup trop d’accès et la réplication du master vers le slave ne sera pas encore effective pour la phase de lecture de certaines données, on optera pour 2 InnoDB avec un seul accédé en lecture/écriture, cela nous permettant lors d’un problème sur le master de le remplacer par le slave qui sera également performant en écriture (en MyISAM, les écritures saturent la base…). On limite les jointures pour bénéficier des avantages du système MySQL. Tout ça sans parler du paramétrage de chaque mode de stockage (InnoDBBufferPool, …) en fonction des opérations et de la volumétrie du site… Plus la volumétrie sera importante, plus le positionnement des index sera vital ! Nous avons également fait du sharding de données (découpage horizontal) via un modulo afin de répartir les données ne nécessitant pas de requêtes ensemblistes sur plusieurs serveurs et permettre de meilleurs temps de réponse et la possibilité d’une meilleure montée en charge.

Une couche de cache gérée par Memcached pour soulager les bases des données les plus souvent accédées…

Et voilà ! Un bref aperçu de la partie qui nous a probablement pris le plus de temps et qu’il est bien souvent nécessaire d’optimiser, une fois les grands axes retenus, au fil de la montée en charge de l’application.

Security Groups
Une fois les logiciels sélectionnés, il faut mettre en place les groupes de sécurité AWS. Ces groupes vont permettre de limiter les interactions des machines entre elles mais aussi de restreindre les accès de l’extérieur. Un groupe de sécurité se paramètre « tout simplement » comme un firewall avec le protocole utilisé (udp, tcp, icmp, …), le port ou la plage de ports (1 à 65535) ouverts pour les ayants-droits définis soit par un couple « identifiant de compte AWS :groupe », soit par une adresse IP d’un réseau ou d’un host. Cela s’effectue au niveau de la console « Elastic Fox », comme beaucoup de paramétrages.

Exemples :

• le groupe « Load-Balancer » octroiera pour tcp sur le port 80 (HTTP) les IPs du réseau extérieur 0.0.0.0/0 ,

• le groupe « Web » octroiera pour tcp sur le port 80 (HTTP) les machines de mon compte AWS appartenant au groupe « Load-Balancer »,

• le groupe « SQL » octroiera pour tcp sur le port 3306 (MySQL) les machines de mon compte AWS appartenant au groupe « Web »,

• …

• tous les groupes octroieront pour tcp sur le port 22 (SSH) l’ IP extérieure de l’administrateur de l’infrastructure AWS x.x.x.x/32 ,

• tous les groupes octroieront pour udp sur le port 161 (SNMP) les machines de mon compte AWS appartenant au groupe « Monitoring ».

Attention : une fois un EC2 démarré dans un groupe, il n’est pas possible d’en changer, c’est pour cela qu’il est important d’avoir défini les groupes au préalable. C’est de plus un très bon exercice de réflexion afin de concevoir l’infrastructure.

De plus, une même instance peut appartenir à plusieurs groupes, par exemple un EC2 hébergeant un MySQL et un Memcached appartiendra au groupe définissant les règles d’accès aux serveurs MySQL et à celui définissant les règles d’accès aux serveurs Memcached. Cela permet une structuration et une granularité/découpage des règles par fonctionnalités.

Les 2 dernières règles précédentes pourront donc s’écrire :

• toutes les machines appartiendront à un groupe supplémentaire qui octroiera pour tcp sur le port 22 (SSH) l’ IP extérieure de l’administrateur de l’infrastructure AWS x.x.x.x/32 ,

• toutes les machines appartiendront à un groupe supplémentaire qui octroiera pour udp sur le port 161 (SNMP) les machines de mon compte AWS appartenant au groupe « Monitoring ».

Comme précisé, cela permet de découper la sécurité par fonctionnalité.

Il est à noter également que les modifications des règles de sécurité d’un groupe donné sont instantanées.

Ressources et pricing
L’étape suivante est de définir les ressources dont nous aurons besoin pour l’application en termes de puissance et de stockage. Etablir une prévision de l’utilisation des ressources est indispensable afin d’avoir une vision claire des coûts sur le mois, les coûts horaires/trafic ne permettant pas cette vue d’ensemble. Il faut prendre en compte le coût fixe (facilement prédictible) des ressources et également les coût associés au trafic réseau en effectuant une prévision qu’il sera possible d’ajuster en fonction de l’évolution de la fréquentation sur le site. Au final, une bonne feuille Excel résumera pleinement la situation sur le mois et à l’année.

Concernant la puissance (RAM, CPU, …), il est en effet important de prendre ce dont nous avons besoin et de ne pas surestimer les besoins, en effet le prix de chaque configuration dépendant des ressources associées. De plus sur ce genre d’infrastructure, il faut réfléchir en termes de scalabilité et donc de distribuer la charge sur X machines plus réduite que sur une trop importante afin d’avoir la possibilité de lisser au mieux la charge.

Je n’aborderai pas ici le sujet de la conception d’applications « complètement » distribuées, sujet qui n’est pas trivial, loin de là. Il est très peu commun (comprendre rare ;o)) de voir des applications distribuées à tous les niveaux permettant par simple multiplication du service (et des éléments sous-jacents) d’augmenter les capacités de réponse, bien souvent la source de données est un goulet d’étranglement non distribué. La distribution est à mon avis la clé de ce genre d’application mais engendre bien souvent un coût de conception bien trop important. Disons le autrement : nous n’avons pas pris l’habitude de réfléchir naturellement dans ce sens et n’avons pas de modèles/standards évidents et donc le coût de réflexion associé augmente…

Tadaaa !
Il ne vous reste plus qu’à lancer les instances EC2 à partir de la console « Elastic Fox » en sélectionnant l’AMI retenue (la vôtre ou une « standard »), en lui attribuant une configuration (m1.small, m1.large, m1.xlarge, c1.medium ou c1.xlarge), une clé de sécurité, une zone d’accessibilité et finalement un ou plusieurs groupes de sécurité. Il reste à récupérer 15 secondes plus tard le nom DNS public de la machine et à vous y connecter via un client SSH. Il vous sera également possible de démarrer un volume EBS en précisant sa taille en Go, sa zone d’accessibilité et éventuellement le snapshot à partir duquel il va être généré. Reste ensuite à associer le volume à une instance EC2 en précisant le nom du device qu’il prendra (par exemple « /dev/sdd »). Et voilà, c’est parti !

Il est très important de noter que chaque machine possède un nom DNS privé qu’il est indispensable d’utiliser pour une communication entre les machines car le trafic interne entre les EC2 n’est pas facturé contrairement au trafic entrant via le nom DNS public ou bien une « Elastic IP » ! Une erreur de configuration pourrait avoir comme conséquence une hausse des coûts inutile.

Conclusion
La conception d’une infrastructure sur AWS demande autant de réflexion que n’importe quelle infrastructure pour la mener à bien. Il faut bien comprendre les spécificités des services Amazon et plus généralement sa conception pour les utiliser au mieux. Cependant, une fois appréhendés, les AWS permettent de monter une infrastructure modulaire et performante en un minimum de temps puisque sortie des considérations logistiques, dynamique et réactive de part les possibilités en termes de scalabilité et pour des coûts correspondant à vos réels besoins.

Il reste à noter qu’il faut également suivre l’évolution des services Amazon qui proposent au fur et à mesure de nouvelles fonctionnalités intéressantes (voir par exemple http://aws.amazon.com/contact-us/new-features-for-amazon-ec2/) qui suivent la cinématique standard de diffusion privée, diffusion publique en beta puis diffusion publique. Il est nécessaire de se tenir informé afin d’avoir toujours une vue exhaustive des composants à disposition et d’utiliser au mieux les briques mises en place en standard.

Il reste à présent la mise en place d’une telle infrastructure et il convient pour un service hébergé de la sorte de mettre en place un certains nombres de composants en place afin d’automatiser et d’homogénéiser l’infrastructure. Cela fera l’objet de mon prochain post.

Frédéric FAURE

On entend beaucoup parler du Cloud Computing ces dernier temps, à juste titre me demanderez-vous ? Mais qu’est-ce que le Cloud Computing et ne s’agit-il pas encore d’un nouveau buzz word pour vanter les mérites d’une technologie déjà connue ?

Quelle différence entre le Cloud Computing et la virtualisation que l’on connait déjà ?

La virtualisation permet de mutualiser les ressources hardware (disque, RAM, …), de diminuer les coûts en terme de consommation d’énergie électrique, de place et de personnel pour l’administration et la logistique et d’augmenter l’efficacité des PRA (Plan de Reprise d’Activité) du fait de la simplicité de remise à disposition d’un système en quelques clicks. Cette couche d’abstraction entre le système et le hardware a permis une avancée au niveau de l’administration des parcs informatiques.

Le Cloud Computing c’est en fait de la virtualisation, mais chez un hébergeur. Quels sont les avantages ?

·         De même que pour l’hébergement classique, cela permet de s’affranchir des problématiques hardware : plus besoin de commander, par exemple, un ESX et ses lames avec les questions de délais et d’installation, tout est déjà en place et l’interface d’administration n’attend que vous.

·         L’autre valeur ajoutée, plus originale celle là, est le modèle économique retenu, le « SaaS » (Software as a Service), c’est-à-dire la facturation à l’utilisation : une partie « fixe » (c’est-à-dire prédictible) fonction du temps d’utilisation des ressources réservées (CPU, RAM, disque, …) et une partie « variable » (dépendante de votre succès) en fonction du trafic (l’utilisation du réseau en quelque sorte). Et pour les systèmes payants (Windows, …) un surcoût (très raisonnable) est appliqué sur la partie « fixe » afin de compenser la licence. Certains packages systèmes/logiciels payants existent également avec leur tarification « fixe » associée.

Ces 2 composantes mises ensembles, cela vous permet par exemple de monter une plateforme pour une démonstration de 2 jours pour un coût dérisoire avec à disposition des ressources en termes de puissance (CPU, RAM, …) et de stockage de données quasi illimitées.

Quelle est la cible du Cloud Computing ?

Le Cloud Computing serait-il alors une énorme sandbox (bac à sable ou environnement de tests) réservée pour les POC (Proof Of Concept), pour les démonstrations en quelque sorte ? Bien sûr que non, ce serait du gâchis ! Cette offre s’adapte aussi très bien aux applications qui nécessitent de la scalabilité, et il y en a de plus en plus de nos jours :

·         Les applications sociales que l’on trouve sur FaceBook, par exemple, et qui peuvent connaître un succès du jour au lendemain en profitant de phénomènes de viralité et voir leur fréquentation exploser.

·         Les APIs montées elles mêmes sur un modèle économique de type SaaS et qui ne nécessitent de dépenser de l’argent pour leurs ressources qu’à partir du moment où des clients paient pour utiliser lesdites APIs.

·         Finalement, le Cloud Computing propose également des possibilités variées comme Amazon avec ses AWS (Amazon Web Services) qui décompose son offre en plusieurs parties : EC2 (Elastic Compute Cloud) pour les instances de machines virtuelles, EBS (Elastic Block Store) pour le stockage de données persistantes avec de nombreux i/o (type données de bases de données), SQS (Simple Queue Service) pour la gestion de files de messages, SimpleDB pour un stockage de données simplifié sur un modèle non relationnel, CloudFront pour délivrer des contenus statiques (images, …) avec une distribution géographique (fonction de CDN (Content Delivery Network) comme Akamai, …), … et S3 (Simple Storage Service) spécialement mis en place pour le stockage de données à disposition d’Internet. S3 est tout à fait adapté à des sites de type contenu, collaboratif par exemple comme les blogs, … en offrant un volume de stockage quasi illimité. Et le trafic me direz-vous ? Libre à vous de gérer votre propre plateforme de cache en amont qui cache les informations les plus tendances et ne fait appel à S3 que pour charger les informations moins requêtées. Magique !

Avec un minimum d’infrastructure, il est possible de maintenir des sites grand format !

La mort de la virtualisation ?

Mais alors, la virtualisation que nous connaissons et qui ne date pas de si loin me direz-vous est-elle sur le déclin ? Hé bien non, car elle ne s’adresse pas à la même cible. Prenez l’exemple d’un SI, urbanisé avec son EAI, son ETL, sa gestion centralisée de l’authentification, … Trop complexe et de plus la scalabilité n’est pas de mise puisque le public cible des applications du SI est sensé être connu… Enfin… Si on a pensé à faire un cahier des charges et une matrice des flux échangés ! Mais cela est un autre sujet…

De plus, un des thèmes encore tabou du Cloud Computing est résumé simplement par « Mais où sont mes données ? »,  « Que se passe-t-il lorsque j’arrête le site, suis-je sûr que mes données sont effacées ? » et « D’autres que moi ont-ils un droit de regard sur mes informations ? ». A l’heure où même le secret bancaire vacille, il est juste de se poser la question. Actuellement, la réponse est loin d’être évidente et les règlements internationaux s’entremêlent. La confidentialité des données n’est, à mon avis, pas encore assurée et il faudra attendre un murissement certain avant de voir des zones de stockage régies par une charte internationale ou à la carte. En attendant, ce genre de préoccupation ne concerne pas la majeure partie des sites, loin de là.

Les différentes formules

Infrastructure

J’ai testé l’offre d’Amazon avec ses AWS. AWS propose la mise à disposition de machines virtuelles avec des spécifications techniques hard (CPU, RAM, architecture, …) sur lesquelles on sélectionne le système à charger parmi une liste. Ensuite, on peut se connecter en SSH à la machine et on l’administre à sa guise, en utilisant ou non les briques (EBS, SQS, …) mises à disposition.

Webapp

Le fonctionnement retenu par Google (Google App Engine), pour ne citer que lui, qui propose un environnement d’exécution pour vos applications web, à la contrainte près de l’utilisation de Python pour le développement des applications, de l’utilisation d’un modèle de stockage de données non relationnel (BigTable), du respect de contraintes de performances sur les temps de réponse et les volumes échangés, … Un environnement beaucoup plus structuré (et contraignant) qui est le pari de Google qui a misé sur la performance grâce à l’homogénéité et la simplicité. Il est à noter que pour intégrer des applications déjà développées, cela impliquerait une réécriture totale ou partielle de celles-ci… Google a choisi de se séparer des boulets « ressource-phages » du passé.

Autres

D’autres formules vont probablement faire leur apparition : on note par exemple Microsoft’s Azure Services Platform qui proposera une gamme de services étendue.

En conclusion

Le Cloud Computing est promis à un bel avenir. Il s’inscrit en effet dans la démarche en vogue de restructuration des infrastructures et de réduction des coûts. Il rejoint de plus le modèle économique SaaS par ce que l’on pourrait appeler le modèle Haas (Hardware as a Service). Ce modèle économique s’inscrit dans l’évolution naturelle des architectures vers les SOA (Services Oriented Architecture) et répond aux besoins des consommateurs.

Les services proposés par les sociétés de Cloud Computing seront probablement la clé de leur succès, des services comme, par exemple, FPS (Flexible Payments Service) de Amazon permettant via une API d’accéder à des fonctionnalités de paiement sécurisé. Lorsque les offres vont mûrir, des services orientés métier apparaîtront probablement, facilitant la mise en place de processus métiers.

Cela ne veut pas dire pour autant qu’il n’y aura plus besoin de réfléchir lors de la mise en place d’infrastructures et il y a maintenant 2 questions essentielles à se poser :

·         Le Cloud Computing répond-il à mon besoin en particulier et apporte-t-il des avantages par rapport à une infrastructure virtualisée (ou non) interne ?

·         Si oui, quelles sont les briques dont j’aurai besoin et comment les organiser ?

Le Cloud Computing décharge d’un certain nombre de contraintes logistiques, voire d’un nombre certain, mais il faut toujours une étape de conception rigoureuse et réfléchie de l’infrastructure.

Une description détaillée de la conception et de la mise en place de l’infrastructure sur AWS d’une application sociale à forte sollicitation fera l’objet de mes prochains posts.

Frédéric FAURE