Le fonctionnement

Varnish se configure simplement grâce à deux types de fichiers. Le fichier de configuration de Varnish où nous allons définir certains paramètres internes et les fichiers VCL qui permettent de configurer le comportement de Varnish via une sorte de langage de programmation.

Le principe de Varnish s’appuie sur la machine à état suivante :

Varnish permet d’intervenir au niveau de chacun des états pour effectuer des opérations sur HTTP ou sur lui-même. C’est cette finesse d’intervention qui permet à Varnish d’être véloce et complet.

Un client effectue une requête sur une ressource qui n’est pas en cache suivra le cheminement suivant :

Si cette ressource est demandée à nouveau, le chemin suivi change car la ressource est maintenant en cache :

Toutes ces étapes sont symbolisées en VCL par des “procédures standards” (vcl_recv, vcl_fetch, vcl_deliver… etc). Toutes ces procédures sont surchargables et nous pouvons aussi déclarer les nôtres qui seront appelées dans les procédures standards. Le langage VCL ne tolère aucun code orphelin, tout ce qui est déclaré doit être utilisé.

Le Cache

Varnish propose un cache en mémoire et un cache sur disque. Mais il faut faire un choix, les deux ne sont pas cumulables. Le cache accepte à peu près tout ce qui passe dans les mains de Varnish (pages HTML, fichiers statics, flux de données en JSON… etc), à partir du moment où l’on déclare l’objet cachable et qu’il a une TTL.
Le cache est alimenté juste après l’étape “Fetch”, en réalité c’est juste après la récupération de la donnée sur le backend. C’est à cet endroit que l’on va faire toutes les modifications de l’entête HTTP de la ressource cachée. Faire ces modifications au niveau du “Fetch” va permettre de garantir une entrée cache propre (ne pas avoir plusieurs entrées cache car une même ressource va avoir un payload différent). De plus l’objet est stocké dans le cache avec son entête HTTP, il est donc plus efficace de traiter une fois pour toute l’entête et la resservir avec l’objet.
Comme nous le verrons plus loin, la compression d’objet influe aussi sur les performances du cache. Il est préférable de stocker un objet compressé et laisser Varnish le délivrer compressé ou non suivant l’entête “Accept-Encoding”.

La définition correct de la TTL d’un objet pour manager le cache-control est un élément important de Varnish. Nous pouvons contrôler le cache de façon précise en définissant la TTL pour un type de ressource ou pour une url par exemple :

if(beresp.ttl > 0s){
  unset beresp.http.Expires;
  if ( req.backend == backend_S3 ) {
     set beresp.http.Cache-Control = "public, max-age=60";
     set beresp.ttl = 60s;
  } else {
     set beresp.http.Cache-Control = "public, max-age=7200";
     set beresp.ttl = 2h;
  }
}

Ici nous demandons à Varnish de cacher sur 60 secondes tout ce qui vient de le backend “backend_S3” et le reste sera caché deux heures.

Le cache peut se manager de deux façons différentes :

La Compression

Depuis la version 3.0, Varnish a la possibilité de compresser et décompresser des ressources. Cette fonctionnalité est importante pour 3 raisons :

Elle peut être activée simplement en harmonisant l’entête “Accept-Encoding” et en positionnant la variable “do_gzip” au niveau du backend ou de la réponse du backend. Pour le reste Varnish va adapter la réponse (objet compressé ou non) au client en s’appuyant sur le “Accept encoding” de la requête.
Il est bien sûr évident que la stratégie de compression doit être adaptée au type d’objet. On ne compressera pas un objet déjà compressé (gif, jpg…etc) :).

Le Loadbalancing

Varnish peut gérer des backends de tous horizons. Avec des sites de plus en plus chargés, il est capable d’offrir la possibilité de faire du loadbalancing. Varnish dispose de 3 types de loadbalancing qui sont appelés “Director” :

Varnish sait gérer l’éviction d’un backend lorsqu’il est indisponible. Cette fonctionnalité est d’autant plus utile quand nous activons le “probe” sur les backends.

backend server1 {
   .host = "server1.example.com";
   .probe = {
     .url = "/";
     .interval = 5s;
     .timeout = 1s;
     .window = 5;
     .threshold = 3;
   }
}

Varnish dispose aussi d’un mécanisme pour palier complètement à la défaillance d’un backend ou d’un Director. Nous appelons cela “Grace mode” ou “Saint mode”. Ces termes cachent la possibilité de servir un contenu caché même x minutes après la TTL en cas de non réponse d’un serveur. Il est aussi capable d’aiguiller une requête vers un autre serveur répondant correctement quand le serveur cible initial donne des réponses HTTP 500 à cause d’une trop grande charge par exemple.

Reverse Proxy

Nous avons vu que Varnish se place devant toute notre infrastructure. Il va permettre de masquer complètement l’architecture déployée en utilisant toute la puissance de Reverse Proxy qu’il met à notre disposition.

En fait, il nous permet de faire un découplage complet entre l’organisation des URIs d’appels et l’organisation de leurs traitements sur l’infrastructure.

Voici un exemple d’une requête cliente que nous arrivons à aiguiller avec Varnish vers un bucket S3 public du nom de “ressources” et l’aiguillage prend en compte ce qu’il y a dans le nom du host de la requete :

set req.backend = backend_s3;
if(req.url == "/ressources1.xml") {
  set req.url = regsuball(req.http.host,
              "^(?:.*[.])?([a-z]+)[.](?:net|com)$", "/ressource1.\1.xml");
}else if(req.url == "/ressource2.txt") {
  set req.url = regsuball(req.http.host,
              "^(?:([a-z]+)[0-9]*[.])(?:([a-z]+)*[.])[a-z]+$","/ressources.\1.\2.txt");
}
set req.http.host = "resources.s3.amazonaws.com";

backend  backend_s3 {
  .host = "ressources.s3.amazonaws.com";
  .port = "80";
  .connect_timeout = 5s;
  .first_byte_timeout = 3s;
  .between_bytes_timeout = 2s;
  .max_connections = 1000;
}

Sécuriser et nettoyage HTTP

Le protocole HTTP permet d’utiliser plusieurs types de méthodes (GET, POST, DELETE… etc). Ces méthodes peuvent être utilisées de différentes manières pour déclencher des actions spécifiques (cas de services REST) sur les services abrités sur les backends. Or la protection au niveau HTTP de ce genre de services est assez fastidieuse côté serveurs d’applications. Varnish va permettre de filtrer précisément ce qui doit passer et pour quelle utilisation. Nous allons donc limiter les effets de bords.
Imaginons que nous avons un service accessible uniquement en GET /service1/ et un deuxième /service2/ accessible lui en GET et POST nous allons écrire quelque chose comme ceci :

if (req.request != "GET" && req.request != "POST"){
  call error;
}

if (req.url ~ "^/service2"){
call service2;
}

if(req.request == "POST"){
  call error;
}

if (req.url ~ "^/service1"){
  call service1;
}

call error;

Dans cet exemple nous interdisons systématiquement tout ce qui n’est pas méthode GET ou POST. Ensuite pour une url qui commence par /service2 nous allons vers la routine qui va traiter le payload pour ce service. Puis nous bannissons la méthode POST et nous traitons les urls avec /service1 et enfin nous bannissons le reste.

Avec cette méthode aucune requête non prévue peut remonter vers un backend. Nous avons deux avantages :

Dans un deuxième cas de figure il peut être intéressant de normaliser les entêtes HTTP. Prenons l’exemple de l’Accept-Encoding. Varnish préconise de le normaliser ainsi :

if (req.http.Accept-Encoding) {
  if (req.http.Accept-Encoding ~ "gzip") {
    set req.http.Accept-Encoding = "gzip";
  } elsif (req.http.Accept-Encoding ~ "deflate") {
    set req.http.Accept-Encoding = "deflate";
  } else {
    remove req.http.Accept-Encoding;
  }
}

Tout simplement pour éviter de créer des entrées cache différentes pour un même payload uniquement parce que tous les clients n’écrivent pas cet entête de la même façon.

Nous pouvons aussi enlever certains headers qui peuvent donner trop d’informations sur l’infrastructure. Pour S3 par exemple nous allons passer ces commandes dans le fetch :

unset beresp.http.x-amz-id-2;
unset beresp.http.x-amz-request-id;
unset beresp.http.x-amz-meta-s3cmd-attrs;
unset beresp.http.x-amz-meta-s3fox-filesize;
unset beresp.http.x-amz-meta-s3fox-modifiedtime;

Ou positionner des entêtes plus personnelles :

set beresp.http.Server = « ServeurPerso »;

La dernière petite chose à penser pour le nettoyage réside dans le positionnement d’un content-type correct pour toutes des ressources. Cette opération se fait de la même manière que pour le nettoyage des headers en positionnant “set beresp.http.Content-Type” par groupe de ressources.

De par ces fonctionnalités, Varnish est capable d’assurer l’orchestration de la haute disponibilité d’une architecture. Il est capable de détecter les backends défaillants et même de les remplacer en s’appuyant sur son cache. Il va les protéger en prenant en compte une grande partie de la gestion des erreurs 404.

Uniformisation des Logs d’accès

Le process “varnishd” ne produit aucun log. Il se contente d’écrire les informations dans des segments de mémoire partagée. Ces segments sont consommés par des outils comme varnishadm, varnishlog ou encore varnishncsa. C’est principalement varnishncsa qui nous intéresse. C’est ce process qui va lire les informations et créer un fichier de log au format NCSA. L’avantage ici est énorme. Nous pouvons décharger les serveurs d’applications et front http de la production de ces logs. De plus ces logs seront moins éparpillés (quoi que, avec l’utilisation de syslog-ng ça ne soit pas un problème). Enfin les logs seront tous normalisés qu’ils soient sur Apache, Tomcat, JBoss ou encore lighttp et NginX. Nous pouvons donc penser uniquement aux traitements que nous allons bien pouvoir leur faire subir et ne plus passer du temps à tout reformater. Cette considération prend tout son sens quand on commence à atteindre plusieurs gigas de logs d’accès par jour.
Depuis la version 3.0, Varnishncsa permet de ne pas suivre la norme NCSA et nous laisse le choix du format de sortie.

Laurent ROUX

Le but de cet article est de montrer comment avoir un référentiel des instances disponibles sur un compte Amazon (ou autre) avec toutes les informations qui vont bien sans devoir utiliser la console web Amazon. Cette solution permet de pousser l’automatisation un cran plus loin en proposant une liste exhaustive que l’on peut automatiser et la possibilité d’avoir une liste des serveurs disponibles en une ligne de commande pour n’importe quel Devops allergique aux opérations sur navigateur web.

Dans le but de rester élastique dans la démarche, nous allons utiliser deux fonctionnalités DNS des plus intéressantes qui sont :

Nous allons aussi nous aider des API Amazon et tout ça dans un environnement Linux. Notre DNS va donc servir de base de données pour référencer les machines via leurs IP privées.

Liste des pré-requis

Un serveur T1-Micro sur Amazon servant de DNS est largement suffisant. Le package BIND9 doit être installé. Sachant que sur une infrastructure nous préférons utiliser des noms à la place des IP, l’utilisation d’un DNS est fortement conseillée. De plus, la configuration des différents éléments techniques d’une plate-forme est nettement plus souple en utilisant des noms.

Configuration

Pour effectuer des requêtes nsupdate sur un DNS il faut autoriser les IP des machines qui ont le droit d’émettre ces requêtes vers notre DNS (nsupdate et axfr). Ensuite il faut placer les bases du DNS (fichiers db.xxx) dans un endroit ou le process bind a le droit d’écrire. Pour des raisons de sécurité, il est hors de question que ce process puisse avoir un accès en écriture dans le répertoire /etc/ nous allons donc déplacer ces fichiers dans /var/cache/bind/.

Elements de Configuration DNS

Dans le fichier named.conf.local dans la section de la zone que nous voulons contrôler il faut ajouter l’ip de la machine autorisée à faire les requêtes nsupdate :

allow-update { xxx.xxx.xxx.xxx; };

Les requêtes AXFR sont autorisées dans ce même fichier de configuration en ajoutant l’ip des serveurs autorisés dans la sections “allow-transfer” de la zone.
Dans cette même section nous allons déplacer le fichier de la zone en modifiant son chemin :

file « /var/cache/bind/db.xxxx.yyyy »;

Démarche

Une fois cette opération réalisée nous pouvons utiliser les API Amazon pour récupérer les informations qui concernent une instance (par exemple, nous utiliserons ec2-describe-instances dont la documentation est à l’adresse suivante :  DOC API).
Les informations que nous allons récupérer (security groupes, Key, EBS ID…..), vont être réorganisées pour ensuite être injectées dans le DNS sous la forme d’enregistrements TXT en plus de l’enregistrement A utilisé pour référencer une adresse.
Pour réaliser une mise à jour automatique du DNS il est préférable d’exécuter une instruction de “delete” avant l’ajout d’un enregistrement. Vu que nous sommes sur un DNS qui sera utilisé pour les zones de notre infrastructure nous allons prendre en compte les trois enregistrements suivants :

Pour enlever les enregistrements précédents (dans le cas ou le serveur est déjà référencé ou pour enlever le serveur).

nsupdate
> server monserverdns.domain.com
> zone domain.net
> update delete monserver.domain.net A
> update delete monserver.domain.net TXT
> update delete zzz.yyy.xxx.www.in-addr.arpa. PTR
> send

Ensuite on enregistre le serveur.

nsupdate
> server monserverdns.domain.com
> zone domain.net
> update add monserver.domain.net 86400 IN A www.xxx.yyy.zzz
> update add monserver.domain.net 86400 IN TXT informations sur le serveur
> update add zzz.yyy.xxx.www.in-addr.arpa 86400 IN PTR monserver.domain.net.
> send

Nous partons du principe que le DNS est bien déclaré au niveau du fichier /etc/resolv.conf.

Une fois tous les enregistrements en place il suffit de passer la commande suivante pour que la liste apparaisse :

dig @ip_du_dns axfr domain.net

sh-3.2# dig @10.211.55.5 axfr test.net
; <<>> DiG 9.7.3-P3 <<>> @10.211.55.5 axfr test.net;
(1 server found)
;; global options: +cmd
test.net. 604800 IN SOA dns. root.test.net. 4 604800 86400 2419200 604800
test.net. 604800 IN NS dns.
test.net. 604800 IN A 10.211.55.5
test.net. 604800 IN AAAA ::1
s1.test.net. 86400 IN A 1.2.3.4
s1.test.net. 86400 IN TXT « tout » « ce » « que » « l » « on » « peut » « dire » « sur » « un » « serveur »
test.net. 604800 IN SOA dns. root.test.net. 4 604800 86400 2419200 604800
;; Query time: 19 msec
;; SERVER: 10.211.55.5#53(10.211.55.5)
;; WHEN: Mon Jan  9 16:03:56 2012
;; XFR size: 7 records (messages 1, bytes 237)

Nous touchons au but. Il suffit maintenant d’exécuter la même commande avec un grep sur “TXT” pour récupérer la liste qui nous intéresse.

Avec la commande suivante nous allons enlever l’enregistrement TXT du DNS :

nsupdate
> server monserverdns.test.com
> zone test.net
> update delete monserver.test.net TXT
> send

sh-3.2# dig @10.211.55.5 axfr test.net
; <<>> DiG 9.7.3-P3 <<>>
@10.211.55.5 axfr test.net;
(1 server found);;
global options: +cmd
test.net. 604800 IN SOA dns. root.test.net. 5 604800 86400 2419200 604800
test.net. 604800 IN NS dns.
test.net. 604800 IN A 10.211.55.5
test.net. 604800 IN AAAA ::1
s1.test.net. 86400 IN A 1.2.3.4
test.net. 604800 IN SOA dns. root.test.net. 5 604800 86400 2419200 604800
;; Query time: 2 msec
;; SERVER: 10.211.55.5#53(10.211.55.5)
;; WHEN: Mon Jan  9 16:15:30 2012
;; XFR size: 6 records (messages 1, bytes 183)

Nous avons donc une base de données (le serveur DNS) qui va nous servir de référence pour y placer toutes les informations des instances tirées des API Amazon.
Cet article n’aborde pas le côté sécurité de bind et ne fait donc pas référence à la gestion de clé pour les requêtes nsupdate.

Laurent ROUX

Urbandive is an immersive view service launched by the French YellowPages which allows you to travel in cities in France thanks to a 360° view. Urbandive focuses on providing high definition pictures and accurate professional and social content. One of the biggest jobs was to enable a fast scalable architecture, because it was really difficult to forecast the traffic load at production time. Traffic load may be influenced if the service receives attention from users as a result of advertising.

Below you will find a summary of the goals we achieve by using a Ruby scheduler built on top of Puppet on AWS to create a complete infrastructure.

Workflow & XTR-Lucid
Our scalability combo is : a home-made Ruby scheduler (XTR-Lucid) to deal with AWS APIs + the Puppet Master to install services and configure EC2 instances and keep them up-to-date during all the production time. This leads to full automation.

Here is the workflow (for the creation step, there are other workflows for stop/reboot/health-check/…) of our automation tool. The dashboard allows you to select a template (which contains the following informations : AMI id, instance type, availability zone, key, list of security groups, list of EBS – from snapshots or not -, …) and to set a name for the instance in the « create » workflow.

This schema gives the general idea of how it works.

To be more accurate and to explain the workflow just a bit :

• The scheduler can be outside or inside of AWS.
• First an action file is put into the TODO directory, by the web application (simple rhtml dashboard) or by the monitoring tool directly. For posting files from the monitoring tool, we will have to define thresholds after some weeks of use of the application. At this time, we have not enough data feedback as we just commenced production.
• The action file is then processed by the scheduler :

1. Connection to AWS and request to start an EC2 instance from the AMI.
2. Scheduler checks that instance is running, EBS (Elastic Block Store) are available, then in-use, and eventually that EC2 TCP stack is up and SSH is OK. Then it connects to the brand-new instance.
3. Puppet client is installed and started, so it sends a certificate request to the master.
4. Puppet client is stopped to avoid any interaction.
5. Connection to the PuppetMaster : update the main files (nodes files of PuppetMaster, « /etc/hosts » file, roles file of Capistrano) and then accept the certificate request of the client.
6. Capistrano updates the « /etc/hosts » file on all instances of our infrastructure as soon as a new EC2 instance comes up (or down), without having to trigger (puppetrun) the simultaneous « pull configuration » of all the Puppet clients.
7. Connection to the new instance.
8. Puppet client is started.
9. Puppet client connects to the master and authenticate. Then it gets what it needs to install and configure the new instance.
10. The installation occurs on the new instance that will be soon available.

• The scheduler doesn’t wait until the instance is fully configured to end the task : installation by Puppet is asynchronous. The scheduler just ends by updating its repository and the monitoring tool.

Technical note 1 : we use Capistrano mainly for application deployment. In the above case (create instance), we use it to update the « /etc/hosts » file on all instances of our infrastructure as soon as a new EC2 instance comes up (or down – it is the same use for stop instance), without having to trigger (puppetrun) the simultaneous « pull configuration » of all the Puppet clients (bad idea ;ob). That’s just a little tip for this workflow.

Technical note 2 : the Ruby scheduler works in asynchronous mode (for security reasons & to be called by other tools – like a monitoring one) by creating action files from the web application in the TODO directory (which can be filled by the monitoring tool for auto-scalability) checked every minute by a CRON which calls the heart of the automation tool.

Technical facts

• We have actually 40 – 50 servers, that’s our base, but we probably will go higher when the traffic will come with marketing campaigns.
• We use Lucid Lynx Ubuntu OS (from a standard AMI powered by Canonical).
• We use the PuppetMaster installed on Apache with Phusion Passenger to increase performances.
• We took Puppet (standard version) right from the Ubuntu repositories packaged in the AMI.

Why using Puppet (and especially on AWS) ?
Consistency & Flexibility
We have multiple services, so we need to be sure that each group of servers is consistent in terms of configuration. If we need to push a quick change on all nodes of a type at a given time, we can even push (trigger « pull », to be more accurate, with puppetrun) this new setting from the PuppetMaster without waiting the pull of Puppet client (30min period) and we are sure that this one is pushed everywere it is needed.
AWS offer AMIs to « snapshot » an instance and clone this one as many as we want. This is very good for developpement, load tests, .. But when we come into production, we cannot build another AMI each time we do a change on a setting and deploy again EC2 instances from the new AMI. We need something flexible to patch our configurations quickly, keeping consistency at all times.

Scalability & Ease
This is a new Internet service which can have a load peak at anytime depending on marketing campaigns. But we have to deal with financial things too. So we keep a base and have to start quickly full configured up-to-date instances within a few minutes. We achieve this by writing a home-made ruby-script-based scheduler (XTR-Lucid) that deals with AWS APIs to launch/stop EC2, add EBS (empty or from snapshot), add/remove to/from ELB, add/delete the new/old host to/from our monitoring tool, … AWS EC2 instances are kept in a repository on our Ruby scheduler. Then our tool lets Puppet take over which ensures for each brand-new instance started from a standard Lucid Lynx AMI that all services, configurations, security rules are installed/applied. So with the feedback of our monitoring tool, the infrastructure can grow and decrease alone (depending on the thresholds set) or we can deploy and stop instances in just one click on our web dashboard.

Operating
In such a project, there is a lot of various services to monitor for the Ops team (And… Yes ! Ops team is always essential, even with automated infrastructure ! :o)). So this is important to capitalize upon knowledge in Puppet descriptors and XTR-Lucid repository and templates, so that by simply reading the descriptors/repository/templates, the whole team knows all what it needs to know at a glance (no need to look everywhere). Things become a lot easier.

Portable Infrastructure
Because of the diversity of services run in the project, maybe not all will fit into AWS in a long term experience (over one year). Once we have real-life feedback on traffic, some services will stay on AWS, others, maybe, will migrate into our physical datacenter. So it will be easier to migrate because all the configuration is concentrated in Puppet descriptors. This enables us to re-deploy easily a brand-new infrastructure on another plateform (even if it is not in the Cloud).

I hope you enjoyed this. You can find here some more information on the way the Ops job is evolving, based on this experience (among others) : Solutions Linux / Open Source 2011 – Le métier de l’Administration Système avec le Cloud Computing (FR). These slides are the ones used for a talk I gave at Solution Linux 2011 (France).

Frédéric FAURE @Twitter @Ysance

De retour du salon Solutions Linux / Open Source 2011 (salon professionnel annuel dédié aux logiciels et solutions libres pour les entreprises), je publie les slides que j’ai présentés en compagnie d’Omer SHALA (Mappy) lors d’une des conférences du salon ayant pour sujet le Cloud Computing. Cette présentation porte sur l’évolution du métier de l’Administration Système avec l’utilisation du Cloud Computing. Nous avons pris comme support notre expérience du projet UrbanDive, le nouveau service de vue immersive en zone urbaine du groupe PagesJaunes.

Omer SHALA, responsable de l’infrastructure du projet, a tout d’abord exposé le contexte du projet, puis a expliqué les éléments de décision qui nous ont amené à choisir le Cloud Computing (et en l’occurrence les Amazon Web Services – AWS) pour mettre en place nos services. Il a finalement fait une synthèse de son expérience de la mise en place de cette infrastructure avec les services d’Amazon (de type IaaS – Infrastructure as a Service), par rapport à ses expériences avec des infrastructures plus classiques (en datacenter) au sein du groupe PagesJaunes.

J’ai repris la seconde partie de la conférence et ai exposé ma vision de l’évolution de l’administration système avec l’utilisation de solutions de type Iaas. Pour finir, j’ai présenté ce que nous avons mis en place pour optimiser le potentiel des services Amazon, notamment via l’automatisation :

• avec le développement d’un ordonnanceur Ruby (XTR-Lucid) pour interfacer les APIs proposées par Amazon et gérer les cinématiques de communication (création/suppression d’instances métier EC2 et disque réseaux EBS, déploiement des services, …) avec les AWS,
• avec l’utilisation d’outils Open Source comme le gestionnaire de configuration centralisé Puppet ou bien le scripteur/exécuteur de tâches Capistrano.

Je vous laisse visionner cette présentation en dessous !

Nous avons également inclus dans cette présentation la matrice de décision sur laquelle nous nous sommes basés pour décider de l’adoption du Cloud Computing pour la mise en place de l’infrastructure.

Frédéric FAURE @Twitter @Ysance

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