Nous sommes ravis de ramener la transformation 2022 en personne le 19 juillet et pratiquement le 20 au 28 juillet.Rejoignez l'IA et les leaders de données pour des conférences perspicaces et des opportunités de réseautage passionnantes.Inscrivez-vous aujourd'hui!
D'ici 2025, 85% des entreprises auront un principe de cloud-premier - un moyen plus efficace d'héberger des données plutôt que sur site.Le passage au cloud computing amplifié par Covid-19 et les travaux à distance a signifié une série de avantages sociaux pour les entreprises: les coûts informatiques inférieurs, l'efficacité accrue et la sécurité fiable.
Avec cette tendance qui continuait à exploser, la menace de perturbations et de pannes de service augmente également.Les fournisseurs de cloud sont très fiables, mais ils ne sont «pas à l'abri de l'échec.»En décembre 2021, Amazon a rapporté avoir vu plusieurs API Amazon Web Services (AWS) affectées et, en quelques minutes, de nombreux sites Web largement utilisés ont baissé.
Alors, comment les entreprises peuvent-elles atténuer les risques de cloud, se préparer à la prochaine pénurie AWS et s'adapter à des pointes soudaines de demande?
La réponse est l'évolutivité et l'élasticité - deux aspects essentiels du cloud computing qui profitent grandement aux entreprises.Parlons des différences entre l'évolutivité et l'élasticité et voyons comment elles peuvent être construites dans les niveaux d'infrastructure cloud, d'application et de base de données.
Comprendre la différence entre l'évolutivité et l'élasticité
L'évolutivité et l'élasticité sont liées au nombre de demandes qui peuvent être faites simultanément dans un système cloud - elles ne s'excluent pas mutuellement;Les deux peuvent devoir être pris en charge séparément.
L'évolutivité est la capacité d'un système à rester réactif à mesure que le nombre d'utilisateurs et le trafic augmente progressivement au fil du temps.Par conséquent, c'est une croissance à long terme qui est planifiée stratégiquement.La plupart des applications B2B et B2C qui gagnent en usage nécessiteront cela pour garantir la fiabilité, les performances élevées et la disponibilité.
Avec quelques modifications de configuration mineures et clics de bouton, en quelques minutes, une entreprise pourrait faire évoluer ou vers le bas son système cloud en haut.Dans de nombreux cas, cela peut être automatisé par des plates-formes cloud avec des facteurs d'échelle appliqués aux niveaux du serveur, du cluster et du réseau, réduisant les dépenses de main-d'œuvre d'ingénierie.
L'élasticité est la capacité d'un système à rester réactif pendant les rafales à court terme ou les pointes instantanées élevées en charge.Certains exemples de systèmes qui sont régulièrement confrontés à des problèmes d'élasticité comprennent les applications de billetterie de la NFL, les systèmes d'enchères et les compagnies d'assurance pendant les catastrophes naturelles.En 2020, la NFL a pu s'appuyer sur AWS pour diffuser en direct son projet virtuel, quand il avait besoin de beaucoup plus de capacité de nuage.
Une entreprise qui connaît des charges de travail imprévisibles mais ne veut pas d'une stratégie de mise à l'échelle pré-planifiée peut rechercher une solution élastique dans le cloud public, avec des coûts de maintenance inférieurs.Cela serait géré par un fournisseur tiers et partagé avec plusieurs organisations en utilisant Internet public.
Alors, votre entreprise a-t-elle des charges de travail prévisibles, des charges très variables ou les deux?
Élaborez les options de mise à l'échelle avec les infrastructures cloud
En ce qui concerne l'évolutivité, les entreprises doivent faire attention à la suralimentation ou à la sous-provisioning.Cela se produit lorsque les équipes technologiques ne fournissent pas de mesures quantitatives autour des exigences de ressources pour les applications ou que l'idée back-end de mise à l'échelle n'est pas alignée sur les objectifs commerciaux.Pour déterminer une solution de taille droite, les tests de performances continus sont essentiels.
Les chefs d'entreprise lisant ceci doivent parler à leurs équipes technologiques pour découvrir comment ils découvrent leurs schémas d'approvisionnement cloud.Les équipes informatiques devraient mesurer continuellement le temps de réponse, le nombre de demandes, la charge du processeur et l'utilisation de la mémoire pour surveiller le coût des marchandises (COG) associé aux dépenses cloud.
Il existe différentes techniques de mise à l'échelle disponibles pour les organisations en fonction des besoins de l'entreprise et des contraintes techniques.Alors, allez-vous évoluer ou sortir?
Vertical scaling involves scaling up or down and is used for applications that are monolithic, often built prior to 2017, and may be difficult to refactor.Il s'agit d'ajouter plus de ressources telles que la RAM ou la puissance de traitement (CPU) à votre serveur existant lorsque vous avez une charge de travail accrue, mais cela signifie que l'échelle a une limite en fonction de la capacité du serveur.Il ne nécessite aucune modification d'architecture d'application car vous déplacez la même application, les fichiers et la base de données dans une machine plus grande.
Horizontal scaling involves scaling in or out and adding more servers to the original cloud infrastructure to work as a single system.Chaque serveur doit être indépendant afin que les serveurs puissent être ajoutés ou supprimés séparément.Il implique de nombreuses considérations architecturales et de conception autour d'équilibrage de chargement, de gestion de session, de mise en cache et de communication.Les applications héritées migrantes (ou obsolètes) qui ne sont pas conçues pour l'informatique distribuée doivent être soigneusement refactorisées.La mise à l'échelle horizontale est particulièrement importante pour les entreprises avec des services de haute disponibilité nécessitant des temps d'arrêt minimaux et des performances élevées, un stockage et une mémoire.
Si vous ne savez pas quelle technique de mise à l'échelle convient mieux à votre entreprise, vous devrez peut-être envisager une plate-forme d'automatisation en ingénierie cloud tierce pour gérer vos besoins, vos objectifs et votre mise en œuvre.
Peser comment les architectures d'application affectent l'évolutivité et l'élasticité
Prenons également une simple application de santé - qui s'applique également à de nombreuses autres industries - pour voir comment elle peut être développée dans différentes architectures et comment cela a un impact sur l'évolutivité et l'élasticité.Les services de santé étaient fortement sous pression et devaient considérablement évoluer pendant la pandémie Covid-19, et auraient pu bénéficier de solutions basées sur le cloud.
À un niveau élevé, il existe deux types d'architectures: monolithique et distribué. Monolithic (or layered, modular monolith, pipeline, and microkernel) architectures are not natively built for efficient scalability and elasticity — all the modules are contained within the main body of the application and, as a result, the entire application is deployed as a single whole.Il existe trois types d'architectures distribuées: les microservices et les microservices et l'espace.
La simple application de soins de santé a un:
Les services de l'hôpital sont très demandés et pour soutenir la croissance, ils doivent faire évoluer les modules d'enregistrement et de rendez-vous des patients.Cela signifie qu'ils n'ont qu'à faire évoluer le portail du patient, pas le médecin ou les portails de bureau.Voyons comment cette application peut être construite sur chaque architecture.
Architecture monolithique
Les startups technologiques, y compris dans les soins de santé, accompagnent souvent ce modèle traditionnel et unifié pour la conception de logiciels en raison de l'avantage de la vitesse à la mise en marché.Mais ce n'est pas une solution optimale pour les entreprises nécessitant l'évolutivité et l'élasticité.En effet, il existe une seule instance intégrée de l'application et une base de données unique centralisée.
Pour la mise à l'échelle de l'application, l'ajout de plus d'instances de l'application avec un équilibrage de charge finit par étendre les deux autres portails ainsi que le portail patient, même si l'entreprise n'a pas besoin de cela.
La plupart des applications monolithiques utilisent une base de données monolithique - l'une des ressources cloud les plus chères.Les coûts de cloud augmentent de façon exponentielle avec une échelle, et cette disposition est coûteuse, en particulier en ce qui concerne le temps de maintenance des ingénieurs du développement et des opérations.
Un autre aspect qui rend les architectures monolithiques inadaptées à la prise en charge de l'élasticité et de l'évolutivité est le temps moyen vers le startup (MTTS) - le moment où une nouvelle instance de l'application prend pour démarrer.Il faut généralement plusieurs minutes en raison de la grande portée de l'application et de la base de données: les ingénieurs doivent créer les fonctions de support, les dépendances, les objets et les pools de connexion et assurer la sécurité et la connectivité à d'autres services.
Architecture axée sur l'événement
L'architecture axée sur l'événement est mieux adaptée à l'architecture monolithique pour la mise à l'échelle et l'élasticité.Par exemple, il publie un événement où quelque chose de perceptible se produit.Cela pourrait ressembler à des achats sur un site de commerce électronique pendant une période chargée, à commander un article, mais à recevoir un e-mail disant qu'il est en rupture de stock.La messagerie et les files d'attente asynchrones fournissent une pression arrière lorsque la frontale est mise à l'échelle sans mettre à l'échelle de l'arrière par des demandes de file d'attente.
Dans cette étude de cas d'application des soins de santé, cette architecture distribuée signifierait que chaque module est son propre processeur d'événements;Il y a une flexibilité pour distribuer ou partager des données sur un ou plusieurs modules.Il y a une certaine flexibilité à un niveau d'application et de base de données en termes d'échelle car les services ne sont plus couplés.
Architecture de microservices
Cette architecture considère chaque service comme un service à un seul usage, donnant aux entreprises la possibilité de faire évoluer chaque service indépendamment et d'éviter de consommer des ressources précieuses inutilement.Pour la mise à l'échelle de la base de données, la couche de persistance peut être conçue et configurée exclusivement pour chaque service pour la mise à l'échelle individuelle.
Parallèlement à l'architecture axée sur les événements, ces architectures coûtent plus cher en termes de ressources cloud que les architectures monolithiques à de faibles niveaux d'utilisation.Cependant, avec des charges croissantes, des implémentations multitensives et dans les cas où il y a des rafales de trafic, elles sont plus économiques.Le MTTS est également très efficace et peut être mesuré en quelques secondes en raison de services à grain fin.
Cependant, avec le grand nombre de services et de nature distribuée, le débogage peut être plus difficile et il peut y avoir des coûts de maintenance plus élevés si les services ne sont pas entièrement automatisés.
Architecture spatiale
Cette architecture est basée sur un principe appelé traitement transformé par Tuple - plusieurs processeurs parallèles avec de la mémoire partagée.Cette architecture maximise à la fois l'évolutivité et l'élasticité à un niveau d'application et de base de données.
Toutes les interactions d'application ont lieu avec la grille de données en mémoire.Les appels à la grille sont asynchrones et les processeurs d'événements peuvent évoluer indépendamment.Avec la mise à l'échelle de la base de données, il existe un écrivain de données de fond qui lit et met à jour la base de données.Toutes les opérations d'insertion, de mise à jour ou de suppression sont envoyées au rédacteur de données par le service correspondant et en file d'attente pour être ramassé.
MTTS est extrêmement rapide, prenant généralement quelques millisecondes, car toutes les interactions de données sont avec des données en mémoire.Cependant, tous les services doivent se connecter au courtier et la charge de cache initiale doit être créée avec un lecteur de données.
À cette époque numérique, les entreprises souhaitent augmenter ou diminuer les ressources informatiques au besoin pour répondre aux demandes changeantes.La première étape consiste à passer de grands systèmes monolithiques à l'architecture distribuée pour gagner un avantage concurrentiel - c'est ce que Netflix, Lyft, Uber et Google ont fait.Cependant, le choix de laquelle l'architecture est subjective et les décisions doivent être prises en fonction de la capacité des développeurs, de la charge moyenne, de la charge de pointe, des contraintes budgétaires et des objectifs de croissance professionnelle.
Sashank est un entrepreneur en série avec un vif intérêt pour l'innovation.
DataDecisionmakers
Bienvenue dans la communauté VentureBeat!
DataDecisionmakers est l'endroit où les experts, y compris les techniciens qui font du travail de données, peuvent partager des idées liées aux données et l'innovation.
Si vous souhaitez lire sur les idées de pointe et les informations à jour, les meilleures pratiques et l'avenir de la technologie des données et des données, rejoignez-nous chez DataDecisionmakers.
Vous pourriez même envisager de contribuer votre propre article!
En savoir plus sur DataDecisionmakers
