continON se déploie d’un seul tenant. Ce qui change, c’est à qui appartient le terrain sur lequel la plateforme repose.
La plateforme fonctionne comme un ensemble de services conteneurisés sur un cluster Kubernetes, mis à disposition par un pipeline de livraison contrôlé. Cela ne change pas d’un déploiement à l’autre. Ce qui change, c’est à qui appartient le cluster, qui détient le nom d’hôte public et son certificat, et qui répond lorsqu’une machine demande une intervention. Cette page porte sur cette ligne de partage.
- Exploité pour vous
- L’environnement fonctionne sur une infrastructure que nous exploitons. Le cluster, le nom d’hôte public et son certificat, ainsi que la mise en production de chaque version, sont de notre ressort.
- Sur une infrastructure que vous contrôlez
- La même charge de travail est déployée sur un cluster que votre organisation possède ou loue. La licence active le produit là où vous le placez ; les machines, le nom d’hôte et leur exploitation vous reviennent.
Quatre frontières, de l’extérieur vers l’intérieur.
La périphérie publique
Exploité pour vous Nous détenons le nom d’hôte et son certificat.
Sur une infrastructure que vous contrôlez Votre organisation détient le nom d’hôte et son certificat.
Un service n’est joignable de l’extérieur que s’il a reçu explicitement un nom d’hôte public avec un certificat. Tout ce qui n’en a pas reçu est joignable à l’intérieur de l’environnement et nulle part ailleurs – c’est le comportement par défaut, pas un réglage que quelqu’un a pensé à activer.
Ce qui la franchitLe trafic des navigateurs vers les applications dotées d’un nom d’hôte. Rien d’autre.
L’environnement
Exploité pour vous Nous exploitons le cluster et appliquons les versions.
Sur une infrastructure que vous contrôlez Votre équipe exploite le cluster ; les versions restent livrées comme une unité contrôlée et versionnée.
Un cluster qui exécute les services du produit. Les versions y sont appliquées par le pipeline de livraison plutôt qu’à la main : les dépôts des applications détiennent leur code source et rien d’autre, et ne peuvent pas modifier l’endroit ni la manière dont le produit est déployé. Cette séparation constitue le dispositif de maîtrise des changements, et elle vaut dans les deux implantations.
Ce qui la franchitLes images publiées, appliquées par le pipeline. Les appels sortants que le produit adresse aux systèmes que vous avez connectés.
Le produit
Détenu parIdentique dans les deux cas.
Les applications, l’unique serveur d’autorisation auprès duquel chaque application s’authentifie, le modèle d’organisation et de fonctions, les définitions des Builders et la couche de données commune. C’est le même logiciel dans les deux implantations – il n’y a ni édition cloud, ni édition sur site allégée.
Ce qui la franchitRien de nouveau. Un enregistrement qui passe d’une application à une autre reste à l’intérieur de cette frontière.
Les enregistrements de votre organisation
Détenu parÀ vous dans les deux cas.
Chaque enregistrement est rattaché à l’organisation à laquelle il appartient, et un fichier de licence chiffré – validé au chargement, portant le nom de l’organisation, le type de déploiement et une date d’expiration – détermine quelles applications existent, ou non, pour cette organisation.
Ce qui la franchitUniquement ce qu’une identité connectée est autorisée à lire ou à écrire, selon le poste que cette identité occupe.
Déplacer l’enveloppe ne déplace rien de tout ceci.
- Le modèle d’accès
- Des groupes d’autorisations liés aux fonctions de l’organigramme, pas à des comptes. Voir
- La licence
- Le même fichier chiffré, validé au chargement, qui conditionne l’accès aux mêmes modules. Voir
- Les mécanismes d’intégration
- Les mêmes requêtes enregistrées sur vos propres sources et le même coffre d’identifiants par organisation. Voir
- Le modèle d’organisation
- Les mêmes unités, fonctions et postes auxquels se réfère chaque autre partie du produit. Voir
Ce que cette page n’affirme pas.
- Les objectifs de disponibilité, la sauvegarde et la restauration sont convenus pour chaque mandat. Cette page n’affirme aucun taux de disponibilité, et le modèle de déploiement lui-même n’implique aucun niveau de service.
- Lorsque le cluster vous appartient, son exploitation – capacité, correctifs de l’hôte, surveillance et sauvegardes de votre propre base de données – reste de la responsabilité de votre organisation.
- continON est livré comme une seule charge de travail conteneurisée. Il n’est pas proposé comme service géré sur la plateforme propre d’un fournisseur cloud tiers, et cette page n’en présente pas.
Comment la plateforme s’articule
Apportez vos contraintes d’infrastructure.
Une séance de travail pour déterminer où se situerait l’environnement, qui détiendrait le nom d’hôte, ce que votre équipe exploiterait et ce que nous exploiterions – avant toute signature.