3. Ippon est un cabinet de conseil et d’expertise en
développement de logiciels innovants
Ippon Technologies 2017
Aurélien SCHWARTZ
Responsable de projet de Data Science chez EDF
“ En nous adressant à Ippon nous cherchions une société capable de nous accompagner dans la construction d’un produit qui n’existait
alors qu’au stade de proof of concept sur nos machines de chercheurs. “
4. Ippon Technologies 2017
IPPON EN QUELQUES MOTS
15ans
2002 - 2017
30M€
prévisionnel 2017
300collaborateurs
24M€
CA 2016
4continents
6. Ippon Technologies 2017
Entraînement intensif avec
pour objectif de dépasser nos
limites en équipe
Fondé par Stéphane Nomis, ancien
sportif de haut niveau.
Remise en question
permanente afin de viser
l’excellence
NOS VALEURS
LES VALEURS DU SPORT DE HAUT NIVEAU
APPLIQUÉES AU MANAGEMENT D’UNE ENTREPRISE
7. Discovery To Delivery
Innover et optimiser votre Time To Market
Ippon Technologies 2017
Une méthode
Agile
Approche
customer/user centric
Accompagnement
et co-construction
Vision claire
et partagée
de votre
stratégie digitale
Des Data
valorisées
Développement
de logiciel
industrialisé
Des infrastructures
bien managées
9. Ippon Technologies 2017
NOS SERVICES
Stratégie Client
Architecture IT
Transition Agile
Vision Produit
Management
CONSEIL
Design thinking
Ergonomie
Expérience Utilisateur
UI
Design intéractif
EXPÉRIENCE
UTILISATEUR
& DESIGN FullStack
Java, JavaScript & JVM
OpenSource
Agile
Continuous Delivery
Craftsmanship
DÉVELOPPEMENT
Fast Data
Smart Data
Big Data
Data Science
DATA
Chaînes Devops
Infrastructure as Code
Cloud
Hosting / Infogérance
DEVOPS & CLOUD
Timing :
40min de presentation
20 min de démonstration
10 min de présentation
10 min de démonstration
10 min de questions
une valeurs ippon c’est notre volonté d’accompagner nos clients, pas uniquement sur la réalisation mais sur le discovery to delivery
aider à la concretisation de la strategie digitale de notre client
Panel ou catalogue de services
Evolution des infrastructure
Baremetal: Single tenant
Virtual machines (IAAS) : Multitenant
Containeurs : (2013)
Functions (FAAS) (lambda 2 ans)
PaaS : plateform as a service , cloud computing qui fournit un plateforme et un environnement
Container : FaaS = scaling auto / not by default for container
NoOps: il y a des Ops mais juste pas de Internal Sys admin
concretement 2 types Serverless : BaaS et FaaS
BaaS:
Initialement pour mobile apps
FaaS
Event based
concretement 2 types Serverless : BaaS et FaaS
BaaS:
Initialement pour mobile apps
FaaS
Event based
concretement 2 types Serverless : BaaS et FaaS
BaaS:
Initialement pour mobile apps
FaaS
Event based
concretement 2 types Serverless : BaaS et FaaS
BaaS:
Initialement pour mobile apps
FaaS
Event based
concretement 2 types Serverless : BaaS et FaaS
BaaS:
Initialement pour mobile apps
FaaS
Event based
concretement 2 types Serverless : BaaS et FaaS
BaaS:
Initialement pour mobile apps
FaaS
Event based
concretement 2 types Serverless : BaaS et FaaS
BaaS:
Initialement pour mobile apps
FaaS
Event based
concretement 2 types Serverless : BaaS et FaaS
BaaS:
Initialement pour mobile apps
FaaS
Event based
concretement 2 types Serverless : BaaS et FaaS
BaaS:
Initialement pour mobile apps
FaaS
Event based
concretement 2 types Serverless : BaaS et FaaS
BaaS:
Initialement pour mobile apps
FaaS
Event based
concretement 2 types Serverless : BaaS et FaaS
BaaS:
Initialement pour mobile apps
FaaS
Event based
concretement 2 types Serverless : BaaS et FaaS
BaaS:
Initialement pour mobile apps
FaaS
Event based
concretement 2 types Serverless : BaaS et FaaS
BaaS:
Initialement pour mobile apps
FaaS
Event based
concretement 2 types Serverless : BaaS et FaaS
BaaS:
Initialement pour mobile apps
FaaS
Event based
UseCase : Enregistrement d’un vote dynamique via SMS
En combinant AWS Lambda avec d'autres services AWS, les développeurs peuvent créer de puissantes applications Web qui augmentent automatiquement et descendent et fonctionnent dans une configuration hautement disponible dans plusieurs centres de données, avec un effort administratif nul requis pour l'extensibilité, les sauvegardes ou la redondance multi-centres de données.
Cet exemple illustre l'utilisation d'AWS Lambda et Amazon API Gateway pour créer une application de vote dynamique, qui reçoit des votes via SMS, agrège les totaux dans Amazon DynamoDB et utilise Amazon Simple Storage Service (Amazon S3) pour afficher les résultats en temps réel.
L'architecture peut être créée avec un modèle AWS CloudFormation.
Le modèle fait ce qui suit:
Crée un compartiment S3 nommé pour contenir votre application Web.
Crée une table DynamoDB nommée VoteApp pour enregistrer les votes
Crée une table DynamoDB nommée VoteAppAggregates pour regrouper les totaux des votes
Crée une fonction Lambda qui permet à votre application de recevoir des votes
Crée une fonction Lambda qui permet à votre application d'agréger les votes
Crée un rôle et une stratégie AWS Identity and Access (IAM) pour permettre aux fonctions Lambda d'écrire sur les journaux Amazon CloudWatch et d'écrire et d'interroger les tables DynamoDB
L'architecture de référence de traitement de fichiers en temps réel est une architecture de traitement de données parallèle, événementielle et événementielle qui utilise AWS Lambda. Cette architecture est idéale pour les charges de travail qui nécessitent plus d'une dérivée de données d'un objet. Cette architecture simple est décrite dans la publication du blog "Fanout S3 Event Notifications to Multiple Endpoints" sur AWS Compute Blog. Cet exemple d'application démontre une application de conversion Markdown où Lambda est utilisé pour convertir des fichiers Markdown en HTML et en texte brut.
Reduced operational cost:
coût infra (economie d’echelle par les providers)
coût employées (ops : utilisation des services managés)
Reduced dev cost:
Exemple Authentification
Exemple base de données pour applicaiton mobile avec communication direct
Scaling cost:
on paie ce que l’on consomme
exemple d’économie : utilisation occasionnelle d’une fonction
Optimization:
optimisation du code 1s > 200ms = 80% d’économie
Greener computing:
cloud providers gèrent leur propre ferme d’instances et peuvent ainsi optimiser la répartition des charges au lieu d’avoir de la change non utilisé
vendor lock-in:
dépendance forte vers le fournisseurs de services (migration ?)
pas de langage commun (spécifications)
contraintes d’utilisation des ressources d’un provider (ex API Gateway + Lambda)
migration code (pas meme interface entre providers)
Security
Multitenant et partage d’instance (accès aux données d’autres clients)
périmètre d’action et empreinte de la solution sur internet (+ grande + grand % d’attaque)
hétérogénéité des applicatifs et des règles de sécurité
accès DB via API, perte barrière de protection d’une app traditionnelle
Server optimizations
pas de possibilité de customization (ok pour 99% des cas et bad pour 1%)
2 visions : Point de vue API (Chalice) et point de vue Infra (Serverless)
2 visions : Point de vue API (Chalice) et point de vue Infra (Serverless)
Déployer automatiquement vos fonctions et gérer les sources d’événement pour pouvoir interagir avec elles
Exemple concret du helloworld en live
Modification du serverless.yml pour event API Gateway
Test simple snas api type S3 Kinesis etc, donc soit vous avez ça en local soit utilisez resources de tests AWS
- http:
path: hello
method: get
Orienté API pas d’intégration avec CloudFormation ni de création de sources d’évênement.
Auto création policy IAM selon appels SDK AWS dans fonction (ex : S3, Kinesis etc)
Attention supporte pas encore la suppression des ressources
Orienté API pas d’intégration avec CloudFormation ni de création de sources d’évênement.
Bilan sur avantages inconvénients
Beaucoup de simplification et d’avantages mais pas magique
Forte dépendance au Cloud provider
Bien étudier les usecases avant de partir tête baissé (event based)
Pas assez mature (lambda existe depuis 2ans)
mais avenir radieux, nouvelle communauté dynamique