Hop, à peine le temps de reposer les Googles Glass de soleil, de ranger la i-crème solaire, c’est déjà la rentrée. Allez, ne déprimez pas, on était au Paris JUG mardi soir et on va tout vous raconter. Au programme : Google Cloud Platform dans une nouvelle salle. Mine de rien, on entame la 7ème saison du Paris JUG.
Tout d’abord, l’équipe du Paris JUG change un peu. C’est maintenant Charles Sabourdin qui s’occupe des soirées, Mister Quizz pour les intimes, avec une nouvelle équipe de bénévoles. Les soirées du Paris JUG (créé en février 2008) auront lieu désormais à l’ESIEA, dans un amphi sympa, qui permet d’accueillir environ 230 personnes.
J’aime bien la rentrée. On retrouve les copains que l’on a pas vu depuis 1 mois. Untel n’a pas grandi, un autre a perdu encore plus de cheveux, et l’autre nous montre sa superbe montre ramené de Google.IO, bref ça sent le cartable en cuir et les chaussures neuves. Et moi j’aime bien.
La soirée était animée par David Gageot et Didier Girard. David, freelance, blogger et geek. Didier, directeur des opérations chez SFEIR et Beek (Boss + Geek). La soirée ce soir c’est quand même une bonne grosse promo de Google Cloud Platform.
Alors on cloud…
A l’exercice de la main levée, assez peu de personnes finalement utilisent du Cloud computing pour le développement et pour les mises en prod. Une plus grosse majorité est simple utilisateur. Mais globalement, j’étais étonné de voir que peu de développeurs dans la salle avait déjà utilisé Amazon AWS ou Google Cloud Platform.
Didier Girard pour expliquer le cloud prend l’image de cette fameuse course d’endurance, le Marathon des Sables. Il s’agit d’effectuer 240km dans le désert, en auto-suffisance. Cela veut dire que vous devez donc prévoir exactement la quantité de nourriture pour une semaine. L’informatique classique telle qu’elle est encore pratiquée aujourd’hui demande de connaître à l’avance la quantité de serveurs et de logiciels nécessaires pour un projet. Bien souvent, c’est même la prod qui décide de la version de Java, d’utiliser telle ou telle base de données, et tel serveur d’application. Or on peut penser que cela représente un gaspillage pour certains projets, ou un risque opérationnel important pour d’autres.
Le Cloud à contrario permet de se concentrer sur l’architecture. C’est un immense supermarché, dans lequel le développeur peut piocher uniquement ce dont il a besoin. Cela ne supprime pas le rôle du sys-admin (particulièrement si vous faîtes de l’IaaS, comme avec Amazon AWS).
Les espèces qui survivent, c’est celles qui sont le plus adaptable au changement. Si Darwin était DSI, est-ce que cette phrase serait vraie ? Le Cloud représente un espace de choix et de liberté. La vision est orientée ressources/usages/services et permet à l’entreprise de ne pas devoir internaliser une infrastructure, de maintenir un capital matériel et humain pour faire uniquement de la prod. C’est moche pour les sys-admins et les équipes d’exploitation, mais c’est une réalité.
De là à dire que le Cloud va tuer les S.I internes… moi je n’y crois pas une minute. Par contre, pour ceux qui auront réussi à utiliser une approche Cloud, on peut penser que ce sera un avantage compétitif. Mais Didier est trop dithyrambique et je crois plutôt que la vérité se situe entre sa vision, et ce que les entreprises pourront faire dans les 5 ans qui viennent.
Maman j’ai peur
Le Cloud ça fait super peur. Nos données super-secretes comme le nombre de visiteurs sur notre site ne doivent pas fuiter dans la nature. Vaut mieux qu’elles restent sur Xiti ou Google Analytics, au moins c’est sûr… c’est pas du Cloud.
Alors il y aurait un problème de confidentialité. Cependant comme le dit justement Didier Girard, regardez l’affaire Snowden. La fuite est venue de l’intérieure. On parle de la NSA…
Le problème de la confidentialité des données doit être abordé simplement en regardant le niveau de confidentialité :
- les non-classifiées, sans caractère confidentielle ou secret
- les données confidentielles
- les données secrètes.
Ce qui est secret ne devra pas être sur du Cloud. D’ailleurs, est-ce qu’il est intelligent d’avoir ces données au format numérique ? Est-ce que le portable du PDG est assez sécurisé ? Et sa boîte email avec Exchange ? Bref avant de crier au loup, il convient de revoir quels types de données peuvent aller sur le Cloud sans problème.
Il y a ensuite le problème de la territorialité des données. A cela, les grands du Cloud proposent des hébergements en Europe. Si vous voulez vraiment du Français, tournez-vous vers Clevercloud ou Numergy. Les solutions existent.
Le premier de la classe : Google Cloud Platform.
Enfin le premier… certainement pas. Google Cloud Platform c’est la réponse de Google à Amazon Web Services. AWS pour les intimes. Et force est de reconnaître que Google ne propose pas autant de services qu’AWS. Mais cependant, particulièrement pour certains services, il est vraiment temps de s’intéresser à GCP.
Didier et David parlerons d’une partie de l’architecture de GCP :
- Compute
- Storage
- App Services
Sur la partie Compute, il existe 2 produits : Google AppEngine et Compute Engine. Le premier est une solution type PaaS, à la Heroku, avec cependant des contraintes assez fortes sur le code et le type d’API que vous pouvez utiliser. 4 ans après sa sortie, AppEngine n’a pas autant explosé que ce que nous pensions. Lors de sa présentation où j’avais été invité, en avril 2009, et de ce que j’en ai vu à Devoxx 2009, le buzz dans la communauté des développeurs reste assez discret.
Ce qui par contre me semble plus intéressant, c’est Compute Engine. C’est LA réponse de Google à Amazon EC2. Alors quelles différences ? Pourquoi partir sur GCE ? Et bien on a découvert quelques trucs intéressants… comme le support du déploiement de conteneur Docker. Et ça, c’est intéressant.
Compute Engine est une solution de déploiement sur machines virtuelles, de type IaaS. A cela, s’ajoute un ensemble de services, comme la persistence, via Cloud SQL, Cloud Datastore, Cloud Storage et BigQuery.
Les caractéristiques et l’intérêt de GCE, c’est une garantie de performance, le réseau de Google, un paiement à la minute d’utilisation, la possibilité de déployer plusieurs VMs sur différents centres de données, des certifications ISO quant aux niveaux de sécurité et d’encryption des données et enfin, la possibilité d’installer assez rapidement plusieurs machines.
A cela, c’est exactement la même offre qu’Amazon EC2, modulo le fait que l’on parle de Google. Mais bon, Amazon quoi.
Ce qu’il faut surveiller
Là où par contre je pense que Google a une carte à jouer, c’est sur la gestion des conteneurs. Pour faire simple, il est désormais possible de déployer du Docker sur GCE. Bon, Docker c’est le programme de l’année dernière. Si vous avez oublié, je vous invite à relire quelques articles sur le Touilleur Express.
Une solution intermédiaire entre du PaaS et de l’IaaS qui a de l’avenir, c’est le A Container in Da Cloud As a Service (ACDC-AS). Highway to hell, un truc que j’écoutais lorsque j’étais jeune (hier).
Et là, David Gageot en a justement montré pas mal d’usages, avec des démos plutôt convaincantes. L’idée est assez simple : vous pouvez désormais penser non plus « je déploie mon application » mais « je déploie mon conteneur avec mon application et ses services ». C’est un moyen simple pour pouvoir démarrer rapidement un volume important de services. L’intérêt aussi étant d’avoir exactement le même environnement en prod, qu’en développement. Docker permet justement de définir cela précisément.
Les petits bémols, c’est que le déploiement d’un conteneur demande pas mal de chargements. Comptez plusieurs centaines de méga pour une image… ce qui s’ajoute à la VM qui fait tourner votre application. Mais le gain est là.
Le Cloud répond aux développeurs qui souhaite avoir un environnement de travail performant. Vous pouvez travailler avec une machine avec 16 coeurs et 240 Go de mémoire. Pour faire tourner Java, c’est limite, mais ça marche.
Cela étant dit, par expérience il est plus intéressant d’avoir une ou deux grosses machines, qu’un paquet de petites machines pour faire des traitements.
David Gageot a fait ensuite quelques démonstrations avec Kubernetes. Il s’agit d’une solution de gestion de conteneurs (à la docker) dans le Cloud. Oui, c’est une solution pour déployer des paquets de Docker dans le Cloud. A suivre, mais sans doute réservé à des usages assez rares.
C’est la récré
Après une pause buffet, offert par le Paris JUG, on reprend et nous enchaînons les démonstrations, les questions-réponses et pas mal de démonstrations encore. Ce qui m’a particulièrement intéressé, c’est Big Query. Et là, pour le monde du décisionnel, il y a un produit intéressant. Didier montre un exemple avec 31 millions de lignes de données, sur lequel des requêtes en temps réel ne prennent que quelques secondes. Le truc qui tue ? C’est le prix.
Big Query (enfin Cloud storage) facture d’une part le volume de données stockés (2 centimes le Giga), et d’autre part le traitement de celles-ci. Vous payez à la requête.
Imaginez la tête de ce DSI qui a acheté de coûteuses machines pour y installer du Business Object, lorsqu’en face un stagiaire lui sortira ses dashboards calculés avec Google Big Query pour 4 euro le rapport. Tiens, prend un mouchoir sponsorisé par Oracle.
Bref, ce qu’il fallait retenir :
- Google Compute Engine est d’abord une réponse type IaaS à Amazon
- Il est à mon avis plus simple de débuter avec GCE, qu’avec Amazon EC2 pour les développeurs
- Un développeur qui n’a pas vraiment de connaissances d’administration système ne sera pas capable d’utiliser GCE correctement
- Les Sys-admin ont encore du boulot, s’ils peuvent ajouter la carte Cloud à leur CV
- Les prix me semblent moins chers que chez Amazon, à performance équivalente
- Big Query c’est vraiment bien pour du décisionnel. A comparer avec Redshift chez Amazon.
- Didier aime beaucoup Google
- David ce soir là n’avait pas la baraka pour les démos
Sur ce, bonne rentrée à tous
0 no like
Bonsoir Nicolas,
Sauf erreur de ma part, il me semble que le jeu de données pour Big Query contenait 350 millions de lignes.
Attention au vol de photos sur son iCloud 🙂
Logue vie au Paris JUG.