A travers un retour d'expérience sur le projet Klubup.com, nous explorerons une architecture applicative est basée sur les Micro Service, avec des API REST exploitées par les applications web principales (Symfony/BackboneJS), par les applications mobiles ( iOS et Android), mais aussi des petites applications métier basé sur d'autres techno comme Silex, Meteor ou NodeJS. Nous aussi aborderons la problématique d'authentification (Oauth), la gestion asynchrone via la solution Iron.io, mais aussi la partie infra avec la virtualisation, le provisionning avec Chef et la gestion des logs avec Logentries.

1. Architecture d'une
application full API
orientée micro service

2. Présentation
• Yves Heitz
DevOps Klubup
• Xavier Gorse / @xgorse
CTO & Co-fondateur Klubup
Fondateur Elao

3. Qu’est ce qu’un micro service ?
http://martinfowler.com/articles/microservices.html

4. Qu’est ce qu’un micro service ?
http://martinfowler.com/articles/microservices.html

5. 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

6. Klubup
• Liste des services

7. Services
Klub SF2 Mysql
Search Silex SOLR
Pics Silex -
Register NodeJS Redis
Provider NodeJS -
Metrics GO Logentries
Notification PHP Iron.io Firebase

8. Applications
Front Backbone
iOS ObjectiveC
Android Java
Mirador SF2
Twitter streaming MeteorJS
GraphManager MeteorJS

9. Pourquoi ?
• Appli monolithique de 60 Bundles
• Mobile
• Application full Javascript
• Optimisation des dev Back/Front

10. Bon candidat à un service
• Scope fonctionnel délimité
• Datastore spécifique
• Bootstrap d’un nouveau fonctionnel
• Nouvelle techno

11. Mauvais candidat à un service
• Data existante
• Transactionnel
• Nano service
• Nouvelle techno

12. Quelle techno pour mon service ?
• Compétences
• Productivité
• Performance
• Evolution de techno

13. Communication
• HTTP : Universel
• API REST JSON : Universel, Simple
• Consommation directe
• Consommation encapsulée via un service

14. Gestion d’erreurs
• Accepter
• Criticité
• Front
• Back

15. Sécurité
• OAuth2 pour les applications
• OAuth2, Hawk et réseau privé pour les services
• OAuth2 pas adapté entre les services
• HTTPS

16. Transactionnel
• Pas de gestion de transaction cross services
• Seulement au sein d'un service
• Accepter l’erreur pour éviter les transactions

17. Monitoring / Reporting
• Basé sur les log avec Logentries
• RequestId pour regrouper les logs
• UserAgent des applications et des services

18. Monitoring / Reporting
• Basé sur les log avec Logentries
• RequestId pour regroupé les logs
• UserAgent des applications et des services

19. Scalabilité
• Isolation
• Horizontalement / Verticalement
• Séparation API Lecture / Ecriture
• Concurrency des workers
• Humaine : 1 team / 1 service

20. 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

21. Asynchrone
• Iron.io SAAS : IronMQ & IronWorker
• Callback HTTP
• Messaging avec workers
• Généralisation des messages sur toutes les API

22. Iron.io

23. Cache
• Pas de cache au niveau applicatif
• Séparation /public/* et /private/*
• Public : Cache HTTP via Varnish
• Private : pas de cache pour l’instant

24. Infra
• Provisionning avec Chef OpsCode
• VM via OpenVz
• Autonomie des deploy Applications/Services
• Impact nouveau service / nouvelle techno

25. Conclusion
• Composant
• Orienté métier
• Approche produit
• Décentralisation
• Infrastructure automatisée
• Gestion des erreurs

26. Conclusion
• Couplage : Applications, Services, Infra
• Bootstrap rapide
• Industrialisation et refactoring douloureux
• Ouverture du code
• Setup et debug compliqués

27. Next Step ?
• Baptême du feu à la charge
• Rationalisation
• Industrialisation
• Docker

28. Merci
Recrute sur Lyon Recrute sur Paris