Les réseaux internes utilisent souvent des connexions 1 Gbit / s ou plus rapides. Les connexions ou liaisons par fibres optiques permettent des largeurs de bande beaucoup plus élevées entre les serveurs. Imaginez maintenant la taille moyenne d'une réponse JSON d'une API. Combien de ces réponses peuvent être transmises sur une connexion de 1 Gbps en une seconde?
Faisons le calcul. 1 Gbps est de 131 072 Ko par seconde. Si une réponse JSON moyenne est de 5 Ko (ce qui est assez!), Vous pouvez envoyer 26 214 réponses par seconde de bout en bout avec seulement une paire de machines . Pas si mal, n'est ce pas?
C'est pourquoi la connexion réseau n'est généralement pas le goulot d'étranglement.
Un autre aspect des microservices est que vous pouvez facilement évoluer. Imaginez deux serveurs, l'un hébergeant l'API, l'autre le consommant. Si jamais la connexion devient un goulot d'étranglement, ajoutez simplement deux autres serveurs et vous pourrez doubler les performances.
C’est à ce moment-là que nos 26 214 réponses précédentes par seconde deviennent trop petites pour l’ampleur de l’application. Vous ajoutez neuf autres paires et vous pouvez maintenant servir 262 140 réponses.
Mais revenons à notre paire de serveurs et faisons des comparaisons.
Si une requête moyenne non mise en cache sur une base de données prend 10 ms, vous êtes limité à 100 requêtes par seconde. 100 requêtes. 26 214 réponses. Atteindre la vitesse de 26 214 réponses par seconde nécessite une grande quantité de mise en cache et d’optimisation (si la réponse doit réellement faire quelque chose d’utile, comme interroger une base de données; les réponses de style "Hello World" ne sont pas admissibles).
Sur mon ordinateur, à l'heure actuelle, la page d'accueil de DOMContentLoaded pour Google s'est produite à 394 ms. après l'envoi de la demande. C'est moins de 3 demandes par seconde. Pour la page d’accueil de Programmers.SE, cela s’est passé à 603 ms. après l'envoi de la demande. Ce n'est même pas 2 demandes par seconde. Au fait, j'ai une connexion Internet à 100 Mbps et un ordinateur rapide: beaucoup d'utilisateurs vont attendre plus longtemps.
Si le goulot d'étranglement est la vitesse du réseau entre les serveurs, ces deux sites pourraient littéralement faire des milliers d'appels vers différentes API tout en servant la page.
Ces deux cas montrent que le réseau ne sera probablement pas votre goulot d'étranglement en théorie (en pratique, vous devez effectuer les tests de performances et le profilage réels pour déterminer l'emplacement exact du goulot d'étranglement de votre système hébergé sur un matériel particulier). Le temps consacré au travail réel (qu'il s'agisse de requêtes SQL, de compression, etc.) et l'envoi du résultat à l'utilisateur final sont beaucoup plus importants.
Pensez aux bases de données
Généralement, les bases de données sont hébergées séparément de l'application Web qui les utilise. Cela peut poser un problème: qu'en est-il de la vitesse de connexion entre le serveur hébergeant l'application et le serveur hébergeant la base de données?
Il semble que dans certains cas, la vitesse de connexion pose problème, c’est-à-dire lorsque vous stockez d’énormes quantités de données qui n’ont pas besoin d’être traitées par la base de données elle-même et qui devraient être disponibles maintenant (c’est-à-dire de gros fichiers binaires). Mais de telles situations sont rares: dans la plupart des cas, la vitesse de transfert n’est pas si grande comparée à la vitesse de traitement de la requête elle-même.
Lorsque la vitesse de transfert est réellement importante, c'est lorsqu'une entreprise héberge de grands ensembles de données sur un NAS et que plusieurs clients accèdent au NAS en même temps. C'est là qu'un SAN peut être une solution. Ceci étant dit, ce n'est pas la seule solution. Les câbles Cat 6 peuvent supporter des vitesses allant jusqu'à 10 Gbps; La liaison peut également être utilisée pour augmenter la vitesse sans changer les câbles ou les adaptateurs réseau. D'autres solutions existent, impliquant la réplication de données sur plusieurs NAS.
Oubliez la vitesse; penser à l'évolutivité
Un point important d'une application Web est de pouvoir évoluer. Bien que les performances réelles importent (car personne ne veut payer pour des serveurs plus puissants), l’évolutivité est beaucoup plus importante, car elle vous permet de lancer du matériel supplémentaire en cas de besoin.
Si vous avez une application pas particulièrement rapide, vous perdrez de l'argent car vous aurez besoin de serveurs plus puissants.
Si vous avez une application rapide qui ne peut pas évoluer, vous perdrez des clients car vous ne serez pas en mesure de répondre à une demande croissante.
De la même manière, les machines virtuelles étaient perçues il y a une décennie comme un énorme problème de performances. En effet, héberger une application sur un serveur ou sur une machine virtuelle avait un impact important sur les performances. Bien que l'écart soit beaucoup plus petit aujourd'hui, il existe toujours.
Malgré cette perte de performances, les environnements virtuels sont devenus très populaires en raison de la flexibilité qu’ils offrent.
Comme avec la vitesse du réseau, vous constaterez peut-être que la VM est le goulet d'étranglement réel et que, compte tenu de votre taille réelle, vous économiserez des milliards de dollars en hébergeant votre application directement, sans les VM. Mais ce n'est pas ce qui se passe pour 99,9% des applications: leur goulot d'étranglement est ailleurs et l'inconvénient d'une perte de quelques microsecondes à cause de la VM est facilement compensé par les avantages de l'abstraction matérielle et de son évolutivité.