Pour la première fois cette année, je me suis décidé à me rendre à un meetup organisé bénévolement à Sophia Antipolis, plus exactement, dans les locaux de Teach On Mars. Ce 26ème meetup organisé par cette équipe avec pour organisateur Laurent Pasterolli  eut pour sujet les différentes applications d’AWS possible dans le cadre de développement mobile.

N’étant pas un devops, et je dois l’admettre que je ne suis pas un configurateur né (je suis de ceux qui préfère installer une distribution Linux en cliquant sur next plusieurs fois ~), j’ai eu peur de ne pas pouvoir suivre le meetup car AWS peut-être un outil compliqué à présenter.

Découpé en 2 conférences de 20 à 30 minutes ; la première d’entre elles concernait l’utilisation d’une fonctionnalité AWS permettant de redimensionner une image, la seconde concernait l’intégration de AWS avec des exemples afin de démontrer la facilité avec laquelle il était possible de travailler avec Amazon Web Service.

Redimensionner vos images avec AWS

Cette présentation proposée par Mickael Lopez concernait l’utilisation de la stack AWS afin de se servir d’une lambda AWS permettant le redimensionnement d’une image.

Les explications sur les services Amazon utilisés furent les suivantes :

  • Cloud Front : Un service Amazon qui a pour but d’accélérer la distribution de donnée statique (telle que des images). Utiliser comme un cache dans le cadre de ce cas d’utilisation.
  • API Gateway : Service Amazon permettant la publication de service, un point d’entrée unique pouvant être utilisé à la fois comme proxy et reverse proxy. Dans le cadre de ce cas d’utilisation, l’API Gateway redirige le message jusqu’à la lambda qui s’occupera du redimensionnement de l’image.
  • Lambda : AWS Lambda, service serveless proposé par Amazon. Il s’agit d’une portion de code qui peut être exécuté à la volé. AWS s’occupe de manager les ressources en fonction de l’utilisation d’une lambda. Ce qui implique une réduction globale des couts.

Une lambda doit être « hot » pour s’exécuter rapidement, c’est-à-dire qu’elle doit être utilisé avant de pouvoir fonctionner de manière optimale.

Suite à ces explications relativement basiques du fonctionnement d’AWS, une présentation concrète de l’utilisation de la stack AWS a été faite.

 

 

L’implémentation de ce cas d’utilisation peut être considérée pour n’importe quelle AWS Lambda nécessitant un contenu statique.

L’utilisateur requête là une image d’une taille spécifique à Amazon S3 (le cache), ce dernier ne le possède pas et répond donc un 404 (not found) à l’utilisateur. Ce dernier envoi donc une requête à l’API Gateway pour récupérer cette image. L’API gateway redirige ce message à une lambda AWS qui va avoir pour responsabilité de remplir le S3 avec l’image à la taille voulu. Une fois cela fait, le client requête une nouvelle fois le S3 qui retrouve son image.

Cette utilisation peut sembler basique mais est en réalité très intéressante de par le fait que cela ne requiert pas énormément de travail (d’autant plus que la lambda dont nous parlons existe de base dans AWS).

Mais sans compter uniquement la simplicité d’implémentation (au final ce n’est que des services AWS sans réel code propriétaire), le plus intéressant est la scalabilité de cette fonctionnalité. En effet le S3 duplique les données dans plusieurs data centers différents et assure un accès aux données requêtées. De la même manière l’API Gateway est reconnue pour sa résilience. Et les lambdas, de par le simple fait qu’il ne soit exécuté qu’au moment de la requête (serverless), en font des éléments résilients de base.

Il semblerait que le prix des services AWS soient généralement plus bas que la location d’infrastructure. Ce qui semble logique quand il s’avère d’utilisation de lambda (et donc utilisation de ressource uniquement quand nécessaire) cependant même le S3 qui est un cache résilient et avec un mirroring des données est moins cher que la location d’un simple disque. C’est une information qu’il est intéressant de partager de par le fait que cela me semble contre-intuitif.

Amazon Web Service écosystème

Cette seconde présentation effectuée par Olivier Tosello, a eu pour objectif de nous donner un aperçu plus global des possibilités d’utilisation de AWS ainsi que les manières d’intégrer ces services dans le cadre de développement mobile en nous donnant un exemple que tout le monde a eu a implémenter une fois dans sa vie. Un système de management de compte (connexion, déconnexion, création de compte, mot de passe oublié etc…).

Lors de cette présentation les services suivants ont été explorés :

  • Cognito: Service de gestion d’utilisateur serverless permettant une connexion via une identité fédéré (facebook, twitter etc…)
    • Cognito Identity, ce service fut la pièce centrale de cette présentation car cela permet de faire absolument tout ce dont nous avons besoin concernant des utilisateurs, de la création de compte aux différentes sécurités. Lors de la présentation de la configuration, il apparait clairement qu’une utilisation basique est possible pour des utilisateurs néophytes (tel que moi) mais aussi qu’une utilisation avancée et très complexe peut être envisagé (afin de gérer, par exemple une sécurité pour des utilisateurs se connectant avec des coordonnées géographiques différentes pouvant être considérer comme un vol de compte).
    • Cognito Sync : Ce service n’a pas été exploré, mais permet de stocker des données et est notamment utilisé afin de stocker les sauvegardes dans le cadre de jeux mobiles.
  • Aws Amplify : Un facilitateur d’intégration, des vues préexistantes avec des communications avec les services AWS déjà implémentés. D’après l’expérience d’Oliver Tosello, même si tous ce qui concerne le back-end est gérer par Cognito et donc par AWS, le fait d’implémenter ce back-end avec des vues et de comprendre comment utiliser et configurer AWS peut prendre entre 2 et 3 mois pour un utilisateur commençant «from scratch». Cette manière de faire a pour avantage de donner une liberté absolue sur les vues ainsi que les transitions et l’esthétique du produit. Avec l’utilisation d’AWS, implémenter les fonctionnalités basiques d’une gestion de compte ne prend pas plus d’une après-midi. Et les implémentations les plus avancées possibles peuvent être effectuées en une semaine. Ce qui est un gain de productivité impressionnant. Cependant, le défaut est bien évidemment que les personnalisations des vues sont très limitées.

 

En conclusion, je dirais que ce meetup était très intéressant, d’une part de par les présentations qui révélaient un contenue intéressant, sans pour autant entrer trop dans des détails techniques spécifiques à la configuration (chose que je craignais en me rendant sur place) et permet donc à n’importe qui d’entrer dans le sujet, ce qui en fait une bonne conférence. D’autre part, comme on peut s’y attendre à ce genre d’évènement, l’ambiance est très agréable, les gens sont ouverts à la discussion (les pizzas sont bonnes :p). Bref, une belle opportunité de réseaux-té et d’apprendre des choses.

En tout cas c’était ma première expérience de meetup sur Sophia Antipolis, et sûrement pas la dernière et j’espère vous voir aux suivantes 🙂

Merci à Quentin 🙂