VT2017 Serverless Architectures - Revision history

Antoine.Boisadam: /* Synthèse */

2017-09-17T17:47:28Z

Synthèse

Antoine.Boisadam: /* Inconvénients */

2017-09-16T10:47:51Z

Inconvénients

← Older revision		Revision as of 10:47, 16 September 2017
Line 40:		Line 40:
	===Inconvénients===		===Inconvénients===

	* '''Dépendance au cloud provider''' : Effectivement, si le fournisseur ferme ou est ne fonctionne plus un temps, c'est vers vous que les utiliseurs se retourneront car votre application finale ne "fonctionne pas". De plus, si du jour au lendemain, le provider augmente ses prix (x2, x3, ...) il faudra payer ou ~~recoder~~ entièrement sa solution.		* '''Dépendance au cloud provider''' : Effectivement, si le fournisseur ferme ou est ne fonctionne plus un temps, c'est vers vous que les utiliseurs se retourneront car votre application finale ne "fonctionne pas". De plus, si du jour au lendemain, le provider augmente ses prix (x2, x3, ...) il faudra payer ou ré-implémenter entièrement sa solution.
	* '''Durée d’exécution''' : On a là deux problématique, quid du timeout et quid de la latence au démarrage ? C'est à dire, si la fonction met plus de 5 minutes à rendre un résultat, que ce passe-t-il ? Pour la latence au démarrage, comme il faut créer un conteneur à chaque exécution, les fournisseurs ne laissent pas pour l'instant un choix infini de langage exécutable. On retrouve souvent Javascript (Avec Node.JS) pour ces performances.		* '''Durée d’exécution''' : On a là deux problématique, quid du timeout et quid de la latence au démarrage ? C'est à dire, si la fonction met plus de 5 minutes à rendre un résultat, que ce passe-t-il ? Pour la latence au démarrage, comme il faut créer un conteneur à chaque exécution, les fournisseurs ne laissent pas pour l'instant un choix infini de langage exécutable. On retrouve souvent Javascript (Avec Node.JS) pour ces performances.
	* '''Non applicable à tous les projets''' : Pas de solution miracle, même si on peux appliquer une architecture serveless à plus de 90% des scénarios.		* '''Non applicable à tous les projets''' : Pas de solution miracle, même si on peux appliquer une architecture serveless à plus de 90% des scénarios.

Antoine.Boisadam: /* Synthèse */

2017-09-16T10:43:43Z

Synthèse

← Older revision		Revision as of 10:43, 16 September 2017
Line 25:		Line 25:
	Serverless ne signifie pas sans serveur '''mais''' que le serveur est invisible pour l'utilisateur. Il y a donc un impact sur les coûts de maintenance, mais aussi matériels.		Serverless ne signifie pas sans serveur '''mais''' que le serveur est invisible pour l'utilisateur. Il y a donc un impact sur les coûts de maintenance, mais aussi matériels.

			'''To Be Continued..'''
	TBC..

	==Avantages et inconvénients==		==Avantages et inconvénients==

Antoine.Boisadam: /* Synthèse */

2017-09-16T10:39:52Z

Synthèse

← Older revision		Revision as of 10:39, 16 September 2017
Line 21:		Line 21:

	La mise en place de serveurs, qu'ils soient hébergés dans l'entreprise ou chez un fournisseur en ligne, leurs configurations et le déploiement d'applications sur ceux-ci peut s'avérer très coûteux (en terme d'homme/temps et aussi matériel). C'est pour ces raisons que ces dernières années, les architectures dîtes serverless se sont démocratisées.		La mise en place de serveurs, qu'ils soient hébergés dans l'entreprise ou chez un fournisseur en ligne, leurs configurations et le déploiement d'applications sur ceux-ci peut s'avérer très coûteux (en terme d'homme/temps et aussi matériel). C'est pour ces raisons que ces dernières années, les architectures dîtes serverless se sont démocratisées.

	==Le principe==

	Une architecture serverless est une architecture où l'utilisateur n'a plus à gérer la moindre architecture. Il se concentre exclusivement sur la conception.		Une architecture serverless est une architecture où l'utilisateur n'a plus à gérer la moindre architecture. Il se concentre exclusivement sur la conception.
	Serverless ne signifie pas sans serveur '''mais''' que le serveur est invisible pour l'utilisateur. Il y a donc un impact sur les coûts.		Serverless ne signifie pas sans serveur '''mais''' que le serveur est invisible pour l'utilisateur. Il y a donc un impact sur les coûts de maintenance, mais aussi matériels.

	TBC..		TBC..

Antoine.Boisadam: /* Inconvénients */

2017-09-16T10:32:33Z

Inconvénients

← Older revision		Revision as of 10:32, 16 September 2017
Line 43:		Line 43:

	* '''Dépendance au cloud provider''' : Effectivement, si le fournisseur ferme ou est ne fonctionne plus un temps, c'est vers vous que les utiliseurs se retourneront car votre application finale ne "fonctionne pas". De plus, si du jour au lendemain, le provider augmente ses prix (x2, x3, ...) il faudra payer ou recoder entièrement sa solution.		* '''Dépendance au cloud provider''' : Effectivement, si le fournisseur ferme ou est ne fonctionne plus un temps, c'est vers vous que les utiliseurs se retourneront car votre application finale ne "fonctionne pas". De plus, si du jour au lendemain, le provider augmente ses prix (x2, x3, ...) il faudra payer ou recoder entièrement sa solution.
	* '''Durée d’exécution''' : On a là deux problématique, quid du timeout et quid de la latence au démarrage ? C'est à dire, si la fonction met plus de 5 minutes à rendre un résultat, que ce passe-t-t-il ? Pour la latence au démarrage, comme il faut créer un conteneur à chaque exécution, les fournisseurs ne laissent pas pour l'instant un choix infini de langage exécutable. On retrouve souvent Javascript (Avec Node.JS) pour ces performances.		* '''Durée d’exécution''' : On a là deux problématique, quid du timeout et quid de la latence au démarrage ? C'est à dire, si la fonction met plus de 5 minutes à rendre un résultat, que ce passe-t-il ? Pour la latence au démarrage, comme il faut créer un conteneur à chaque exécution, les fournisseurs ne laissent pas pour l'instant un choix infini de langage exécutable. On retrouve souvent Javascript (Avec Node.JS) pour ces performances.
	* '''Non applicable à tous les projets''' : Pas de solution miracle, même si on peux appliquer une architecture serveless à plus de 90% des scénarios.		* '''Non applicable à tous les projets''' : Pas de solution miracle, même si on peux appliquer une architecture serveless à plus de 90% des scénarios.
	* '''Sécurité''' : C'est aussi un avantage, mais il faut penser que si le fournisseur subit un hack ou autre, c'est aussi les données de l'entreprise qui sont en danger. Attention aux données externalisées !		* '''Sécurité''' : C'est aussi un avantage, mais il faut penser que si le fournisseur subit un hack ou autre, c'est aussi les données de l'entreprise qui sont en danger. Attention aux données externalisées !

Antoine.Boisadam: /* Inconvénients */

2017-09-16T10:32:15Z

Inconvénients

← Older revision		Revision as of 10:32, 16 September 2017
Line 42:		Line 42:
	===Inconvénients===		===Inconvénients===

	* '''Dépendance au cloud provider''' : Effectivement, si le fournisseur ferme ou est ne fonctionne plus un temps, c'est vers vous que les utiliseurs se retourneront car votre application finale ne "fonctionne pas"		* '''Dépendance au cloud provider''' : Effectivement, si le fournisseur ferme ou est ne fonctionne plus un temps, c'est vers vous que les utiliseurs se retourneront car votre application finale ne "fonctionne pas". De plus, si du jour au lendemain, le provider augmente ses prix (x2, x3, ...) il faudra payer ou recoder entièrement sa solution.
	* '''Durée d’exécution''' : On a là deux problématique, quid du timeout et quid de la latence au démarrage ? C'est à dire, si la fonction met plus de 5 minutes à rendre un résultat, que ce passe-t-t-il ? Pour la latence au démarrage, comme il faut créer un conteneur à chaque exécution, les fournisseurs ne laissent pas pour l'instant un choix infini de langage exécutable. On retrouve souvent Javascript (Avec Node.JS) pour ces performances.		* '''Durée d’exécution''' : On a là deux problématique, quid du timeout et quid de la latence au démarrage ? C'est à dire, si la fonction met plus de 5 minutes à rendre un résultat, que ce passe-t-t-il ? Pour la latence au démarrage, comme il faut créer un conteneur à chaque exécution, les fournisseurs ne laissent pas pour l'instant un choix infini de langage exécutable. On retrouve souvent Javascript (Avec Node.JS) pour ces performances.
	* '''Non applicable à tous les projets''' : Pas de solution miracle, même si on peux appliquer une architecture serveless à plus de 90% des scénarios.		* '''Non applicable à tous les projets''' : Pas de solution miracle, même si on peux appliquer une architecture serveless à plus de 90% des scénarios.
	* '''Sécurité''' : C'est aussi un avantage, mais il faut penser que si le fournisseur subit un hack ou autre, c'est aussi les données de l'entreprise qui sont en danger. Attention aux données externalisées !		* '''Sécurité''' : C'est aussi un avantage, mais il faut penser que si le fournisseur subit un hack ou autre, c'est aussi les données de l'entreprise qui sont en danger. Attention aux données externalisées !


	==OpenWhisk==		==OpenWhisk==

Antoine.Boisadam: /* Le principe */

2017-09-15T13:05:05Z

Le principe

← Older revision		Revision as of 13:05, 15 September 2017
Line 26:		Line 26:
	Une architecture serverless est une architecture où l'utilisateur n'a plus à gérer la moindre architecture. Il se concentre exclusivement sur la conception.		Une architecture serverless est une architecture où l'utilisateur n'a plus à gérer la moindre architecture. Il se concentre exclusivement sur la conception.
	Serverless ne signifie pas sans serveur '''mais''' que le serveur est invisible pour l'utilisateur. Il y a donc un impact sur les coûts.		Serverless ne signifie pas sans serveur '''mais''' que le serveur est invisible pour l'utilisateur. Il y a donc un impact sur les coûts.

			TBC..

	==Avantages et inconvénients==		==Avantages et inconvénients==

Antoine.Boisadam: /* Le principe */

2017-09-15T13:04:50Z

Le principe

← Older revision		Revision as of 13:04, 15 September 2017
Line 24:		Line 24:
	==Le principe==		==Le principe==

			Une architecture serverless est une architecture où l'utilisateur n'a plus à gérer la moindre architecture. Il se concentre exclusivement sur la conception.

			Serverless ne signifie pas sans serveur '''mais''' que le serveur est invisible pour l'utilisateur. Il y a donc un impact sur les coûts.

	==Avantages et inconvénients==		==Avantages et inconvénients==

Antoine.Boisadam: /* OpenWhisk */

2017-09-15T13:00:10Z

OpenWhisk

← Older revision		Revision as of 13:00, 15 September 2017
Line 46:		Line 46:

	==OpenWhisk==		==OpenWhisk==

			OpenWhisk est un projet aujourd'hui open-source et propulsé par Apache (https://openwhisk.incubator.apache.org/). Ce projet permet de mettre en place un serveur qui fonctionne en temps que fonction (ou action) qui répond à un événement.

	[[File:Openwhisk-principe.png\|400px]]		[[File:Openwhisk-principe.png\|400px]]

			IBM propose un service ''IBM Function'' qui propose d'utiliser cette architecture : https://console.bluemix.net/openwhisk

	=Webographie=		=Webographie=

Antoine.Boisadam: /* Synthèse */ Avantages/inconvenients

2017-09-15T12:53:26Z

Synthèse: Avantages/inconvenients

← Older revision		Revision as of 12:53, 15 September 2017
Line 19:		Line 19:

	=Synthèse=		=Synthèse=

			La mise en place de serveurs, qu'ils soient hébergés dans l'entreprise ou chez un fournisseur en ligne, leurs configurations et le déploiement d'applications sur ceux-ci peut s'avérer très coûteux (en terme d'homme/temps et aussi matériel). C'est pour ces raisons que ces dernières années, les architectures dîtes serverless se sont démocratisées.

			==Le principe==



			==Avantages et inconvénients==

			La technologie parfaite n'existe pas encore, c'est pourquoi j'expose ici les avantages et inconvénient d'une telle architecture.

			===Avantages===

			* '''Coûts réduits''' : En effet, pas de serveur physique = pas de frais d'achat et maintenance de matériel, ni de dépense électrique pour faire tourner et refroidir un (ou plusieurs) serveur(s). Un serveur hébergé dans l'entreprise, qui rend un site web, doit disponible 100% du temps (ou du moins, le plus possible). <br/>Lors de l'utilisation d'une architecture serveless, les coûts sont également réduits car les fournisseurs facturent à l’appel de fonction (et pas à la minute de [[uptime]] comme lorsqu'on paie un serveur traditionnel) : on payera donc en fonction du nombre d'utilisateur sur notre application (au lieu d'un coût "fixe").
			* '''Mise à l’échelle''' : Les cloud provider ont mis en place de la parrallèlisation d'action. Comme il y a un conteneur par action, il n'y a plus de surchage d'un conteneur puisqu'on peux en créer X conteneurs pour X actions.
			* '''Informatique plus « vert »''' : Le serveur ne tourne plus 24h/24 et les fournisseurs peuvent faire tourner plusieurs actions sur un même serveur (physique). Il faut s'avoir, qu'en moyenne 5 à 15% des data-centers des entreprises sont utilisés, il y a donc une possibilité d'amélioration avec cette architecture.
			* '''Sécurité''' : La sécurité étant totalement géré par le fournisseur, la majorité des barrières aux attaques informatiques (proxy, anti-DDOS, ...) n'étant plus à mettre en place par l'équipe technique de l'entreprise.

			===Inconvénients===

			* '''Dépendance au cloud provider''' : Effectivement, si le fournisseur ferme ou est ne fonctionne plus un temps, c'est vers vous que les utiliseurs se retourneront car votre application finale ne "fonctionne pas"
			* '''Durée d’exécution''' : On a là deux problématique, quid du timeout et quid de la latence au démarrage ? C'est à dire, si la fonction met plus de 5 minutes à rendre un résultat, que ce passe-t-t-il ? Pour la latence au démarrage, comme il faut créer un conteneur à chaque exécution, les fournisseurs ne laissent pas pour l'instant un choix infini de langage exécutable. On retrouve souvent Javascript (Avec Node.JS) pour ces performances.
			* '''Non applicable à tous les projets''' : Pas de solution miracle, même si on peux appliquer une architecture serveless à plus de 90% des scénarios.
			* '''Sécurité''' : C'est aussi un avantage, mais il faut penser que si le fournisseur subit un hack ou autre, c'est aussi les données de l'entreprise qui sont en danger. Attention aux données externalisées !


			==OpenWhisk==

			[[File:Openwhisk-principe.png\|400px]]

	=Webographie=		=Webographie=

← Older revision		Revision as of 17:47, 17 September 2017
Line 23:		Line 23:

	Une architecture serverless est une architecture où l'utilisateur n'a plus à gérer la moindre architecture. Il se concentre exclusivement sur la conception.		Une architecture serverless est une architecture où l'utilisateur n'a plus à gérer la moindre architecture. Il se concentre exclusivement sur la conception.
	Serverless ne signifie pas sans serveur '''mais''' que le serveur est invisible pour l'utilisateur. Il y a donc un impact sur les coûts de maintenance, mais aussi matériels.		Serverless ne signifie pas sans serveur '''mais''' que le serveur est invisible pour l'utilisateur. Il y a donc un impact sur les coûts de maintenance, mais aussi matériels puisque les serveurs sont externalisés chez des fournisseurs de services (Amazon, Google, IBM, ...).

			Le gros changement par rapport aux architecture classique est que toute la logique du serveur est découpée en fonction. Pour chaque exécution de fonction, un conteneur (voir [[Docker]] pour plus d'info) va être lancé et détruit dès le résultat de la fonction renvoyé.
	'''To Be Continued..'''

	==Avantages et inconvénients==		==Avantages et inconvénients==
Line 34:		Line 34:

	* '''Coûts réduits''' : En effet, pas de serveur physique = pas de frais d'achat et maintenance de matériel, ni de dépense électrique pour faire tourner et refroidir un (ou plusieurs) serveur(s). Un serveur hébergé dans l'entreprise, qui rend un site web, doit disponible 100% du temps (ou du moins, le plus possible). <br/>Lors de l'utilisation d'une architecture serveless, les coûts sont également réduits car les fournisseurs facturent à l’appel de fonction (et pas à la minute de [[uptime]] comme lorsqu'on paie un serveur traditionnel) : on payera donc en fonction du nombre d'utilisateur sur notre application (au lieu d'un coût "fixe").		* '''Coûts réduits''' : En effet, pas de serveur physique = pas de frais d'achat et maintenance de matériel, ni de dépense électrique pour faire tourner et refroidir un (ou plusieurs) serveur(s). Un serveur hébergé dans l'entreprise, qui rend un site web, doit disponible 100% du temps (ou du moins, le plus possible). <br/>Lors de l'utilisation d'une architecture serveless, les coûts sont également réduits car les fournisseurs facturent à l’appel de fonction (et pas à la minute de [[uptime]] comme lorsqu'on paie un serveur traditionnel) : on payera donc en fonction du nombre d'utilisateur sur notre application (au lieu d'un coût "fixe").
	* '''Mise à l’échelle''' : Les cloud provider ont mis en place de la ~~parrallèlisation~~ d'action. Comme il y a un conteneur par action, il n'y a plus de ~~surchage~~ d'un conteneur puisqu'on peux en créer X conteneurs pour X actions.		* '''Mise à l’échelle''' : Les cloud provider ont mis en place de la parallélisation d'action. Comme il y a un conteneur par action, il n'y a plus de surcharge d'un conteneur puisqu'on peux en créer X conteneurs pour X actions.
	* '''Informatique plus « vert »''' : Le serveur ne tourne plus 24h/24 et les fournisseurs peuvent faire tourner plusieurs actions sur un même serveur (physique). Il faut ~~s'avoir~~, qu'en moyenne 5 à 15% des data-centers des entreprises sont utilisés, il y a donc une possibilité d'amélioration avec cette architecture.		* '''Informatique plus « vert »''' : Le serveur ne tourne plus 24h/24 et les fournisseurs peuvent faire tourner plusieurs actions sur un même serveur (physique). Il faut savoir, qu'en moyenne 5 à 15% des data-centers des entreprises sont utilisés, il y a donc une possibilité d'amélioration avec cette architecture.
	* '''Sécurité''' : La sécurité étant totalement géré par le fournisseur, la majorité des barrières aux attaques informatiques (proxy, anti-DDOS, ...) n'étant plus à mettre en place par l'équipe technique de l'entreprise.		* '''Sécurité''' : La sécurité étant totalement géré par le fournisseur, la majorité des barrières aux attaques informatiques (proxy, anti-DDOS, ...) n'étant plus à mettre en place par l'équipe technique de l'entreprise.

	===Inconvénients===		===Inconvénients===

	* '''Dépendance au cloud provider''' : Effectivement, si le fournisseur ferme ou est ne fonctionne plus un temps, c'est vers vous que les ~~utiliseurs~~ se retourneront car votre application finale ne "fonctionne pas". De plus, si du jour au lendemain, le provider augmente ses prix (x2, x3, ...) il faudra payer ou ré-implémenter entièrement sa solution.		* '''Dépendance au cloud provider''' : Effectivement, si le fournisseur ferme ou est ne fonctionne plus un temps, c'est vers vous que les utilisateurs se retourneront car votre application finale ne "fonctionne pas". De plus, si du jour au lendemain, le provider augmente ses prix (x2, x3, ...) il faudra payer ou ré-implémenter entièrement sa solution.
	* '''Durée d’exécution''' : On a là deux problématique, quid du timeout et quid de la latence au démarrage ? C'est à dire, si la fonction met plus de 5 minutes à rendre un résultat, que ce passe-t-il ? Pour la latence au démarrage, comme il faut créer un conteneur à chaque exécution, les fournisseurs ne laissent pas pour l'instant un choix infini de langage exécutable. On retrouve souvent Javascript (Avec Node.JS) pour ces performances.		* '''Durée d’exécution''' : On a là deux problématique, quid du timeout et quid de la latence au démarrage ? C'est à dire, si la fonction met plus de 5 minutes à rendre un résultat, que ce passe-t-il ? Pour la latence au démarrage, comme il faut créer un conteneur à chaque exécution, les fournisseurs ne laissent pas pour l'instant un choix infini de langage exécutable. On retrouve souvent Javascript (Avec Node.JS) pour ces performances.
	* '''Non applicable à tous les projets''' : Pas de solution miracle, même si on peux appliquer une architecture serveless à plus de 90% des scénarios.		* '''Non applicable à tous les projets''' : Pas de solution miracle, même si on peux appliquer une architecture serveless à plus de 90% des scénarios.
Line 47:		Line 47:
	==OpenWhisk==		==OpenWhisk==

	OpenWhisk est un projet aujourd'hui open-source et propulsé par Apache (https://openwhisk.incubator.apache.org/). Ce projet permet de mettre en place un serveur qui fonctionne en ~~temps~~ ~~que~~ fonction (ou action) qui répond à un événement.		OpenWhisk est un projet aujourd'hui open-source et propulsé par Apache (https://openwhisk.incubator.apache.org/). Ce projet permet de mettre en place un serveur qui fonctionne avec la logique fonction (ou action) qui répond à un événement. On illustre dans la figure ci-dessous le concept de conteneur éphémère.

	[[File:Openwhisk-principe.png\|400px]]		[[File:Openwhisk-principe.png\|400px]]