Transition de votre infrastructure vers une architecture en tant que code

Perficient nous sommes passionnés par l'encouragement des ingénieurs en tant que généralistes et l'exemple d'une productivité inégalée en modernisant les problèmes d'ingénierie courants. Nous croyons également fermement aux équipes flexibles et à la recherche de solutions uniques qui permettent à un groupe d'individus créatifs de prendre en charge des projets de tous types et de toutes tailles avec une grande efficacité.

Le C loud Development Kit (CDK) et Fargate et e nouveaux services d'AWS qui facilitent la définition et le déploiement de votre infrastructure . Fargate a été introduit en 2017 pour aider les développeurs à se concentrer sur la création d'applications plutôt que sur la gestion de l'infrastructure de cluster. Avec des choix comme Lambda et Fargate l'espace de calcul est amusant mais qu'en est-il de tout le reste? CDK a été introduit en 2019 pour faciliter le amende et connecter toutes vos autres infrastructure cloud . Aujourd'hui, au moment où j'écris ces lignes, le CDK a mûri avec plus de 95 nouvelles versions, et 65 de ces versions dans la dernière année seule . Il s’agit d’une approche axée sur le code pour définir l’infrastructure et prend en charge les principaux langages de programmation préférés. CDK a aussi une astuce pour garder tous les langages de programmation synchronisés donc aucun langage n'a plus de fonctionnalités qu'un autre .

Comme pour toute infrastructure en tant que code approche vous bénéficiez de la flexibilité pour tester, annuler, réviser et automatiser vos modifications d'infrastructure . Mais l'esprit du CDK était quelque chose de plus grand que cela. Il existe de nombreux produits qui proposent une infrastructure sous forme de code, mais du point de vue de l'ingénieur d'application, ils sont en fait de l'infrastructure sous forme de fichiers de configuration ( par exemple CloudFormation ou modèles ARM). Comme CDK supporte de vrais langages de programmation, vous avez la liberté d'avoir des boucles for if conditions et construisant des classes de niveau supérieur pour encapsuler les meilleures pratiques. Au fur et à mesure de la maturation du CDK, AWS et la communauté open source ont également construit des modèles et des composants architecturaux d'ordre supérieur avec AWS suggérant les meilleures pratiques. Cela garantit qu'en utilisant simplement CDK, un ingénieur suit de nombreux principes du AWS Well Architected Framework prêt à l'emploi. Cela a permis un changement majeur: une fois que vous utilisez ces modèles, vous avez l'impression de définir votre architecture plutôt que votre infrastructure. Cela passe de la définition explicite de chaque détail à maintenant implicitement de dire ce que vous voulez et de laisser le CDK comprendre les détails avec les meilleures pratiques AWS que la plupart des gens voudraient . On a presque l'impression d'écrire l'architecture sous forme de code au lieu d'infrastructure. Vous pouvez même intégrer des services AWS existants ( par exemple un VPC existant). Si certaines bonnes pratiques ne correspondent pas à votre cas d'utilisation, vous pouvez éjecter les détails CloudFormation de très bas niveau.

Une fois que vous êtes dans ce changement d'état d'esprit (que vous utilisez l'architecture comme code), cela ouvre beaucoup de portes. Pour voir à quel point le CDK peut simplifier les choses, examinons les exigences pour avoir une API évolutive qui interroge DynamoDB (en gardant à l'esprit que l'alternative sans CDK nécessite des dizaines de milliers de clics dans la console Web AWS ).

Ci-dessus, un exemple de code CDK qui aurait pris des centaines de lignes de CloudFormation. Vous définissez maintenant de gros morceaux de votre architecture, plutôt que de minuscules détails d'infrastructure. Réduire plusieurs ordres de grandeur de détails est une bonne chose, mais même après cela, combien de code faudrait-il pour créer une API typique. Examinons les exigences typiques d'une API qui interroge DynamoDB.

Exigences typiques des API

• Protection DDOS / Limites de limitation basées sur les clés API
• Auth
• Mappage de noms de domaine avec flexibilité des cibles changeant rapidement
• Environnements multiples ( Dev, Staging, Prod, Blue / Green)
• Évolutivité avec maintenance automatique des serveurs
• CI / CD

Using API Gateway, Fargate et CodeStar nous pouvons satisfaire toutes ces exigences. Cela semble simple, mais câbler tous ces services uniquement avec la console Web AWS, ou CloudFormation serait des milliers de clics ou 4500+ lignes de configuration . Le diagramme montre comment câbler ces services. La bonne nouvelle est que le CDK peut construire cela en seulement ~ 150 lignes de code . Vous pouvez consulter le github repo ici avec plus de détails.

Cette 3 0x réduction nous a donné une productivité inégalée, et elle a rendu notre infrastructure plus gérable grâce aux composants architecturaux de plus haut niveau du CDK.

Je travaille dans le groupe Custom Development Solutions. W Nous évaluons toujours les moyens de fournir plus de valeur commerciale, en mettant à jour nos stratégies avec les nouvelles technologies qui ont mûri. Le CDK a rendu nos équipes plus productives en réduisant la complexité de l'infrastructure afin que nous puissions passer plus de temps à construire une pile complète code produit et frapper objectifs commerciaux. Contactez ci-dessous si vous souhaitez entrer en contact avec nous et découvrir comment nous pouvons également aider votre entreprise .

À propos de l'auteur

Quincy Mitchell est ingénieur logiciel au sein de la division Custom Development Solutions pour Perficient. Il adore créer des outils qui aident les ingénieurs à faire plus qu'ils ne peuvent l'imaginer.

Plus de cet auteur