Dossier veille techno : retour sur le dernier AWSomeDay

Dossier veille techno : retour sur le dernier AWSomeDay

Dossier veille techno : retour sur le dernier AWSomeDay (AWS)

Vous connaissez sûrement le principe : pour promouvoir son offre Cloud, en faire comprendre les fonctionnalités spécifiques et sa puissance face à sa concurrence, AWS organise plusieurs fois par an des journées de formation à destination des développeurs, des clients et prospects potentiels, ou plus largement de toute personne intéressée par cette techno.

Confrontés aux mêmes challenges business et techniques, c’est aussi le moment pour les invités d’échanger sur les différents projets cloud du moment.

INOCO était à la dernière édition du 31 aout 2018 à la Tour Carpe Diem (La Défense), et vous livre les dernières infos !

Pour rappel, AWS a été créée en 2006 avec la volonté de donner accès aux clients à la technologie alors déjà utilisée par Amazon, qui a pour but de faciliter les expérimentations (appelé AB Testing chez AWS). En pratique, le site testait à la volée des changements (nouvelle couleur des boutons par exemple) pour analyser l’impact sur le comportement des utilisateurs, et ainsi choisir ce qui est le plus impactant. Pour y arriver, on utilisait les notions de découplage liées aux microservices et aux API.

Depuis, AWS s’est développée de façon exponentielle : il y a aujourd’hui 18 « régions », c’est-à-dire zones métropolitaines dans lesquelles AWS est installée. Parmi ces régions, 4 sont désormais en Europe : Londres, Dublin, Francfort, et depuis très récemment, Paris. A l’intérieur de ces régions, il y a ce que AWS appelle des « zones de disponibilités », autrement dit un ou plusieurs datacenters, connectés entre eux grâce à un réseau en faible latence, ce qui permet d’offrir aux clients une infrastructure résiliente si un datacenter tombe. A titre d’exemple, la région Paris offre 3 zones de disponibilités, éloignées physiquement les unes des autres pour répartir au mieux le risque.

Autre développement notoire : AWS continue d’accélérer son rythme d’innovation, en lançant chaque année plus de fonctionnalités que l’année précédente. Pour 2017, AWS annonce 1430 nouvelles features mises à disposition de ses clients. La logique de ces fonctionnalités se veut « customer backwards » ; autrement dit, les idées d’innovation sont issues des demandes clients. Cette politique est bien propre à Amazon, à l’opposé par exemple de ce que propose Google qui considère, à l’inverse, que ce que demande les clients n’est pas forcément ce dont ils ont besoin.

La situation actuelle au sein des business lines et des DSI est à la fois pressurisant et paradoxal : il s’agit de faire moins cher, plus vite, et de continuer à innover. Face à ce constat, le cloud public apparait comme une réponse adaptée, qui permet l’innovation & le prototypage, la structuration & l’automatisation, la robustesse & la fiabilité à l’échelle. Cela permet d’avancer en « learning by doing » et d’assumer le droit à l’erreur puisqu’on peut lancer un projet, puis le détruire ou le scaler facilement en fonction des résultats.

Pour passer au Cloud, 3 patterns se dessinent :

• System on record, c’est-à-dire une migration des applications telles quelles. Les enjeux ici s’articuleront autour de l’hébergement évolutif et la migration de masse
• System of differentiation, autrement dit opérer la transformation des applications afin de bénéficier pleinement des services managés de cloud : construction d’une chaîne CI/CD, organisation DevOps, approche microservices
• System of innovation, enfin, qui consiste à construire de nouvelles applications directement dans le cloud, donc « cloud native ». On parle alors d’innovation IT comme activité centrale et de cycles de vie automatisés by design.

De façon générale, il faut retenir que la transformation vers le Cloud n’est ni technologique, ni purement business : elle est globale et doit embarquer toute la stratégie de l’entreprise. Pour cette transition, on peut par exemple évoquer le modèle 70/20/10, théorisée par le Center of Creative Leadership. Ainsi, on peut considérer que la formation théorique, indispensable, devra pourtant représenter seulement 10% de l’investissement total. Sur cette partie, on pense par exemple aux cours de eLearning dispensés sur acloud.guru. Plus important que cet apprentissage formel, vient l’aspect social : on estime que 20% de ce que l’on apprend est issu des échanges avec ses collègues, ou des experts lors de meetups. Citons sur ce point plusieurs pistes, comme les Hashidays et les meetups du AWS French Users Group qui organisent souvent des rencontres. Enfin, pas moins de 70% de la montée en compétence doit être tirée par l’expérimentation et la pratique lors de projets dédiés. A ce sujet, les « GameDays » sont un moyen ludique de s’entrainer : inspirés du chaos engineering, ces jeux de rôles proposent de reproduire un environnement, pour automatiser et générer des pannes massives, à résoudre en équipe.

Et vous, comment gérez-vous la transition vers le Cloud ?