Django c'est un fronted web, ça n'est pas une architecture en soi. Spotify par exemple doit gérer les musiques et les profils utilisateurs. Il faut stocker et mettre à disposition les musiques aux utilisateurs, ça ne se fait pas en stockant tout dans un sgbdr. Essayez de proposer les musiques qui plaisent aux bonnes personnes ça demande à pouvoir faire du calcul en arrière plan pour mettre à jour les profils et vérifier ce qui correspond le mieux. Enfin si django est à l'aise avec des interfaces web avec templates coté serveurs, il va falloir faire des choses en plus pour les mobiles et par exemple les chromecast ou les trucs comme Alexa. Il faut des api pour ça, il faut les authentifier ce qui se fait souvent autrement que dans un site web (sans cookies par exemple).
Il faut bien distinguer architecture et technologie. On peut garder une techno par inertie par exemple (on a commencé avec et on a pas encore jugé bon de la remplacer ou on ne s'en sert que pour une partie) et au contraire on peut utiliser des technologies hypes pour faire des trucs très à l'ancienne.
Mais ces architectures peuvent avoir de l'intérêt même sans grand besoin de montée en charge. Elles peuvent donner une meilleure résilience par exemple (pense aux sites de billetterie par exemple qui ont des pics de charges très ponctuels) ou permettre certaines souplesse (c'est plus simple de supprimer un micro service pour le remplacer que du code qui aura tendance à avoir un plus fort couplage avec le reste de l'application).
[^] # Re: Je suis resté en 2000
Posté par barmic . En réponse à la dépêche Démystifier l’activité d’hébergeur. Évalué à 5.
Django c'est un fronted web, ça n'est pas une architecture en soi. Spotify par exemple doit gérer les musiques et les profils utilisateurs. Il faut stocker et mettre à disposition les musiques aux utilisateurs, ça ne se fait pas en stockant tout dans un sgbdr. Essayez de proposer les musiques qui plaisent aux bonnes personnes ça demande à pouvoir faire du calcul en arrière plan pour mettre à jour les profils et vérifier ce qui correspond le mieux. Enfin si django est à l'aise avec des interfaces web avec templates coté serveurs, il va falloir faire des choses en plus pour les mobiles et par exemple les chromecast ou les trucs comme Alexa. Il faut des api pour ça, il faut les authentifier ce qui se fait souvent autrement que dans un site web (sans cookies par exemple).
Il faut bien distinguer architecture et technologie. On peut garder une techno par inertie par exemple (on a commencé avec et on a pas encore jugé bon de la remplacer ou on ne s'en sert que pour une partie) et au contraire on peut utiliser des technologies hypes pour faire des trucs très à l'ancienne.
Un blog de référence dans le domaine http://highscalability.com/
Mais ces architectures peuvent avoir de l'intérêt même sans grand besoin de montée en charge. Elles peuvent donner une meilleure résilience par exemple (pense aux sites de billetterie par exemple qui ont des pics de charges très ponctuels) ou permettre certaines souplesse (c'est plus simple de supprimer un micro service pour le remplacer que du code qui aura tendance à avoir un plus fort couplage avec le reste de l'application).