Un broker MQTT BYOC tourne dans votre propre compte cloud tandis qu'un fournisseur spécialisé se charge du travail d'exploitation, comme pour un broker MQTT managé. Cet article explique le fonctionnement du modèle bring your own cloud, la répartition des responsabilités, les cas où il est préférable à un hébergement mutualisé ou dédié, et comment préparer votre compte avant le déploiement.
Qu'est-ce qu'un broker MQTT BYOC ?
« Bring your own cloud » désigne un modèle de déploiement dans lequel le logiciel tourne sur une infrastructure que vous possédez et payez, généralement dans un compte ou un abonnement cloud sous le contrôle de votre organisation, tandis que l'éditeur l'exploite. Les machines virtuelles ou conteneurs du broker, le réseau, les disques et les load balancers se trouvent dans votre compte. Les ingénieurs ou l'automatisation du fournisseur déploient, configurent, mettent à jour et supervisent le broker grâce aux accès que vous leur accordez.
Comparez cela aux deux options d'hébergement plus courantes :
- Hébergement mutualisé (serverless). De nombreux clients partagent un cluster exploité dans le compte du fournisseur. Vous obtenez des endpoints et des identifiants en quelques minutes et ne payez rien pour la capacité inutilisée, mais vous ne choisissez pas l'infrastructure sous-jacente.
- Hébergement dédié. Vous disposez de votre propre cluster isolé, toujours dans le compte du fournisseur. Les performances ne sont partagées avec personne, mais l'infrastructure reste la propriété de l'éditeur.
- BYOC. Votre propre broker isolé, dans votre propre compte. Le trafic des messages transite par une infrastructure que vous contrôlez, sous vos politiques de sécurité cloud et votre facturation.
Si vous découvrez la place des brokers dans un système IoT, le rôle d'un broker MQTT couvre les bases.
Pourquoi les équipes choisissent le bring your own cloud
Contrôle des données et conformité
La raison la plus courante est le contrôle des données. Certaines organisations imposent que les données de production, y compris la télémétrie des appareils, restent dans des comptes qu'elles possèdent, là où s'appliquent leurs propres journaux, clés de chiffrement, contrôles réseau et audits. Un déploiement BYOC permet à la couche MQTT de respecter cette politique sans que l'équipe ait à devenir exploitante de broker. Notre guide sur la résidence des données MQTT approfondit les questions de localisation et de réglementation.
Proximité réseau
Lorsque vos consommateurs, comme les moteurs de traitement de flux, les bases de données et les services d'analytique, tournent déjà dans un compte et une région cloud donnés, placer le broker à côté d'eux garde le trafic sur le réseau privé. Les abonnés de votre réseau virtuel peuvent se connecter sans traverser l'Internet public, tandis que les appareils continuent de joindre un endpoint public.
Tirer parti des engagements cloud existants
De nombreuses entreprises ont négocié des engagements avec un fournisseur cloud. Faire tourner l'infrastructure du broker dans votre compte signifie que les dépenses de calcul et de réseau comptent dans ces engagements et apparaissent dans vos rapports de coûts existants.
Une revue de sécurité plus simple
Les équipes de sécurité trouvent souvent plus facile d'approuver une infrastructure située dans un compte qu'elles surveillent déjà, sous des politiques qu'elles appliquent déjà, que d'évaluer de zéro un nouvel environnement tiers.
Qui gère quoi dans un déploiement BYOC
La répartition exacte est fixée par votre accord avec le fournisseur, mais le schéma typique est le suivant :
| Domaine | Vous (propriétaire du compte) | Fournisseur (exploitant) |
|---|---|---|
| Compte cloud, facturation, politiques de l'organisation | Oui | Non |
| Conception réseau, plages d'IP, peering, politique de pare-feu | Approuve et possède | Propose et met en œuvre les parties propres au broker |
| Installation et configuration du broker | Relit | Oui |
| Mises à jour et correctifs de sécurité du broker | Approuve les fenêtres de maintenance | Oui |
| Certificats TLS des endpoints du broker | Décisions sur les domaines | Émission et renouvellement |
| Supervision de la santé du broker et réponse aux incidents | Contact d'escalade | Oui |
| Firmware des appareils et applications clientes | Oui | Non |
| Consommateurs de données et intégrations en aval | Oui | Non |
L'idée clé : vous conservez la propriété et la visibilité de l'infrastructure, et le fournisseur en porte la charge d'exploitation. Mettez-vous d'accord par écrit sur le périmètre des accès, les fenêtres de maintenance, les chemins d'escalade et la façon dont les accès sont révoqués.
BYOC face au mutualisé, au dédié et à l'auto-hébergé
| Critère | Serverless mutualisé | Dédié | BYOC | Auto-hébergé |
|---|---|---|---|---|
| Où tourne l'infrastructure | Compte du fournisseur | Compte du fournisseur | Votre compte | Votre compte ou votre datacenter |
| Qui exploite le broker | Fournisseur | Fournisseur | Fournisseur | Votre équipe |
| Isolation vis-à-vis des autres clients | Logique | Cluster physique | Physique, dans votre compte | Totale |
| Délai avant la première connexion | Quelques minutes | Court | Plus long (préparation du compte) | Dépend de votre équipe |
| Facture d'infrastructure | Incluse dans le plan | Incluse dans le plan | Votre facture cloud plus le service | Votre facture cloud ou matériel |
| Votre effort d'exploitation | Très faible | Très faible | Faible | Élevé |
BYOC se situe entre l'hébergement dédié et l'auto-hébergement. Si vous n'êtes pas sûr d'en avoir besoin, un broker MQTT dédié offre souvent une isolation suffisante avec moins de mise en place. Si vous voulez un contrôle total et avez les personnes pour l'exploiter, comparez l'effort dans broker MQTT auto-hébergé ou managé.
Le fonctionnement de ConnectMQ BYOC
ConnectMQ propose BYOC parmi ses plans : le broker tourne dans votre compte cloud et est géré pour vous. Il se comporte de la même façon que sur les autres plans. Les clients se connectent en MQTT 3.1.1 ou MQTT 5.0 sur les ports standard, TCP 1883, TLS 8883, WebSocket 8083 et Secure WebSocket 8084 avec le chemin /mqtt : le firmware des appareils et les applications écrits pour un broker Serverless ou Dedicated ne nécessitent aucune modification de code, seulement de nouveaux paramètres de connexion.
Les fonctionnalités de la plateforme restent disponibles : identifiants générés avec des client ID qui leur sont liés, isolation multi-tenant et quotas par plan, protection contre l'inondation de messages, blocage d'IP après des échecs de connexion répétés, fonctionnalités MQTT 5 comme les abonnements partagés, l'expiration de session et l'expiration des messages, ainsi que le décodage Sparkplug B avec republication dans des topics ISA-95 pour les projets industriels.
Comme BYOC dépend de votre environnement cloud, confirmez directement avec l'équipe les fournisseurs cloud, les régions et le modèle d'accès pris en charge avant de planifier le déploiement.
Préparer votre compte cloud
Quel que soit votre fournisseur, la même préparation raccourcit l'intégration BYOC :
- Créez un compte ou un abonnement dédié au broker, afin que ses autorisations, sa facturation et ses journaux d'audit soient séparés des autres charges de travail.
- Choisissez la région en fonction de l'endroit d'où se connectent les appareils, de l'endroit où tournent les consommateurs et d'éventuelles exigences de résidence.
- Réservez des plages réseau qui n'entreront pas en conflit avec vos VPC existants ou vos réseaux sur site si vous prévoyez un peering ou une connexion VPN.
- Vérifiez les quotas de service pour les instances de calcul, les load balancers et les adresses IP publiques dans cette région.
- Définissez le modèle d'accès : un rôle restreint que le fournisseur peut assumer, avec journalisation activée, et une procédure documentée pour le révoquer.
- Décidez du DNS des endpoints du broker et de qui gère les enregistrements.
- Convenez des fenêtres de maintenance et de la façon dont vous êtes prévenu avant les mises à jour.
- Mettez en place des tags de coût pour que l'infrastructure du broker soit visible dans vos rapports.
Validez vos clients avant la migration
Pendant la préparation de l'environnement BYOC, vous pouvez tester le comportement de vos clients sur le serveur MQTT public gratuit, réservé aux tests et aux prototypes, puis sur un broker privé gratuit. Cet exemple Python utilise paho-mqtt 2.x et se connecte en TLS. Remplacez plus tard l'hôte et les identifiants par votre endpoint BYOC ; rien d'autre ne change.
import ssl
import paho.mqtt.client as mqtt
HOST = "broker.connectmq.com" # à remplacer par votre endpoint BYOC
PORT = 8883
CLIENT_ID = "YOUR_CLIENT_ID"
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.subscribe("connectmq/demo/byoc-7c21/#", qos=1)
client.publish("connectmq/demo/byoc-7c21/status", "online", qos=1, retain=True)
def on_message(client, userdata, msg):
print(msg.topic, msg.payload.decode())
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID,
protocol=mqtt.MQTTv5)
# Pour un broker privé, décommentez :
# client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.connect(HOST, PORT, keepalive=60)
client.loop_forever()
Exécutez le même script sur chaque environnement en gardant une structure de topics identique. Quand le broker BYOC est en service, la bascule se résume à une modification de configuration.
Pièges courants
- Des accès trop larges pour l'exploitant. N'accordez que ce dont le broker a besoin et journalisez chaque action.
- Oublier les coûts de sortie de données. Si des appareils ou des consommateurs se trouvent dans d'autres régions ou d'autres clouds, des frais de transfert apparaissent sur votre facture.
- Bloquer les mises à jour. Des politiques qui empêchent l'exploitant d'appliquer les correctifs créent le même risque qu'un broker auto-hébergé non maintenu.
- Pas d'environnement de préproduction. Gardez un petit broker hors production, par exemple sur le plan Serverless gratuit, pour tester le firmware et les intégrations.
Démarrez avec ConnectMQ
Vous pouvez découvrir la plateforme dès aujourd'hui sur le plan Serverless gratuit, sans carte bancaire, sur app.connectmq.com. Développez et testez-y vos appareils, puis échangez avec l'équipe sur le passage à BYOC lorsque vos exigences de contrôle des données l'imposent. Pour une vue plus large des options d'hébergement, lisez le guide du broker MQTT cloud ou comparez les plans dans la présentation du broker MQTT managé ConnectMQ.
Questions fréquentes
Un broker MQTT BYOC, est-ce la même chose que l'auto-hébergement ?
Non. L'infrastructure se trouve dans votre compte, mais c'est le fournisseur qui installe, met à jour et supervise le broker. En auto-hébergement, votre propre équipe fait tout cela.
Mes appareils ont-ils besoin d'un firmware différent pour BYOC ?
Pas si le broker parle MQTT standard. Sur ConnectMQ, BYOC utilise les mêmes protocoles et les mêmes ports que les autres plans : vous ne changez que le nom d'hôte et les identifiants.
Qui paie l'infrastructure cloud en BYOC ?
L'infrastructure apparaît sur votre propre facture cloud, et le service de gestion est facturé séparément par le fournisseur. Confirmez les modalités exactes avec votre fournisseur.
Quand BYOC est-il disproportionné ?
Si aucune politique ne vous impose de garder les données dans votre propre compte, un broker MQTT managé mutualisé ou dédié est plus rapide à démarrer et plus simple à exploiter.
