L'histoire de l'économie industrielle est l'histoire de la consommation d'une ressource limitée. Dans le cas de l'électricité, le pic du soir a été prononcé, et les propriétaires de centrales ont donc fait pression sur les transports urbains modernes et ont créé de toutes pièces, en fait, l'industrie électronique grand public. Autrement dit, ils ont changé le mode de vie de millions de personnes, de sorte que les centrales électriques sont chargées plus uniformément.
Les ressources informatiques ont une histoire similaire. Rarement, quiconque les utilise pleinement. Parlons de l'exploitation et un peu de la prochaine génération de programmation pour de tels environnements où il est très flexible de partager des ressources.
Consommation saisonnière
La consommation saisonnière d'un client saisonnier ressemble à 11 mois de calme et à un mois de double-triple charge. Tout le monde connaît son apogée. Retail bloque toutes les activités d'ici décembre et les ventes du Nouvel An, obtient des machines virtuelles. Tout le monde a toujours sa propre saison de remises et de grosses ventes - pour quelqu'un le 1er septembre, pour des cadeaux le 8 mars, etc. Tous les services B2C ont une activité saisonnière compréhensible uniquement avec les heures d'ouverture, par exemple, avec les banques Internet. Chez Technoserv Cloud, nous ne prévoyons pas de travaux de maintenance pour ces périodes.
Les géologues rentrent de l'expédition et commencent à compter leurs fossiles dans le nuage. Dans les grandes entreprises, les rapports à la fin de la période sont collectés à partir d'un tas de sous-systèmes - quelque part efficacement et quelque part avec un craquement, presque au point d'impact. L'apprentissage automatique et l'analyse donnent des charges très importantes, mais ils ne le font pas de manière permanente.
Les pics estivaux sont une industrie touristique, mais ils n'ont pas de sauts importants, mais il y a des DDoS dans la saison, généralement lorsque les gens vont acheter des billets pour les vacances de mai.
Consommation normale
Notre client moyen dans notre cloud consomme des ressources par «scie quotidienne»: le matin en début de journée de travail, la montée commence, au déjeuner une courte baisse, le soir une diminution de 2-3 fois. La nuit, les tâches système sont lancées - sauvegardes, débordements de données dans l'analyse, inventaire de détail et calculs d'inventaire logistique, prévisions de ventes. La finance a des antécédents de crédit différents et d'autres caches. Il n'y a pas d'ABS dans le cloud, eux, les opérateurs mobiles et les entreprises comme les chemins de fer ont la compensation la nuit, c'est-à-dire que le solde quotidien de toutes les opérations est réduit. Cela, relativement parlant, ne consiste pas à entrer la nuit, mais à collecter des transactions similaires en paquets et à les compenser les uns les autres pendant la période.
En général, un bureau ordinaire "vit". Les administrateurs les plus avancés prescrivent déjà la mise à l'échelle, mais jusqu'à présent, nous ne voyons que des exemples isolés.
Dans un cas simple, cela ressemble à ceci: élevez une autre machine virtuelle à 11h00, placez-la avec les services dans l'équilibreur, migrez doucement vers 19h00 et payez. Autrement dit, le paiement n'est que pour un tiers de la journée, et aux heures de pointe, la disponibilité est la même qu'avec la location permanente d'une machine virtuelle supplémentaire.
C'est parce que nous avons une discrétisation d'horloge Nos clients sont souvent intéressés par une autre variante de ce script - la mise à l'échelle automatique. Lorsque la consommation de ressources augmente à 80%, une autre machine augmente. Tomber à une certaine limite - la voiture s'éteint. Dans le contrat financier, nous avons le paiement à l'utilisation, c'est-à-dire le post-paiement pour les ressources réellement consommées, la quantification des machines virtuelles à l'heure. Dans la console, vous pouvez soulever vous-même un certain nombre de voitures. L'administrateur entre et le fait avec ses mains sous des charges (par exemple, le Black Friday, lorsque la charge sur le site augmente), ou il écrit un script qui démarre et éteint la machine virtuelle. Il existe une seule entreprise, les développeurs, conditionnellement, des applications bancaires - ils ont besoin d'une mise à l'échelle automatique pour les tests et des pics de broyage de la base de données. Ils ont une architecture très appropriée pour l'automatisation, et avec eux, nous testons un système entièrement automatique lorsque le cloud lui-même alloue la bonne quantité de VM. C'est-à-dire, comment, par lui-même - via un serveur vitnes séparé (une machine virtuelle dédiée ou une machine externe), qui peut gérer la charge, la distribution des applications et l'équilibrage via l'API. Ils obtiennent d'abord la mise à l'échelle automatique, aident à établir correctement les priorités. Et en même temps, ils travaillent comme testeurs pour nous, en fait. Le produit est écrit à très bon marché en fonction de leurs besoins: nous n'avons pas un tel service dans le cloud comme un service plug-in, mais nous expérimentons. Jusqu'à présent, tout est manuel, plus cet alpha: nous avons tous les rapports et les conversations détaillées du technologue produit avec leurs développeurs pour le travail. Ainsi, un produit est né qui sera nécessaire à toutes ces équipes.
Caractéristiques architecturales du logiciel
Pourquoi y a-t-il peu d'administrateurs de mise à l'échelle automatique, bien que cela soit plus rentable? Parce que pour faire évoluer correctement la charge dans le cloud, vous devez disposer d'une application et d'une architecture de base de données préparées. Si une application comme un front Web évolue généralement facilement, l'écriture dans la base de données est déjà une question plus intéressante. Toutes les applications ne sont pas simplement divisées en front-back ou en microservices pour les distribuer sur différentes machines.
Ceux qui l'ont - ceux, bien sûr, épargnent. Et ils obtiennent un plus pour la stabilité, dont nous avons parlé ici dans un article sur
les erreurs d'architecture courantes .
Naturellement, vous devez réécrire le logiciel pour cela. Ce qui n'est pas toujours possible rapidement et pas toujours possible en principe.
Mais la prochaine génération d'histoire du cloud semble encore plus intéressante.
Virtualisation de conteneurs
La prochaine génération est celle des conteneurs. Maintenant, cela ressemble à une sorte de machines virtuelles légères avec des microservices qui montent pendant la manipulation et sont déchargées de la RAM en l'absence d'activité. Autrement dit, ils apparaissent et sont remplacés en tant qu'applications dans la RAM et l'échange de systèmes d'exploitation modernes - tels qu'ils sont utilisés. Cela semble simple, et de nombreux acteurs majeurs ont déjà réécrit leur architecture spécifiquement pour les conteneurs.
Autrement dit, il ne s'agit même pas de machines virtuelles distinctes, mais simplement de processus sur celles-ci, quelque chose comme des applications Citrix Xen. Ou les bonnes vieilles machines virtuelles dans le conteneur, c'est-à-dire les mêmes machines avec une mise à l'échelle automatique approfondie.
Mais ce n'est que la première étape. Le fait est que la conteneurisation des fonctions est encore plus intéressante. C'est toujours un fantasme des architectes, mais si vous écrivez le code immédiatement sous le système de conteneur pop-up, vous pouvez l'envelopper dans chaque fonction. Il y a une entrée, il y a une sortie et il y a une «boîte noire» - le conteneur lui-même. La fonction est appelée dans le code - le conteneur "est apparu", a fonctionné et est retourné attendre le prochain appel.
Le code devra bien entendu refactoriser et ré-optimiser l'ensemble. Mais cela en vaut la peine, et c'est l'une des branches possibles de l'avenir. Selon notre évaluation, il est vrai qu'il est très éloigné - trois ans au moins jusqu'à son introduction par les premiers géants et 15 ans avant son utilisation industrielle en Russie.
En attendant, les conteneurs - hélas, un produit pour les geeks, car ils ne fonctionnent pas très bien. Et il n'y a pas de demande pour eux en Russie, mais il y a des demandes d'autoscaling. Et pas un seul nouveau contrat n'est signé sans paiement à l'utilisation.