architecture d'une application full api orienté micro service

Architecture d'une application full API

orientée micro service

Présentation

• Yves HeitzDevOps Klubup

• Xavier Gorse / @xgorse CTO & Co-fondateur KlubupFondateur Elao

Qu’est ce qu’un micro service ?

http://martinfowler.com/articles/microservices.html

Qu’est ce qu’un micro service ?

http://martinfowler.com/articles/microservices.html

Klubup

• Connecter les @personnes et les #passions autour de la notion du Klub

• On est membre d’un Klub

• On partage dans un Klub

• On sponsorise un Klub

Klubup

• Liste des services

ServicesKlub SF2 Mysql

Search Silex SOLR

Pics Silex -

Register NodeJS Redis

Provider NodeJS -

Metrics GO Logentries

Notification PHP Iron.io Firebase

ApplicationsFront Backbone

iOS ObjectiveC

Android Java

Mirador SF2

Twitter streaming MeteorJS

GraphManager MeteorJS

Pourquoi ?

• Appli monolithique de 60 Bundles

• Mobile

• Application full Javascript

• Optimisation des dev Back/Front

Bon candidat à un service

• Scope fonctionnel délimité

• Datastore spécifique

• Bootstrap d’un nouveau fonctionnel

• Nouvelle techno

Mauvais candidat à un service

• Data existante

• Transactionnel

• Nano service

• Nouvelle techno

Quelle techno pour mon service ?

• Compétences

• Productivité

• Performance

• Evolution de techno

Communication

• HTTP : Universel

• API REST JSON : Universel, Simple

• Consommation directe

• Consommation encapsulée via un service

Gestion d’erreurs

• Accepter

• Criticité

• Front

• Back

Sécurité

• OAuth2 pour les applications

• OAuth2, Hawk et réseau privé pour les services

• OAuth2 pas adapté entre les services

• HTTPS

Transactionnel

• Pas de gestion de transaction cross services

• Seulement au sein d'un service

• Accepter l’erreur pour éviter les transactions

Monitoring / Reporting

• Basé sur les log avec Logentries

• RequestId pour regrouper les logs

• UserAgent des applications et des services

Monitoring / Reporting

• Basé sur les log avec Logentries

• RequestId pour regroupé les logs

• UserAgent des applications et des services

Scalabilité

• Isolation

• Horizontalement / Verticalement

• Séparation API Lecture / Ecriture

• Concurrency des workers

• Humaine : 1 team / 1 service

Performance

• Rendre la main le plus vite possible au front

• Difficulté de la parallélisation en PHP

• Limiter les rebonds entre les services

• Latence HTTP

• Traitement asynchrone

Asynchrone

• Iron.io SAAS : IronMQ & IronWorker

• Callback HTTP

• Messaging avec workers

• Généralisation des messages sur toutes les API

Iron.io

Cache

• Pas de cache au niveau applicatif

• Séparation /public/* et /private/*

• Public : Cache HTTP via Varnish

• Private : pas de cache pour l’instant

Infra

• Provisionning avec Chef OpsCode

• VM via OpenVz

• Autonomie des deploy Applications/Services

• Impact nouveau service / nouvelle techno

Conclusion

• Composant

• Orienté métier

• Approche produit

• Décentralisation

• Infrastructure automatisée

• Gestion des erreurs

Conclusion

• Couplage : Applications, Services, Infra

• Bootstrap rapide

• Industrialisation et refactoring douloureux

• Ouverture du code

• Setup et debug compliqués

Next Step ?

• Baptême du feu à la charge

• Rationalisation

• Industrialisation

• Docker

Merci

Recrute sur ParisRecrute sur Lyon