Disons que vous travaillez sur un projet entièrement nouveau pour développer un nouveau jeu ou une nouvelle application Web. Super! Avec une approche greenfield, vous pouvez choisir où héberger votre projet, quels services tiers utiliser et lesquels construire. Par exemple, l’hébergement sur Azure peut être une excellente idée car vos ingénieurs DevOps et SRE connaissent déjà cette plateforme d’hébergement.

Il peut également être important d’examiner certains des excellents services d’apprentissage automatique sur AWS afin que l’équipe puisse innover plus rapidement et itérer de nouvelles fonctionnalités dans le jeu en fonction de la façon dont les joueurs l’utilisent. Par exemple, avec SageMaker Canvas, votre équipe peut rapidement faire des prédictions ML sur la façon dont l’utilisateur navigue dans le monde virtuel et réintégrer ces informations dans le jeu.

Ou peut-être est-il nécessaire de stocker des données en temps réel à des fins de surveillance et de tableau de bord dans un entrepôt comme Datadog ou New Relic. Il existe différents défis et de nombreuses solutions, alors explorons-en quelques-unes.

Systèmes disparates

L’approche décrite ci-dessus est courante et parfois appelée architecture disparate ou Démocratisation de la technologie. Les avantages sont évidents. L’utilisation de services et d’applications déjà disponibles et testés au combat accélère le processus de livraison.

Les services peuvent être séparés à l’aide de séparation des préoccupations modèle de conception de principe, ce qui signifie que l’application peut être plus facilement mise à l’échelle. Cela se fait en ajoutant plus d’instances spécifiques au service selon les besoins plutôt qu’en faisant évoluer l’ensemble du système.

disparates, ou « cross-cloud » l’hébergement, est plus courant lors de l’ajout ou de la croissance d’applications actuelles que de projets entièrement nouveaux en raison des risques liés au déplacement de composants établis et de la commercialisation disponibilité les accords.

Sécurité et Surveillance

Même avec des projets de jeu entièrement nouveaux, les avantages d’un hébergement disparate peuvent l’emporter sur le coût, et des décisions positives doivent être prises pour concevoir les plates-formes séparément, comme décrit ci-dessus. L’un des coûts importants de cette décision concerne la sécurité et la surveillance. Cette approche se traduit souvent par l’application ‘angles morts’ où aucune partie spécifique du système multidépendant ne contrôle la surveillance.

En outre, « fatigue d’alerte », où plusieurs systèmes signalent le même problème, et/ou le problème est déjà connu et considéré comme une priorité faible, ou le problème est sur-signalé, peut-être en raison d’un mécanisme d’alerte trop actif. Tous ces problèmes peuvent faire en sorte que des problèmes plus importants soient manqués ou négligés.

La solution à ces problèmes est souvent une consolidation du reporting et de la protection des applications à l’aide d’un Plate-forme de protection des applications natives du cloud (CNAPP). Les CNAPP combinent les multiples fonctionnalités de la sécurité du cloud, de la conformité, de la charge de travail, de la gestion des droits et de la sécurité des conteneurs en une seule plate-forme.

Cela se traduit par un coût de possession inférieur et des alertes et des rapports plus rapides et plus cohérents. Lorsque des plates-formes de sécurité distinctes entraînent une augmentation des coûts et de la complexité, les CNAPP permettent de jeter les bases d’un tissu de sécurité continu et souvent sans investissement important dans les outils ou l’attention des développeurs.

Nuage natif

La décision la plus cruciale sera sans doute de construire, dès le premier jour, un natif du cloud plate-forme par opposition à un système plus organiquement développé qui se développe au fil du temps et dépend d’une infrastructure dédiée. Cloud-native (également appelé cloud-first) est principalement une décision de créer une application principalement hébergée dans le cloud plutôt que d’utiliser des serveurs dédiés.

Bien que cela puisse sembler évident pour certains, il est essentiel que cela soit communiqué comme une décision architecturale positive au début de tout projet de développement. Énoncer cette décision implique clairement plusieurs faits pour les différents membres d’une équipe. Les développeurs et les architectes peuvent être en mesure d’utiliser des services et fonctionnalités prédéfinis spécifiques. Les testeurs peuvent utiliser des outils natifs pour cette plate-forme. Et surtout, les ingénieurs DevOps et Site Reliability connaissent et comprennent les limites du système qu’ils doivent protéger et sécuriser.

Ce concept va plus loin de deux manières spécifiques, architecture serveur vs sans serveur et microservice. Les plates-formes natives du cloud peuvent toujours être exécutées sur des serveurs dédiés, et bien que méprisée par certains, cette approche a ses avantages, même s’ils sont certes à court terme.

Par exemple, il peut être nécessaire de créer très rapidement une application MVP (minimal viable product) ou POC (proof of concept). Ceux-ci sont parfois utilisés pour prouver des fonctionnalités à des investisseurs potentiels ou pour montrer qu’une plate-forme ou une application n’est pas seulement un vapourware. Bien sûr, nous voulons certainement que notre application soit construite de manière évolutive à terme, mais c’est à cela que servent les versions majeures, n’est-ce pas ?

L’informatique traditionnelle basée sur serveur peut être plus rapide à mettre en place initialement, mais elle dispose de ressources fixes qui doivent être provisionnées, et les développeurs doivent tenir compte des limitations physiques du matériel physique (ou virtuel). D’un autre côté, l’informatique sans serveur n’a aucune de ces limitations du point de vue des développeurs. L’infrastructure cloud prend en charge la gestion des machines virtuelles, l’allocation du matériel et des tâches spécifiques telles que le multithreading. La conteneurisation est un élément clé et doit être pris en compte lors du développement pour tirer parti de ces avantages.

Convenir d’une approche basée sur les microservices est un point de décision similaire à discuter et à convenir dès le départ. Ne pas utiliser les microservices dès le premier jour entraînera probablement des difficultés plus tard dans le cycle de vie du développement logiciel et la réécriture, ou au minimum la réaffectation du code, qui sont toutes deux coûteuses et chronophages.