Avez-vous manqué la première et la deuxième partie de cette série en plusieurs parties sur “l’optimisation des coûts” ?
Dans la partie 3 de cette série de blogs en plusieurs parties, je vais couvrir, selon le titre “Optimisation des coûts architecturaux”.
Dans des articles précédents, j’ai parlé des primitives fondamentales, de ce que vous pouvez modifier et régler dans le cloud sans changer vos applications.
Mais tu sais quoi? Les architectures peuvent évoluer, et elles doivent évoluer grâce à l’efficacité commerciale et aux économies de coûts.
Si vous êtes un architecte ou un développeur qui nous rejoint aujourd’hui, vous êtes incroyablement chanceux car chaque jour vous avez de nouveaux leviers à actionner.
Les deux principaux Hyperscalers (Azur et AWS) a publié plus de 2 000 nouvelles mises à jour de fonctionnalités et/ou de nouveaux services en 2022.
Vous pouvez les tirer vers le haut, vous pouvez les tirer vers le bas, tout est une question de choix. Mais n’est-ce pas cool avec des décisions intelligentes ; vous pouvez actionner différents leviers et obtenir différents résultats.
Vous pouvez faire des changements de code. C’est souvent la meilleure façon de résoudre les problèmes dans de nombreux cas. Je suis sûr que nous pourrions comprendre le nombre de fois où nous avons parlé à un client ou à un intervenant interne d’une application qui fonctionne terriblement et plutôt que de la réparer, nous utilisons l’infrastructure comme un pansement.
Dans la partie 3 de cette série, je vais illustrer que peut-être plus que jamais, vous devriez simplement réparer cette application en premier lieu, gravir la courbe de maturité du cloud et vous mettre au défi, notez simplement qu’il y a toujours des compromis architecturaux à faire.
Aujourd’hui, il y a bien plus de décisions que vous n’avez jamais eu à prendre auparavant, d’une part c’est difficile parce que vous devez en savoir plus, mais d’autre part c’est génial parce que vous avez plus de choix et vous pouvez prendre de meilleures décisions plus finement affinées et vous pouvez les tester en temps réel pour voir s’ils ont un sens.
Avec le cloud public, vous n’êtes pas assis douze mois avant le déploiement, je pense que si j’utilise ce type d’approche, ça ira.
Vous pouvez dire eh bien j’ai essayé ça, ça n’a pas marché, et je vais passer une semaine et le changer pour quelque chose de complètement différent et ça va. C’est vraiment bien, alors parlons de certains de ces leviers et de certaines de ces astuces que vous pouvez utiliser pour réduire les coûts en modifiant votre architecture.
Éliminez votre niveau de serveur Web et utilisez des applications Web statiques
Débarrassez-vous de vos serveurs Web. Cette pensée vous a-t-elle déjà traversé l’esprit ?
Je suis sûr que tout le monde ici a des serveurs Web qu’il gère, mais en avez-vous vraiment besoin ? Que font-ils vraiment ?
De nos jours, avec les frameworks Web modernes, vous pouvez éliminer votre niveau de serveur Web. Ils sont coûteux, augmentent votre zone d’attaque de surface de sécurité. Avec l’ère du calcul à la périphérie (Porte d’entrée azur / Travailleurs CloudFlare / Travailleurs périphériques d’Akamai / Fonctions CloudFront), êtes-vous vraiment en train de passer la plupart de votre temps à corriger l’amélioration de l’alimentation et à vous en occuper.
Une approche moderne à adopter est celle des applications Web statiques.
Je vais dire que c’est une sorte de mauvaise réputation (opinion personnelle) car ce n’est pas si statique. C’est 2023. Le monde tourne Javascript (ECMA) et vous pouvez faire beaucoup de choses.
Vous effectuez des appels d’API, invoquez un SDK (Azure et AWS JavaScript), appelez des API Gateways (Azure API-M et Passerelle d’API Amazon) et plus.
Applications Web statiques prend en charge JavaScript et Manuscrit applications frontales, y compris celles développées avec des frameworks populaires tels que Vue.js, Réagir, Angulaire et plus. Les applications SPA ou à page unique deviennent rapidement la norme dans le développement basé sur le cloud.
Dans le fil de cette série en plusieurs parties, élevez l’histoire de haut en bas. Vous ne corrigez pas les serveurs, il n’y a pas de règles de mise à l’échelle à craindre, cela fonctionne, qu’est-ce que cela me coûte d’exécuter ?
| Objet moyen par page | 150 |
| Taille moyenne des pages | 2 Mo |
| Pages vues par jour (GET) | 100 000 (450 000 000 par mois) |
| Sortie de transfert de données par mois | 5,8 To |
| Coût total (applications Web statiques Azure) | 1 176 USD (Australie-Est | décembre 2022) |
| D4v5 – Qté de 6 | 1 538 USD (Australie-Est | décembre 2022) |
Static WebApps, je mets au défi tout le monde ici aujourd’hui de jeter un coup d’œil et d’envisager les possibilités si vous en avez vraiment besoin apache, NginXou IIS machines autour ?
Architectures économiques des bases de données
Tout n’est pas SQL ou NoSQL.
Vous avez peut-être entendu parler du proverbe “tous les chemins mènent à Rome”. Dans le monde des applications, Rome est souvent votre base de données relationnelle. Votre objectif en tant qu’architecte cloud moderne est de réduire CRUD appels à leur minimum.
Une approche pour y parvenir consiste à utiliser une base de données NoSQL et la mise en cache comme mécanisme non seulement pour apporter de la vitesse, mais aussi pour réduire les coûts.
Si vous regardez n’importe quelle application à l’échelle du Web, elle a une mise en cache partout. C’est la nouvelle normalité et nous devons en profiter davantage. Ne confondez pas votre base de données transactionnelle avec votre base de données analytique, il y a une raison pour laquelle un service de reporting existe et pourquoi un moteur de base de données relationnelle existe. Pour les mêmes raisons que vous sépareriez ces charges de travail assez souvent, il y aura des points chauds dans vos bases de données, et ce sont les cadeaux où une refactorisation ou un autre outil plus approprié peut être utilisé.
Je ne dis pas que les performances de la base de données relationnelle sont terribles, passons le tout à Base de données Cosmos, MongoDB, DynamoDB ou similaire, car il y a des avantages et des inconvénients à chaque solution.
La mise en cache des bonnes parties de votre application dans un cache en mémoire ou l’utilisation de NoSQL peut changer la donne.
Alors que ce schéma provient de Microsoftje veux vous parler de mon temps à recherche.com.au avec environ 20 000 utilisateurs simultanés, stockant l’état de la session dans une base de données relationnelle. C’est devenu un exercice coûteux pour s’assurer que la base de données relationnelle pouvait prendre en charge une telle simultanéité d’utilisateurs avec une faible latence.
Les avantages en termes de performances et de coûts pour l’entreprise étaient évidents lors du passage à un cache en mémoire. Les développeurs sont attentifs et les récents (2022) Enquête auprès des développeurs de débordement de pile montre clairement la popularité de NoSQL et des caches en mémoire.
L’architecture peut évoluer
Les architectures peuvent en effet évoluer et c’est donc l’heure de la démo. Rendons cela réel et nous allons créer une application. Cette application va illustrer que nous pouvons fournir la même fonctionnalité et le même résultat commercial de plusieurs manières différentes, toutes avec des profils de coûts très différents. Cette application que j’appelle ‘Toilet Finder’. J’utiliserai différents types de calcul, mais en laissant le MySQL base de données comme une constante.
En Australie, le gouvernement australien publie un ensemble de données sur toutes les toilettes publiques d’Australie (https://data.gov.au/data/dataset/national-public-toilet-map) qui comprend diverses propriétés telles que l’emplacement, le nombre ou les toilettes, les tables à langer, etc. Cet ensemble de données est un CSV qui contient 18 408 enregistrements (2022) et nous allons créer un microservice qui, lorsqu’il sera présenté avec un code postal (chaîne de requête), renverra une charge utile JSON de toutes les toilettes publiques pour ce code postal.
Avant d’examiner nos topologies de déploiement, examinons le code Python dans lequel nous allons nous exécuter. Il s’agit d’un extrait de code très simple ; il utilise le serveur Web intégré à Python appelé Bouteille. Il existe un itinéraire pour / code postal (pensez au code postal mais pour l’Australie) et une validation de base pour vérifier si le code postal comporte 4 chiffres.
import os
import mysql.connector
import json
import string
from bottle import route, run, template
@route("
def index():
return 'Hello World'
@route('/postcode/')
def postcode(postcode):
returnData = "INVALID input"
#Validate input - can only be 4 numerics
if len(postcode) == 4 and postcode.isdigit():
#MYSQL Connection
cnx = mysql.connector.connect(user="xxxxxx@toilet-mysql", password='xxxxxxxxx',
host="toilet-mysql.mysql.database.azure.com",
database="toiletdata")
#Query
cursor = cnx.cursor()
query = ("SELECT name, address1, town FROM toilets "
"WHERE postcode=" + postcode)
cursor.execute(query)
resultRow = ""
for (name, address1, town) in cursor:
resultRow = resultRow + json.dumps({'name' : name, 'address1': address1, 'town': town}) + ","
resultRow = resultRow.rstrip(",")
cursor.close()
cnx.close()
returnData = "[" + resultRow + "]"
return returnData
#print __name__
if __name__ == '__main__':
port = int(os.environ.get('PORT', 8080))
run(host="0.0.0.0", port=port, debug=True)
Déploiement typique de VM
L’image ci-dessous montre comment vous pouvez déployer cette solution à l’aide de machines virtuelles. Comme nous voulons que cela soit fiable, nous devrons utiliser plusieurs machines virtuelles dans un Ensemble d’échelles de VM / Groupe de mise à l’échelle automatique et même en utilisant modeste B2M (2vCPU) instances extensibles, mon coût de calcul mensuel sera de 154 USD (décembre 2022 / Australie-Est).
Cette topologie, tout en étant évolutive, fiable et familière à utiliser, est lourde en termes de stockage et de fonctionnement. J’ai encore besoin de patcher et de gérer les serveurs.
Déploiement de conteneur
L’image ci-dessous montre comment vous pouvez déployer cette solution à l’aide de conteneurs. En évoluant à partir de nos VM, nous allons réaliser des scale-up et des scale-down plus rapides. Il va être fiable et c’est un conteneur. J’utilise Azure Container Instances où je paierai en fonction de ma consommation. Je n’ai plus besoin de maintenir et de gérer des machines virtuelles, mais j’utilise à la place un fichier docker qui indique comment créer mes conteneurs. J’héberge ceci dans Azure Container Registry qui est exécuté par Azure Container Instances.
FROM python:3.8
RUN mkdir /code
ADD requirements.txt /code/
ADD application.py /code/
ADD bottle.py /code/
RUN pip3 install bottle
RUN pip3 install mysql-connector
WORKDIR /code
EXPOSE 8080
CMD python /code/application.py
Fonctions et architecture pilotée par les événements
L’image ci-dessous illustre comment vous pouvez déployer cette solution à l’aide d’Azure Functions et est similaire si vous utilisez AWS Lambda. Comme notre offre de conteneurs, celle-ci est légère, ne nécessite aucune mise à jour des serveurs et, compte tenu de notre charge modeste, s’intègre dans le niveau gratuit.
À noter, il y aura une pénalité de premier coup / démarrage à froid dans laquelle vous pouvez voir dans la démo ci-dessous, ce qui n’est vraiment pas un problème pour les charges de travail avec des profils de trafic cohérents.
Démonstration vidéo
Dans la vidéo non classée ci-dessous, vous verrez une démonstration des 3 méthodes permettant d’obtenir le même résultat commercial à 3 profils de coûts très différents. Les machines virtuelles, les conteneurs, les fonctions vous fournissent tous, en tant que constructeurs, des méthodes pour créer les mêmes résultats, mais je veux que vous réfléchissiez à l’économie de votre architecture, est-ce que cela vous préoccupe ?
Résumé – L’économie, la prochaine dimension de l’architecture cloud
Alors que je termine cette série en plusieurs parties, je veux que vous réalisiez que vous devriez exiger le même résultat ou un meilleur résultat à moindre coût.
Les architectures doivent évoluer pendant la durée de vie d’un système et des changements radicaux sont possibles, motivés par l’économie (coût de transition + coût opérationnel). Le cloud public offre une multitude d’opportunités aux constructeurs et aux architectes.
Cherchez-vous les pots d’or? Ils sont là avec une série de nouveaux leviers que vous pouvez tirer, tordre, tirer pour concevoir le nouveau monde. Montez la courbe de maturité du cloud et obtenez le même résultat ou un meilleur résultat à moindre coût. Les architectures peuvent évoluer, mais elles doivent avoir un sens et avec de nouveaux outils et leviers publiés quotidiennement, le coût du changement ne fait que diminuer.
Merci
Canopée de Shane.
