Considérations et modèles d'hébergement Cloud
Pour les éditeurs de logiciel (ISV)
Les éditeurs de logiciel (ISV) ont besoin d'une plate-forme et de services d'infrastructure sécurisés, évolutifs et fiables pour héberger leurs applications. Plus encore que les entreprises de technologies de l'information qui exploitent un système de back-office dans le Cloud, les ISV doivent faire face à des opérations 24h/24 et 7j/7, à des déploiements géographiquement diversifiés, à des modèles de trafic client dynamiques qui peuvent nécessiter une évolutivité élastique, ainsi qu'à des défis en matière de sécurité liés à l'exposition de leur application à l'Internet public.
Un ISV qui migre vers un ou plusieurs fournisseurs Cloud à grande échelle ou qui opère sur ces derniers doit prendre en compte un certain nombre de décisions et de modèles importants. Devriez-vous adopter une stratégie lift-and-shift consistant à déplacer votre application telle quelle, ou bien profiter d'une migration vers le Cloud pour repenser l'architecture de manière à ce qu'elle soit davantage Cloud native et éventuellement commencer à exploiter les services PaaS gérés d'un fournisseur ? Un déploiement dans le Cloud peut-il transformer votre position de réelle disponibilité (HA) et de récupération après sinistre (DR) en introduisant la possibilité d'exploiter des domaines de pannes dans le datacenter, des domaines de disponibilité dans la région ou des interconnexions interrégionales ? Quels outils votre fournisseur Cloud vous offre-t-il pour sécuriser vos données, votre réseau interne, vos hôtes/conteneurs de calcul, ainsi que vos interactions avec vos clients ? Enfin, déployez-vous votre application en tant que SaaS colocatif ou dans une configuration à locataire unique pour chacun de vos clients ?
Outre les centaines d'applications qu'Oracle a migré vers OCI, notre équipe d'ingénierie Cloud a aidé des dizaines d'ISV à planifier et à passer à OCI. Ce microsite fournit des conseils et présente différents modèles d'hébergement pour les éditeurs de logiciels.
Nous explorons divers sujets dans le cadre de différentes approches d'adoption d'Oracle Cloud.
Ce microsite n'est pas destiné à être lu de manière linéaire. Le diagramme ci-dessous représente visuellement le processus que vous pouvez suivre sur ce site en fonction de votre profil. Après avoir terminé cette introduction, veuillez lire la section Notre processus puis, en fonction de votre modèle d'hébergement actuel, poursuivez avec la section Nés dans le Cloud ou Sur site/colocation. Ensuite, lisez la section SaaS colocatif ou SaaS à locataire unique en fonction de votre modèle de distribution d'applications. Enfin, nous recommandons à tous les lecteurs de consulter les sections générales Questions transversales et le Récapitulatif.
Notre processus
- Nés dans le Cloud
- Sur site/colocation
- Modèle de distribution d'applications colocatif
- Modèle de distribution d'applications à locataire unique
De nombreux fournisseurs ISV de solutions SaaS sont "nés dans le Cloud", ce qui pourrait s'apparenter à "Cloud natifs", mais ce n'est pas toujours le cas. L'expression Né dans le Cloud implique généralement la volonté de ne plus être associé aux systèmes existants et d'être construit selon des principes de conception d'applications modernes. La conception d'applications modernes est l'orientation architecturale qui concrétise les principes décrits dans la méthodologie d'application à douze facteurs. Cette approche n'est pas identique à l'architecture Cloud native, même si elles sont étroitement liées. Si vous cherchez plus d'informations sur l'informatique Cloud natif du point de vue d'Oracle, il est intéressant de consulter Modèles Cloud natifs, un eBook axé sur la conception d'une architecture Cloud native.
Que l'application SaaS soit conçue selon les principes de la conception d'applications modernes ou ceux de l'approche Cloud native, certains facteurs clés sont les mêmes :
- Volonté de suivre les principes de développement d'applications modernes
- Volonté de se concentrer sur l'application et non sur l'infrastructure
- Réduction du délai de rentabilité des fonctionnalités
- Déploiements continus, fiables et reproductibles
- Dissociation de ce qui est considéré comme des systèmes "hérités" ou à fournisseur unique
- Volonté de créer, d'exploiter et de soutenir une architecture moderne
- Volonté d'opérer avec la flexibilité que permet le Cloud
Les ISV qui ont commencé avec ces objectifs ont généralement une architecture de services plus découplée. Les composants d'application dans leur charge de travail peuvent être déployés indépendamment, souvent sous forme de conteneurs, et l'architecture de l'application est conçue pour assurer la continuité de l'application en cas de panne de composants. Les applications doivent non seulement gérer la cohérence des données, mais également la disponibilité de l'application.
Selon l'architecture d'exécution choisie, l'ISV aura probablement intégré la surveillance et les notifications dans le contrôle de son infrastructure. OCI fournit des services pour prendre en charge :
- CNCF Cloud Events avec notre Cloud Events Service
- CNCF OpenTracing, qui fait partie de notre Cloud Observability and Management Platform, offre une interopérabilité complète avec les fonctions Cloud (sans serveur) et le service de notification. Ainsi, non seulement la gestion du cycle de vie de votre parc de serveurs est simplifiée, mais les tâches de gouvernance sont également facilitées.
La communication entre les composants met généralement en oeuvre un modèle asynchrone dans lequel les composants génèrent des événements et réagissent à ceux-ci plutôt qu'à des instructions directes. OCI propose le service Streaming. Il s'agit d'un service de streaming sans serveur compatible avec Kafka, qui est souvent utilisé pour gérer ce type de communication. L'avantage de cette approche est la protection des composants en cas de panne, le rayon d'explosion étant réduit par une mise en file d'attente ou un routage intelligents.
Une dissociation supplémentaire est obtenue en séparant les applications de l'infrastructure. L'élasticité est souvent rendue possible par l'utilisation des mécanismes de mise à l'échelle automatique fournis par les prestataires de services Cloud (CSP). La mise à l'échelle automatique peut se faire au niveau des conteneurs en utilisant Oracle Container Engine for Kubernetes (OKE), au niveau du regroupement des instances ou au niveau des groupes de serveurs.
Au fil du temps, certaines applications SaaS commencent à s'écarter de leur architecture standardisée initialement prévue, car les équipes profitent des services PaaS natifs fournis par un seul CSP. En voici quelques exemples : l'utilisation d'un service de gestion des données propre à un seul Cloud, l'intégration d'un appel direct API à une plate-forme NoSQL propre à un fournisseur sans couches d'abstraction appropriées dans l'implémentation en vue d'un remplacement futur, l'utilisation d'IDE qui génèrent du code spécifique au fournisseur. Pour maintenir la portabilité Cloud, les ISV doivent veiller à équilibrer la commodité d'un service de plate-forme avec les risques de dépendance vis-à-vis d'un seul fournisseur qui peuvent résulter si le service n'est pas neutre par rapport au fournisseur. De nombreux ISV ont entamé un processus de remodernisation de leurs applications, dans le but d'avoir une véritable gamme de solutions multicloud. Pour ce faire, ils réexaminent les points de couplage étroits avec les technologies à fournisseur unique ou à usage unique.
Au fil du temps, il pourrait y avoir une dérive de la configuration de l'infrastructure. La plupart des ISV adoptent une approche d'infrastructure en tant que code (IaC) et OCI prend en charge les outils standard, mais va encore plus loin. OCI Resource Manager, un service Terraform géré, peut être utilisé pour surveiller, suivre et réparer des dérives de l'infrastructure.
Une implémentation de type Lift and Shift consiste à migrer vos charges de travail de production, exécutées sur site ou dans une installation de colocation, vers Oracle Cloud Infrastructure (OCI). Dans certains cas, vous souhaiterez peut-être profiter des services Cloud natifs d'OCI pour enrichir vos applications. Cette activité dite de "déplacement et d'amélioration" est une autre bonne raison de passer à OCI. Les sections suivantes traitent du processus Lift-and-Shift et abordent les considérations relatives à la stratégie de déplacement et d'amélioration, si nécessaire.
Ce scénario est parfaitement adapté aux ISV qui cherchent à bénéficier d'une réduction des dépenses d'investissement et à déléguer certaines tâches opérationnelles complexes en matière de disponibilité, de sécurité et de performances à un prestataire de service Cloud (CSP) tel qu'Oracle. En règle générale, un ISV mettra en oeuvre l'une des stratégies suivantes :
- Lift and Shift : migration de leurs applications sur site ou colocalisées vers OCI
- Déplacement et amélioration : migration des applications sur site ou colocalisées vers OCI, puis enrichissement de ces applications en tirant parti des services Cloud natifs ou en migrant des bases de données vers des offres Cloud.
Rien ne vous empêche de mélanger ces stratégies, lorsque certaines charges de travail sont déplacées telles quelles, mais que d'autres sont modifiées pour tirer parti des services gérés OCI (PaaS).
Lift and Shift
La stratégie de migration vers le Cloud nommée "Lift and Shift" consiste à déplacer votre application sur site vers OCI, de sorte que le déploiement qui en résulte soit très similaire au déploiement sur site. La première étape de ce processus consiste à déterminer les charges de travail/applications qui vous permettront de tirer parti des fonctionnalités d'OCI et d'atteindre vos objectifs stratégiques. Nous proposons différentes modalités d'hébergement parmi lesquelles vous pouvez choisir en fonction de vos exigences en matière de résidence des données, de latence et de connectivité. Quel que soit le type d'hébergement que vous choisissez, vous avez accès au portefeuille complet d'OCI.
| Type d'hébergement | Description |
|---|---|
| Cloud public | Vaste plate-forme de services IaaS, PaaS et SaaS |
| Government Cloud (domaines restreints) | Government Cloud (domaines restreints) : vaste plate-forme de services IaaS, PaaS et SaaS déployée dans un domaine restreint pour les organismes du secteur public |
| Dedicated Region Cloud@Customer | Vaste plate-forme de services IaaS, PaaS et SaaS déployée dans votre datacenter |
| Roving Edge Infrastructure | Vaste plate-forme de services IaaS, PaaS et SaaS déployée dans des dispositifs Oracle Roving Edge Devices (Oracle RED) renforcés offrant des services de Cloud-Computing et de stockage à la périphérie des réseaux et dans des emplacements déconnectés |
| Oracle Cloud VMware | Déplacez les charges de travail VMware vers le Cloud ou étendez votre VCenter sur site pour inclure le Cloud sans avoir à restructurer les applications ou à réorganiser les opérations. |
Lorsque vous concevez votre architecture Cloud, gardez à l'esprit qu'Oracle prend en charge un large éventail options de connectivité réseau qui vous permettent de concevoir une solution de Cloud hybride associant des ressources OCI à des composants exécutés dans votre datacenter, ou une solution multicloud qui interconnecte votre gamme OCI avec celle d'un autre prestataire de services Cloud. Ces deux approches sont très courantes et peuvent faciliter la migration des dépendances de charge de travail pour les applications existantes exécutées sur site ou dans les environnements d'autres fournisseurs Cloud, afin de répondre aux exigences en matière de résidence des données, aux contrats de niveau de service informatique ou à d'autres exigences.
OCI permet cette communication sur l'Internet public, via un VPN IPSec, ou via une connectivité dédiée (FastConnect). Le tableau suivant décrit quelques-unes des caractéristiques de chaque approche :
| Méthode | Latence | Coût | Fiabilité | Sécurité |
|---|---|---|---|---|
| Internet public | Variable | Variable | Variable | Moins sécurisé |
| VPN IPSec | Variable | Variable | Variable | Le trafic est crypté, mais le tunnel passe par l'Internet public |
| OCI FastConnect | Faible et prévisible | Prévisible | Le plus fiable | Le plus sécurisé ; le trafic passe par une connexion privée |
En outre, bien que l'interconnexion Cloud-Cloud soit possible entre OCI et tout autre Cloud à l'aide des technologies susmentionnées, Oracle a conclu un partenariat avec Microsoft Azure pour fournir une interconnectivité à faible latence entre les deux Clouds dans de nombreuses régions du monde.
Oracle dispose d'un certain nombre de partenaires spécialisés dans l'automatisation de la migration vers OCI à partir d'un grand nombre de sources, y compris les Clouds publics concurrents et les environnements sur site virtualisés/non virtualisés. La liste complète des fournisseurs de services de migration se trouve dans notre Marketplace. On peut citer notamment Rackware et ZConverter.
Si vous envisagez de migrer Oracle Database à partir d'autres environnements sur site ou Cloud, Oracle fournit une série d'outils pour faciliter la migration hors ligne ou la migration sans temps d'arrêt/en direct. Ces divers outils comprennent Zero Downtime Migration (ZDM), OCI Database Migration (DMS), GoldenGate, DataPump, RMAN, etc. L'outil à choisir dépend des caractéristiques de votre base de données source et cible et de votre environnement d'exploitation. Pour plus de détails, consultez la Page d'accueil d'OCI sur la migration de base de données vers le Cloud.
Déplacement et amélioration
La stratégie de migration vers le Cloud dite de "déplacement et d'amélioration" consiste à enrichir ou à remplacer un service existant par une offre Cloud. Au fur et à mesure que votre équipe avance dans le processus d'identification des candidats appropriés pour la migration vers le Cloud, l'examen des possibilités d'amélioration ou de remplacement des services doit être une priorité. Par exemple, vous pouvez améliorer les applications sur site existantes en migrant la base de données sur site prenant en charge une application critique vers notre service géré Database Cloud Service, notre première base de données autonome Autonomous Database, ou Exadata Cloud Service, qui est la plate-forme la plus rapide pour exécuter Oracle Database dans le Cloud.
En outre, l'adoption d'Oracle Cloud Infrastructure donne accès à un portefeuille complet de services comprenant :
- Data Science Cloud qui inclut des technologies telles que le Machine Learning, l'IA et Big Data Service
- Applied Technologies Software qui inclut des technologies telles que Digital Assistant et Blockchain
- Le développement d'applications avec des technologies telles que Container Engine for Kubernetes, APEX (low-code), Visual Builder Studio (CI/CD) et Mobile Hub
- Les services de sécurité qui incluent des technologies telles que WAF, Identity & Access Management, Cloud Guard et Access Security Broker
- Analytics Cloud
Un modèle de distribution colocatif pour les fournisseurs SaaS utilise des logiciels fonctionnant sur une infrastructure partagée pour prendre en charge les clients finaux individuels ISV (locataires).
Les données client sont généralement stockées dans un ensemble de tables partagées et toutes les couches d'application connaissent l'identifiant unique d'un client. L'application elle-même est conçue pour être multi-client. En règle générale, l'application est également responsable de la gestion des abonnements des utilisateurs. En outre, l'infrastructure doit également être classée en groupes de serveurs en fonction du nombre de clients, de transactions et de réglementations à prendre en charge.
Pourquoi choisir ce modèle ?
Un modèle mutualisé présente des avantages pour l'ISV (éditeur de logiciel). L'utilisation des économies d'échelle offertes par un modèle mutualisé permet de gagner en efficacité. La composition du groupe de serveurs étant bien connue, des gains d'efficacité sont réalisés en matière de gestion et de surveillance de l'infrastructure. Le lancement d'une nouvelle zone de service consiste uniquement à exécuter le code d'automatisation de l'infrastructure, puis à déployer l'application. L'ensemble commun d'infrastructures fournit un affichage unifié pour la surveillance.
Le fait que les clients soient hébergés sur des systèmes de calcul, de stockage et de base de données communs simplifie la stratégie de déploiement d'application. Les ISV qui utilisent ce modèle ont généralement une seule base de code, ce qui facilite le déploiement des mises à jour dans l'ensemble de la base client. De nombreux ISV qui utilisent ce modèle permettent aux clients d'opter pour de nouvelles fonctionnalités en utilisant des drapeaux de fonctionnalités.
Bien entendu, tous ces avantages peuvent également présenter des inconvénients. La prise en charge des clients qui ont des besoins spécifiques en matière de résidence des données nécessite une stratégie de déploiement régionale et il peut y avoir des scénarios dans lesquels les clients ont des besoins d'entreprise consistant à ne pas être hébergés sur les mêmes serveurs qu'un concurrent. En fonction de l'architecture de l'application, les clients peuvent être soumis au scénario du "voisin bruyant". Lorsqu'un groupe de serveurs devient saturé, l'ISV doit décider soit de migrer le client vers un groupe de serveurs plus récent et moins utilisé, soit d'augmenter la capacité du groupe existant.
L'une des conséquences inattendues de la prise en charge adéquate du modèle SaaS colocatif est que l'architecture de votre application doit être bien pensée et planifiée à un niveau plus élevé que dans une architecture à locataire unique. Des contrôles d'accès et des modèles de ségrégation des données appropriés doivent être intégrés dès le départ dans le cadre de l'application, et les ISV doivent s'assurer qu'ils disposent des compétences internes en matière d'ingénierie nécessaires pour réaliser tout cela.
Oracle peut vous aider à combler ces lacunes en faisant appel à nos architectes Cloud pour vous conseiller sur la modernisation de votre application et sur son optimisation en vue d'une migration vers le Cloud réussie. Nos architectes travaillent avec d'autres ISV dans tous les domaines et peuvent vous faire profiter de leur expérience des problèmes similaires et des meilleures pratiques pour votre transformation Cloud.
Isolement du groupe de serveurs
L'une des principales caractéristiques du modèle mutualisé est l'existence d'un environnement partagé pour les locataires hébergés. En tant qu'ISV, vous devez vous assurer que l'application SaaS a été conçue pour séparer et protéger correctement les données client pendant l'exécution. Vous devez également être en mesure de gérer, surveiller et maintenir correctement ce qui se passe dans les différents groupes de serveurs hébergeant votre application.
Vous pouvez avoir des besoins spécifiques pour éloigner les clients de certaines régions des clients d'autres régions (ou sous-régions). Ce type de ségrégation peut être obtenu en déployant vos charges de travail dans la combinaison de régions et de compartiments OCI. C'est le cas, par exemple, d'un fournisseur SaaS aux Etats-Unis qui vend des services à la fois dans le secteur des soins de santé et dans celui de la fabrication générale. Le fournisseur pourrait utiliser des constructions régionales et à compartiments pour séparer ces charges de travail et proposer des fonctionnalités différenciées (c'est-à-dire la conformité HIPPA/HITRUST pour les charges de travail dans le domaine de la santé).
Une évolution naturelle pour les ISV qui ont commencé avec un modèle mutualisé est de faire progresser l'offre pour mieux isoler les données des clients. Généralement, cette évolution se produit d'abord au niveau des données et Oracle Database prend en charge un modèle mutualisé qui permet d'intégrer des bases de données indépendantes et enfichables dans une base de données de conteneur unique.
Un modèle de distribution à locataire unique utilise un logiciel fonctionnant sur une infrastructure dédiée pour prendre en charge les clients finaux individuels ISV. Contrairement à un modèle colocatif dans lequel plusieurs clients partagent les mêmes cycles de traitement et où les données sont mélangées dans des tables de base de données communes, un modèle à locataire unique repose sur des machines virtuelles de traitement, des bases de données et une infrastructure de support distinctes (équilibreurs de charge, files d'attente de messages, etc.) pour chaque client.
Pourquoi choisir ce modèle ?
Un modèle à locataire unique présente de nombreux avantages pour l'ISV (éditeur de Logiciel). Chaque client/locataire hébergé sur un système de calcul, de stockage et de base de données distincts illustre clairement la nécessité de séparer les préoccupations, tant du point de vue de la sécurité que de celui des performances. Le client A ne peut pas affecter le client B, que ce soit par une action malveillante ou en utilisant par inadvertance plus que sa part de ressources. En outre, le rayon d'explosion d'une défaillance catastrophique est plus réduit ; la panne d'un seul composant (comme une base de données ou une file d'attente de messages) n'affecte qu'un seul client plutôt que l'ensemble de l'application SaaS. Chaque locataire dispose d'un environnement distinct, personnalisé avec des fonctionnalités et des correctifs uniques, ce qui permet d'obtenir un modèle de distribution fortement centré sur le client.
Bien entendu, tous ces avantages peuvent également présenter des inconvénients. Tout avantage découlant, par exemple, du déploiement d'environnements centrés sur le client peut être contrebalancé par la charge de travail supplémentaire que représentent la gestion de la configuration et le renforcement de la surveillance et de la maintenance. De nombreux autres avantages de cette approche sont obtenus dans le cadre d'un modèle colocatif, même si la conception et l'implémentation de l'application SaaS du ISV sont plus rigoureuses.
En fin de compte, la question est de savoir si un ISV souhaite investir dans la colocation de son application SaaS, ce qui dépend en grande partie de ses compétences internes en matière d'ingénierie logicielle. Si ce n'est pas le cas, ils peuvent choisir de s'appuyer sur les capacités de compartimentation inhérentes à leur plate-forme logicielle et/ou leur fournisseur Cloud à très grande échelle. Chaque ISV doit faire ce choix en fonction de sa situation particulière.
Oracle peut vous aider à faire ce choix en faisant appel nos architectes Cloud pour vous conseiller sur la modernisation de votre application et sur son optimisation en vue d'une migration vers le Cloud. Nos architectes travaillent avec d'autres ISV dans tous les domaines et peuvent vous faire profiter de leur expérience des problèmes similaires et des meilleures pratiques pour votre transformation Cloud.
Isolement des locataires
L'une des principales caractéristiques du modèle à locataire unique est l'existence d'un environnement isolé pour chaque locataire. En tant qu'ISV, vous souhaitez fournir des ressources dédiées en matière de traitement, de réseau, de stockage, de messagerie et de base de données pour chacun de vos clients. Les ressources doivent être séparées les unes des autres, tant du point de vue de l'exécution que de celui de la gestion.
OCI fournit une fonctionnalité unique, les compartiments. Ceux-ci assurent une forte séparation logique entre toutes les ressources OCI. Vous pouvez placer l'ensemble de l'environnement d'un client (y compris le réseau, le traitement, etc.) dans un compartiment et écrire des politiques OCI qui contrôlent l'accès à ces ressources. Grâce à l'utilisation de ces deux fonctionnalités clés d'OCI, vous êtes en mesure de séparer efficacement le client "A" du client "B" et d'éviter toute contamination croisée des ressources, de la gestion ou des informations. Etant donné que les compartiments sont hiérarchiques, vous avez la possibilité de les imbriquer et de modéliser des configurations client complexes avec cette approche. Imaginez, par exemple, un client réel avec plusieurs divisions qui souhaite une certaine ségrégation entre les unités commerciales tout en maintenant certaines ressources d'entreprise communes.
Bien que le modèle à compartiments offre les meilleures garanties en matière de séparation, il existe quelques approches intermédiaires qui peuvent être utilisées à certains niveaux de l'application pour améliorer l'utilisation des ressources tout en recourant à une méthode non personnalisée de séparation des locataires. Par exemple, au lieu de créer un système de base de données distinct pour chaque locataire, vous pouvez tirer parti des fonctionnalités multi-utilisateurs d'Oracle Database pour implémenter une base de données de conteneur unique avec plusieurs schémas enfichables. Cette approche réduit les coûts liés à la mise en place de plusieurs clusters de bases de données tout en permettant à la base de données d'appliquer la séparation plutôt que de forcer une réécriture du schéma d'application. La machine virtuelle et la base de données en tant que service bare metal d'Oracle prennent en charge l'hébergement partagé dès le départ, tout comme Autonomous Dedicated Database qui peut être utilisé pour vos charges de travail les plus exigeantes.
L'utilisation de cette approche intermédiaire n'est pas seulement possible au niveau des données. Si votre application est conteneurisée, vous pouvez alors utiliser le Container Engine for Kubernetes (OKE) d'Oracle pour déployer plusieurs conteneurs clients dans une seule infrastructure. Vous pouvez ensuite utiliser les primitives natives de Kubernetes telles que les espaces de nommage, le contrôle d'accès basé sur les rôles (RBAC), les secrets et les quotas de ressources pour maintenir la séparation des locataires. Comme pour la base de données, plutôt que de réécrire votre application pour qu'elle soit adaptée aux locataires, vous pouvez simplement tirer parti des fonctionnalités des services Cloud sous-jacents.
Découvrez pourquoi les ISV choisissent Oracle Cloud
Les ISV apportent une meilleure valeur ajoutée à leurs clients grâce à la gamme étendue des services et au support d'OCI.
Questions transversales
Peut-être êtes-vous un ISV "né dans le Cloud" qui crée une infrastructure SaaS à locataire unique en exploitant les capacités innées de votre fournisseur à très grande échelle. Ou peut-être avez-vous commencé sur site et êtes-vous en train de migrer votre application SaaS colocative pour opérer uniquement dans le Cloud. Ou encore, il se peut que votre activité soit une combinaison de ces approches. Quelle que soit la voie empruntée, tout ISV opérant dans le Cloud doit se pencher sur des questions transversales essentielles telles que la sécurité, l'observabilité, la continuité de l'activité et l'automatisation. Dans les sections suivantes, nous examinons comment Oracle est en mesure de relever ces défis fonctionnels et de se démarquer de ses concurrents.
Sécurité, gouvernance et conformité
L'approche d'Oracle est que les fonctions de sécurité doivent toujours être "activées" par défaut et qu'elles doivent être simples et prescriptives. Nous pensons également que les clients ne devraient pas avoir à choisir entre le coût et la sécurité. C'est pourquoi nous nous efforçons de fournir tous les services liés à la sécurité gratuitement ou à faible coût grâce à des partenaires qui proposent des alternatives sur notre marketplace. Nous sommes convaincus que les clients subissent des problèmes de sécurité non pas parce que les outils de prévention des vulnérabilités n'existent pas, mais parce que ces outils sont soit trop chers, soit trop difficiles à utiliser pour la plupart des entreprises.
Oracle estime que la sécurité est une responsabilité partagée entre le fournisseur Cloud et l'ISV. Nous fournissons certaines fonctionnalités de base, telles que la virtualisation de réseaux isolés et la racine de confiance matérielle. Nous les complétons par des outils et des services que l'ISV peut utiliser pour adapter son niveau de sécurité. Les ISV qui souhaitent avoir un aperçu de nos offres de sécurité doivent d'abord consulter notre page d'accueil sur la sécurité et notre architecture de sécurité Cloud.
La sécurité de base commence par l'implémentation robuste de notre Identity & access management (IAM), qui unifie les contrôles d'accès basés sur les rôles avec notre cadre de politiques intuitif. Cette fonctionnalité couvre un large éventail de sujets, notamment les utilisateurs, les groupes, la fédération d'identité et l'autorisation de l'entité instance/ressource. Bien qu'il ne soit pas couvert par l'IAM, un autre concept de sécurité de base concerne la mise en réseau définie par l'utilisateur grâce à l'utilisation de règles, de groupes et de listes de sécurité réseau.
Lorsque vous commencez à développer une architecture technique sécurisée sur Oracle Cloud Infrastructure (OCI), un bon point de départ est le Center for Internet Security (CIS), une organisation indépendante des fournisseurs qui répertorie les meilleures pratiques de sécurité. CIS a fourni un référentiel de sécurité pour les applications OCI et Oracle a développé une automatisation qui aide les ISV à mettre en oeuvre les recommandations du CIS via Terraform.
OCI fournit un certain nombre d'autres services de sécurité fondamentaux :
- La gestion des clés de chiffrement et des secrets
- L'analyse des vulnérabilités des hôtes, des conteneurs et des réseaux
- Les fonctionnalités de la gestion des API et de sécurité comme la protection contre les attaques DDoS, le contrôle d'accès aux API et l'intégration des identités
- Les fonctionnalités de Web Application Firewall (WAF) prenant en charge les informations sur les menaces, les politiques de conformité en matière de sécurité et la gestion adaptative des bots
- Un service Bastion permettant aux clients de fournir un accès restreint et limité dans le temps à des ressources privées
- Un service de certificats permettant le stockage et la gestion de certificats de cryptographie à clé publique (PKCS).
A un niveau supérieur, une fonctionnalité unique d'OCI est la solution Maximum Security Zones qui définit et applique automatiquement les politiques de sécurité dans OCI. Cela permet de mettre en oeuvre une sécurité déclarative en utilisant les meilleures pratiques de sécurité et d'adopter une approche proactive plutôt que réactive de la sécurité des ressources les plus critiques.
Enfin, aucune stratégie de sécurité n'est complète sans la gestion du niveau de sécurité. Cette fonctionnalité est assurée par Cloud Guard pour l'ensemble de votre environnement OCI et par Data Safe pour vos charges de travail de base de données. Ces deux services sont fournis gratuitement aux clients OCI et garantissent que les ressources mal configurées et les activités non sécurisées sont rapidement détectées et corrigées de manière automatisée grâce à des solutions de sécurité prêtes à l'emploi ou par l'envoi de données aux systèmes SIEM/SOC.
Observabilité
Toutes les organisations doivent être en mesure de recueillir des informations sur les performances de leur parc Cloud pour faciliter les opérations et la planification informatique future. Les ISV, en particulier, ont besoin de fonctionnalités plus avancées, car ils utilisent généralement des applications personnalisées qui nécessitent souvent une instrumentation plus approfondie des performances des applications. En outre, les ISV peuvent exécuter leurs charges de travail à l'échelle du Cloud avec une base de consommateurs externes 24h/24 et 7j/7, ce qui nécessite des niveaux de disponibilité plus élevés qu'un système de back-office classique.
A un niveau de base, OCI fournit notre service Monitoring qui permet d'obtenir des informations en temps réel sur les performances de vos charges de travail sur OCI et qui offre des indicateurs clés prêts à l'emploi d'intégrité et de performance. Les utilisateurs peuvent configurer des alarmes pour détecter les anomalies et réagir en conséquence. Ce service est associé à notre service de base Logging qui affiche les logs d'OCI en plus de ceux générés par vos charges de travail. Tout incident ou problème identifié par l'un des services susmentionnés peut être traité par notre service Notifications. Il fournit un système de publication-abonnement à réelle disponibilité et à faible latence, qui envoie des alertes aux fonctions sans serveur (pour la résolution automatique des problèmes), aux messageries ou aux partenaires de distribution des messages comme SMS, Slack et PagerDuty.
A un niveau supérieur, Oracle propose un certain nombre de services axés sur le Machine Learning (ML) qui permettent des analyses plus approfondies dans les domaines de la journalisation, des performances des applications, des performances des bases de données et des opérations. Logging Analytics vous permet de surveiller, de regrouper, d'indexer et d'analyser toutes les données du log et d'utiliser le Machine Learning pour détecter les clusters de problèmes et les anomalies de manière visuelle. Application Performance Monitoring est un service conforme aux normes (OpenTracing & OpenMetrics) qui permet la surveillance synthétique, le traçage distribué et l'analyse de l'exécution des transactions d'applications personnalisées, y compris la prise en charge native de la télémétrie des microservices, dérivée des environnements Kubernetes/Docker que de nombreux ISV proposent. Database Management offre des fonctionnalités de surveillance pour les parcs d'Oracle Database et Operations Insights qui permet aux administrateurs de détecter les problèmes de performances, de prévoir la consommation et de planifier la capacité à l'aide des analytiques ML. Les entreprises peuvent utiliser ces fonctionnalités pour prendre des décisions basées sur les données afin d'optimiser l'utilisation des ressources, d'éviter les pannes de manière proactive et d'améliorer les performances.
Toutes ces fonctionnalités d'observabilité sont fournies sous forme de services intégrés sur OCI et il existe de généreuses offres de "niveaux gratuits" qui permettent aux ISV d'utiliser les services dans des scénarios limités, puis d'étendre leur utilisation en fonction des succès initiaux.
Continuité de l'activité
Les exigences en matière de continuité d'activité d'un ISV peuvent souvent être plus strictes que celles d'une organisation ISV traditionnelle. Si pour un système de back-office traditionnel, comme un système de gestion du capital humain (HCM) ou un système de planification des ressources d'entreprise (ERP), les temps d'arrêt peuvent s'avérer problématiques, la plupart des ISV ne pouvant même pas tolérer d'interruptions temporaires de leurs systèmes orientés vers le client, car ils sont la pierre angulaire de leur activité. C'est pourquoi des concepts tels que la réelle disponibilité (HA) et la récupération après sinistre (DR) sont extrêmement importants. Les ISV doivent exploiter au maximum les fonctionnalités que l'OCI offre dans ces domaines.
Réelle disponibilité
Une région OCI est une zone géographique localisée composée d'un ou plusieurs domaines de disponibilité, chacun d'entre eux étant composé de trois domaines de pannes. La réelle disponibilité est assurée par une redondance des domaines de pannes au sein des domaines de disponibilité.
Un domaine de disponibilité désigne un ou plusieurs datacenters situés dans une région. Les domaines de disponibilité sont isolés les uns des autres, tolérants aux pannes et peu susceptibles de tomber en panne simultanément. Etant donné que les domaines de disponibilité ne partagent pas d'infrastructure physique, telle que l'alimentation ou le refroidissement, ou le réseau de domaine de disponibilité interne, il est peu probable qu'une panne affectant un domaine de disponibilité ait un impact sur la disponibilité des autres.
Un domaine de pannes est un regroupement de matériel et d'infrastructure au sein d'un domaine de disponibilité. Chaque domaine de disponibilité contient trois domaines de pannes. Les domaines de pannes vous permettent de distribuer vos instances afin qu'elles ne soient pas sur le même matériel physique au sein d'un seul domaine de disponibilité. Par conséquent, une panne matérielle inattendue ou une maintenance du matériel de traitement qui affecte un domaine de pannes n'a pas d'impact sur les instances dans d'autres domaines de pannes.
Tous les domaines de disponibilité d'une région sont reliés entre eux par un réseau à faible latence et à large bande passante. Cette interconnexion cryptée et prévisible entre les domaines de disponibilité fournit les éléments constitutifs de la réelle disponibilité et de la récupération après sinistre.
Vous pouvez concevoir des solutions pour plusieurs régions, plusieurs domaines de disponibilité ou plusieurs domaines de pannes, en fonction de la catégorie de pannes contre laquelle vous souhaitez vous protéger.
OCI offre également un grand nombre de fonctionnalités et d'options que vous pouvez adopter pour protéger vos ressources réseau, vos systèmes de stockage et vos ressources de base de données contre les pannes localisées. Un bon point de départ consiste à lire intégralement le Guide sur les solutions de réelle disponibilité de l'OCI Architecture Center afin de faire les choix les plus adaptés à votre modèle d'exploitation.
Récupération après un sinistre
Un sinistre correspond à tout événement qui met vos applications en danger, qu'il s'agisse de pannes de réseau, de pannes d'équipement ou de catastrophes naturelles. Un plan de récupération après sinistre (DR) bien conçu vous permet de vous remettre rapidement d'un sinistre et de continuer à fournir des services à vos utilisateurs. Les fonctionnalités de récupération après un sinistre d'OCI s'appuient sur les fonctionnalités étendues de réelle disponibilité dont il a été question dans la section précédente.
Lorsque vous étudiez votre stratégie de récupération après sinistre, vous devez d'abord tenir compte de votre objectif de temps de récupération (RTO) et de votre objectif de point de récupération (RPO). Le RTO désigne le délai cible dans lequel une application donnée doit être restaurée après un sinistre. En règle générale, plus les applications sont critiques, plus le RTO est faible. Le RPO est la période après un sinistre pendant laquelle l'application peut tolérer la perte de données avant que le sinistre ne commence à affecter l'entreprise.
Ensuite, vous devez déterminer le type de scénario de sinistre contre lequel vous voulez vous protéger. Essayez-vous de vous protéger contre les pannes d'applications, les pannes de réseau, les pannes de centre de données, les incidents régionaux ou tout ce qui précède ? La réponse à cette question, combinée à la détermination de vos RTO/RPO, orientera votre stratégie de récupération après sinistre.
OCI fournit des conseils pour la création d'architectures tolérantes aux sinistres au niveau du traitement, du réseau, du stockage, des applications et des bases de données. Vous pouvez utiliser ces outils pour créer une architecture active-active dans laquelle vos applications fonctionnent simultanément dans deux régions et où une panne dans la région "a" peut être traitée par la région "b". Vous pouvez également créer soit un scénario de sauvegarde à chaud dans lequel une région secondaire est préparée et prête à prendre en charge le trafic en cas de panne de la région primaire, soit un scénario de sauvegarde à froid dans lequel un mélange d'étapes manuelles et/ou automatisées peut être nécessaire pour restaurer les opérations commerciales, soit une mise en oeuvre hybride de ces scénarios.
Un bon point de départ consiste à lire intégralement le Guide sur les solutions de récupération après un sinistre de l'OCI Architecture Center afin de faire les choix les plus adaptés à votre modèle d'exploitation.
Budgets et quotas
En tant qu'ISV exécutant une application SaaS qui utilise les compartiments OCI pour l'isolement, vous pourriez envisager certaines primitives connexes pour vous aider, vous et vos clients, à mieux gérer les ressources. Chaque environnement OCI est généralement préconfiguré avec un certain plafond annuel et bien que les dépassements n'entraînent aucune pénalité, la plupart des ISV aiment contrôler strictement l'utilisation des ressources.
Les ISV devraient commencer par considérer les quotas de compartiments comme un outil permettant de répartir les ressources à l'échelle de l'environnement entre les différents compartiments qui le composent. Grâce à cette primitive, les ressources communes, telles que les UC et les blocs de mémoire, ou les ressources plus spécialisées, telles que les GPU et Exadata, peuvent être réparties entre les compartiments afin de garantir qu'aucun locataire ne bénéficie d'une allocation de ressources trop importante et que certaines ressources spécialisées sont allouées aux bons endroits.
Les quotas fonctionnent sur les ressources Cloud. Lors du contrôle de l'allocation des budgets, les ISV devraient examiner les budgets OCI. Cette fonctionnalité vous permet de définir des budgets d'utilisation pour chaque compartiment et de recevoir des alertes lorsqu'un budget s'approche d'une limite souple ou a dépassé une limite stricte. L'utilisation de cette fonctionnalité peut aider les ISV à gérer leurs dépenses auprès de plusieurs clients et à prévoir la nécessité d'une croissance future des ressources.
Rétrofacturation
Si chaque ISV établit le tarif de son service SaaS de manière différente, un élément commun à de nombreux modèles de tarification est le concept de coût des marchandises vendues (COGS). Si vous ne savez pas combien vous dépensez pour créer et fournir un produit, il est difficile de savoir comment calculer le prix de manière appropriée et comment faire varier ce prix entre les différents consommateurs.
La tarification d'un service SaaS comprend de nombreux éléments, dont les coûts d'ingénierie et de marketing, mais l'un des composants clés est le coût de l'hébergement dans le Cloud. C'est un domaine dans lequel Cost Analysis d'OCI peut vous aider en fournissant des visualisations dynamiques de l'utilisation de vos locataires clients par compartiments et/ou par balises de suivi des coûts. L'utilisation de ces outils peut vous aider à déterminer combien vous dépensez pour l'hébergement de chacun de vos clients et peuvent vous guider quant à la nécessité ou non d'ajuster les prix que vous leur proposez.
Si vous avez besoin de données plus détaillées que celles fournies par nos visualisations, vous pouvez exporter des données d'utilisation entièrement granulaires dans un format lisible par machine pour une analyse plus approfondie avec l'outil de votre choix. De plus, s'il vous arrive d'opérer dans un environnement de Cloud hybride, vous avez la possibilité d'utiliser un outil tiers multicloud comme CloudHealth pour effectuer une analyse unifiée.
Automatisation de l'infrastructure
Très peu d'entreprises construisent leurs environnements manuellement. Les ISV en particulier ont reconnu la valeur de l'orchestration de l'infrastructure et de la gestion de la configuration grâce à l'utilisation d'outils d'infrastructure en tant que code (IaC) tels que Terraform, Ansible, Puppet, etc. L'IaC est parfaitement adaptée, quelle que soit la taille, l'empreinte technique ou l'approche de déploiement de votre entreprise. Elle est particulièrement essentielle pour les ISV en pleine croissance qui étendent constamment leur présence régionale et leur base installée. Sans automatisation, vos frais de maintenance vont augmenter de façon exponentielle et seront difficiles à gérer.
OCI prend en charge un certain nombre d'outils d'automatisation standard qui vous permettront d'implémenter une stratégie d'automatisation neutre par rapport au Cloud. Cela comprend notamment le support produit pour HashiCorp Terraform, Ansible, et Chef. Comme OCI expose toutes ses fonctionnalités via SDK et via une CLI, il est facile de l'intégrer à un certain nombre d'autres outils, comme Puppet.
En outre, OCI s'appuie sur les fonctionnalités de Terraform en offrant un service géré appelé Resource Manager. Ce service, qui est mis gratuitement à la disposition des clients d'OCI, permet d'exécuter Terraform dans les limites du modèle de sécurité basé sur des politiques d'OCI et offre une gestion d'état, une création de modèles, une découverte de ressources et une intégration GitHub/GitLab prêtes à l'emploi.
Automatisation du cycle de vie des logiciels
Les ISV utilisent des outils de construction et de déploiement automatisés pour faire passer leur code à travers le cycle de vie du développement de logiciel. Lorsque l'on envisage un modèle de distribution à locataire unique, une automatisation forte devient encore plus importante, car un seul déploiement peut être fourni à des centaines d'instances de locataires. En outre, ces déploiements doivent souvent être effectués de manière continue pour éliminer les temps d'arrêt. Ils doivent être suffisamment flexibles pour permettre les personnalisations spécifiques dans les succursales des clients individuels.
OCI prend en charge la grande majorité des outils CI/CD leaders sur le marché. Que vous utilisiez Jenkins, Jenkins-X, Spinnaker, TravisCI, GitHub Actions, CircleCI, ou d'autres solutions, il y a probablement des utilisateurs dans l'écosystème logiciel qui utilisent votre outil favori avec OCI.
En outre, OCI propose un Service DevOps facile à utiliser, qui est une plate-forme d'intégration continue et de livraison continue (CI/CD) de bout en bout pour les développeurs. Les ISV peuvent utiliser ce service pour créer, tester et déployer facilement des logiciels sur OCI, ainsi que pour gérer le code source avec des référentiels Git privés hébergés.
Récapitulatif
Oracle reconnaît que chaque ISV apporte avec lui une histoire d'origine, un environnement d'origine, une architecture technique, un modèle de déploiement et des exigences techniques et commerciales spécifiques. Il n'existe pas d'approche "universelle" pour passer à Oracle Cloud Infrastructure (OCI) qui puisse ignorer tous ces facteurs uniques et ne pas en tenir compte pour exploiter les capacités d'OCI.
Un élément clé de notre approche de haute qualité de la migration des ISV est la combinaison de notre processus d'engagement qui réunit des architectes, des consultants commerciaux et des ingénieurs spécialistes pour vous aider à concevoir votre solution Cloud, et de notre utilisation des services Cloud Lift pour travailler main dans la main avec vous afin de déplacer votre charge de travail vers OCI.
Ce qui rend Oracle unique dans le domaine des ISV, c'est notre volonté et notre désir de nous engager individuellement avec les clients au niveau de la stratégie, de la commercialisation, de l'architecture et de la mise en oeuvre, et de faire en sorte que nos experts travaillent avec les vôtres pour définir ensemble vos besoins dans le Cloud.