Quelles techno pour du micro-service : optimisation/confort ?

benjamin_bnds · Juillet 30, 2015, 11:08

Salut,

Dans une approche type micro-service, je souhaite découper une partie d’une grosse application PHP, Symfony.
L’objectif est d’extraire la partie produit du reste de l’applicatif pour en faire une application séparée.

L’application séparée devra :

proposer l’accès à ses données à travers une API Rest hypermedia
mettre à jour ses données (calculs et appels à d’autres API, asynchrones, etc.)

Pour la techno à utiliser, on hésite entre du Rails/Postgresql + Hstore et du Nodejs + Mongodb.
On est aussi ouvert à d’autres stacks.

Le but est double : l’optimisation des temps de réponse et le confort de développement, de mise à jour.

Vous auriez des reco, des articles sur le sujet ?

vdaubry · Juillet 30, 2015, 12:08

Quelle est votre motivation pour changer de stack tech ?

Je vous conseille de commencer par faire un état des lieux des problèmes que vous rencontrez avec PHP+Symfony
En faisant cet exercice il y a de bonne chance que la réponse sorte d’elle même.

Si vous avez surtout envie de jouer avec de nouvelles techno (c’est souvent fun et motivant) je vous déconseillerais de le faire sur votre API coeur. Encore plus dans le cadre d’une grosse refonte d’architecture…

Vu que vous partez dans une approche micro service, vous aurez tout le loisir de choisir une autre stack pour les prochains service. Avec probablement moins de stress et plus de marge de manoeuvre :)

Autre questions à prendre en compte :

Est ce que tu as des contraintes particulières ? (temps réel genre chat, etc)
Quelle volumétrie ?
Quelle taille d’équipe, et quel niveau d’expérience ? (si je comprends bien tout le monde fait du PHP / SQL pour le moment ?)

Sur le fond les 2 stack que tu proposes répondront parfaitement à la plupart des cas de figures. Si tu n’as pas de grosses contraintes technique je privilégierais le confort de développement et de mise à jour dans votre choix.

kakawait · Juillet 30, 2015, 1:20

L’interet même du microservice c’est que chaque microservice soit indépendant, par la je veux dire que tu peux avoir un microservice en C, un en Java, un autre en node. Le but est de pouvoir utiliser les meilleurs outils (langage ou framework) pour un service/problème donnée.

Après je te l’accorde ceci est très théorique et il est difficile au début (et moins productif) de s’engager dans différente stack. Mais j’insiste sur ce point pour pas que tu ne crée un couplage fort entre ton architecture et tes services !

A titre personnel, j’utilise Java avec Spring Boot et Spring Cloud (qui exploite lui même Netflix OSS). La simplicité est assez déconcertante si tu adhères au principe de Spring et des annotations Java.

Une série d’article assez complet pour t’en rendre compte (je ne link que le “part 1”) :

http://callistaenterprise.se/blogg/teknik/2015/04/10/building-microservices-with-spring-cloud-and-netflix-oss-part-1/

augustin · Août 1, 2015, 2:15

Tout à fait d’accord avec Vincent. Faites-vous plaisir sur la techno, puisque l’optimisation arrivera plus tard, et sera faite sans grande difficulté du fait du nombre réduit de dépendances.

Après ce critère, pensez au “get things done” (votre productivité sur une techno), à la maintenabilité et au monitoring (surveiller que plusieurs micro-services sont toujours up peut devenir fastidieux à terme).

Initerworker · Août 2, 2015, 8:18

Pour moi,
Etant dépendant (Cocaïne) à NodeJS, je vous crie son nom sans problème. Mais une configuration Symphony en PHP reste une très bonne solution. Si, bien-sur le Framework et déjà appréhendé.

abelar_s · Août 2, 2015, 3:33

Comme toujours : Martin Fowler l’a déjà fait et explique clairement les leçons apprises.

Choisis la stack que tu veux mais comme le notent les autres, celle qui convient à ton équipe, pas celle qui aurait telle ou telle qualité.

Organise ton service comme tu peux parce que tu vas vite voir que “la vie” ne va pas te laisser dérouler ton schéma d’archi comme prévu.

Martin Fowler note que tous les projets réussis qu’il a vus sont partis

d’un monolithe
de la connaissance de ce qu’il y a de “séparable”
de la séparation morceau par morceau de ce qu’il y a, d’un “grignotage sur les bords”

Bon courage et bonne chance !

blueicefield · Août 5, 2015, 9:44

Je me permets juste de signaler que MongoDB diffère d’un SGBD relationnel est qu’il faut prendre en considération certains points lors de son implémentation :

Pas de support des transactions ACID.
Pas de jointures (il faudra que toutes les données tiennent dans un document pour assurer un bon niveau de perf).