Dans notre article précédent de cette série, nous avons parlé de l’exemple d’architecture d’analyse prédictive trouvée dans une solution de diagnostic médical de pointe pour le secteur de la santé.
Le processus a été expliqué comment nous avons abordé le cas d’utilisation et comment les solutions de portefeuille sont la base de la recherche d’une architecture générique. Il s’est poursuivi par une discussion sur la façon dont nous avons abordé le cas d’utilisation en recherchant des solutions de portefeuille de clients réussies comme base pour une architecture générique.
Il est maintenant temps d’examiner un dernier exemple d’architecture.
Cet article vous guide à travers un exemple d’architecture d’utilisation de GitOps pour fournir un exemple de déploiement et de développement pour des scénarios de diagnostic médical de pointe.
Revue d’architecture
Comme mentionné précédemment, les détails architecturaux couverts ici sont basés sur des solutions réelles utilisant des technologies open source. L’exemple de scénario présenté ici est un générique commun architecture qui a été découverte lors de la recherche de ces solutions. Notre intention est de fournir des conseils et non des détails techniques approfondis.
Cette section couvre les représentations visuelles telles qu’elles sont présentées, mais il est prévu qu’elles évoluent en fonction des recherches futures. Il existe de nombreuses façons de représenter chaque élément de cette architecture, mais nous avons choisi un format qui, nous l’espérons, le rend facile à assimiler. N’hésitez pas à poster des commentaires au bas de cet article, ou contactez-nous directement avec vos commentaires.
Examinons maintenant les détails de cette architecture et décrivons la solution pour deux vues de la solution d’architecture de diagnostic médical de pointe.
Diagnostic médical de pointe avec GitOps
Après avoir parcouru l’architecture de la solution et les éléments de l’article précédent liés au diagnostic médical de pointe, ce schéma nous montre quelque chose de complètement différent. C’est une question de perspective et maintenant nous l’examinons du point de vue du développement et des opérations, en utilisant l’objectif de GitOps.
Dans le schéma ci-dessus, nous commençons du côté droit par le développeur et opérations informatiques utilisateurs, qui développent tous deux leurs propres bases de code spécifiques. Les développeur travaille sur des services, des applications et d’autres aspects d’intégration dans leurs projets. Plus dans opérations informatiques ils concernent les déploiements et l’infrastructure en tant que code pour l’agilité et l’évolutivité, en utilisant par exemple la configuration en tant que projets de code.
Ces deux utilisateurs poussent leurs contributions dans le système de gestion du code source (SCM) où il est ensuite tiré dans le Pipeline CI/CD pour le traitement de construction qui pourrait nécessiter l’utilisation, par exemple, d’images de base standard de la télécommande référentiel d’images (présenté ici en tant que référentiel Red Hat).
Ces builds génèrent des images d’application et de service dans le référentiel d’images pour développeurs qui est ensuite poussé vers l’abonné installations de diagnostic Sur le terrain. Pour le opérations informatiques vous verrez leur configuration et leur code manifeste poussés vers les abonnés installations de diagnostic où ils hébergent systèmes de gestion de code source (SCM) Sur le terrain.
À ce stade, nous passons notre discussion à la centre de diagnostic où l’application sur le terrain des solutions de diagnostic médical est appliquée. UNE GitOps peut être trouvé qui utilise Argo CD pour gérer des ressources spécifiques, y compris des images et des configurations et des manifestes basés sur le code des opérations pour définir la gestion des utilisateurs, des déploiements et des comportements architecturaux.
Enfin, nous voyons tout cela se concrétiser à l’extrême gauche de ce diagramme alors que le avion de contrôle, une plate-forme de conteneurs basée sur OpenShift, héberge les différents services et applications dans leurs environnements d’exécution basés sur des conteneurs.
Ensuite, un regard sur la solution architecturale en mettant l’accent sur la vue des données.
Diagnostic médical Edge avec GitOps (données)
La connectivité des données via l’architecture de diagnostic médical de pointe avec GitOps offre un regard différent sur l’architecture et nous donne un aperçu de la façon dont l’un des actifs les plus précieux d’une organisation de soins de santé est traité.
Il doit être considéré comme l’architecture est conçue, comme un guide et non une déclaration définitive à faire de cette façon sur la façon dont les données sont acheminées à mesure que les acteurs s’engagent avec les systèmes, les applications et les services dans cette architecture .
Notez que la plupart des données ne circulent que dans un sens alors qu’il est assez évident qu’elles vont circuler dans les deux sens. Nous avons choisi de noter que dans les flux qui ne perturbent pas la clarté du diagramme d’architecture, et avons choisi de ne pas indiquer où l’intention est d’afficher le traitement et les flux pour plus de clarté des acteurs aux systèmes sur le backend.
Il appartient au lecteur d’explorer ces diagrammes de données et n’hésitez pas à nous envoyer des commentaires.
Et après
Ce n’était qu’un bref aperçu des éléments génériques communs qui composent notre architecture pour le diagnostic médical de pointe cas d’utilisation.
Un aperçu de cette série sur architecture de diagnostic médical de pointe:
- Présentation architecturale
- Éléments architecturaux communs
- Exemple d’analyse prédictive
- Exemple d’architecture avec GitOps
Retrouvez tous les articles passés que vous avez manqués en suivant les liens publiés ci-dessus.
Ceci termine la série et nous espérons que vous avez apprécié cette visite architecturale de diagnostic médical de pointe.