Une petite ou moyenne entreprise (PME) qui veut quitter Amazon Web Services (AWS) a quatre solutions de rechange réalistes. Ce sont un autre hyperscaler, un cloud pour développeurs ou un hébergeur de serveurs dédiés, une plateforme applicative en libre-service, et un cloud régional infogéré accompagné d’une équipe d’exploitation. Une cinquième option consiste à rester sur AWS en y ajoutant une gouvernance et un opérateur. Le bon choix dépend des services AWS que l’application appelle, de qui opère l’environnement aujourd’hui et de l’endroit où les données doivent résider.
Qu’est-ce qui compte comme une solution de rechange à AWS pour une PME ?
Une solution de rechange à AWS est tout arrangement qui remplace la plateforme, le modèle d’exploitation, ou les deux. Cinq termes suffisent à décrire les choix d’une PME.
Un hyperscaler est un cloud public doté d’un très vaste catalogue de services et de nombreuses régions dans le monde. AWS, Microsoft Azure et Google Cloud sont les principaux.
Un cloud pour développeurs vend des machines virtuelles, du stockage et une courte liste de services infogérés, au moyen d’une console simple et d’une grille de prix publique. DigitalOcean en est un exemple courant. Un hébergeur de serveurs dédiés loue des machines physiques entières au mois. OVH en est un exemple courant. Les deux relèvent de l’infrastructure en tant que service (IaaS) : le client loue de la capacité et opère tout ce qui tourne par-dessus.
Une plateforme en tant que service (PaaS) en libre-service exécute le code d’une application sans exposer de serveurs. Le client y relie un dépôt de code, et la plateforme construit, déploie et met à l’échelle l’application. Heroku et Render en sont des exemples.
Un cloud régional infogéré est un fournisseur qui apporte une infrastructure dans un seul pays ou sur quelques sites, ainsi que les ingénieurs qui l’opèrent selon un périmètre écrit.
Rester sur AWS avec un opérateur conserve la plateforme et change la partie qui en répond.
Comment les solutions de rechange réalistes à AWS se comparent-elles ?
Le tableau compare les cinq options selon les critères qui tranchent habituellement le choix pour une PME.
| Option | Qui l’opère | Convient à | Ce que vous sacrifiez |
|---|---|---|---|
| Un autre hyperscaler | Vos ingénieurs | Une équipe qui a une raison commerciale ou technique de préférer ce fournisseur | Peu de chose sur le plan des capacités. La complexité et la facturation à l’usage vous suivent |
| Cloud pour développeurs ou hébergeur de serveurs dédiés | Vos ingénieurs | Une pile classique opérée par des gens à l’aise avec les serveurs | La plupart des services infogérés exclusifs, certaines régions, et la présence de quelqu’un d’autre pour opérer les serveurs la nuit |
| PaaS en libre-service | Le fournisseur opère la plateforme. Votre équipe est responsable de l’application | Une petite équipe produit qui veut livrer du code et éviter les serveurs | La maîtrise du système d’exploitation et du réseau, et souvent un prix unitaire plus bas à grande échelle |
| Cloud régional infogéré | Le fournisseur, selon un périmètre écrit | Une pile classique dans une entreprise sans personnel d’exploitation | Le nombre de régions, l’étendue du catalogue, et souvent une grille de prix publique |
| Rester sur AWS avec une gouvernance et un opérateur | Le fournisseur, selon un périmètre écrit | Une architecture AWS saine dont personne n’est responsable | Rien du côté de la plateforme. La facturation à l’usage demeure |
Les trois premières options changent la plateforme et laissent l’exploitation à l’entreprise. La quatrième change à la fois la plateforme et l’opérateur. La cinquième change seulement l’opérateur.
Un autre hyperscaler est-il une vraie solution de rechange à AWS ?
Un autre hyperscaler est une vraie solution de rechange à AWS quand il existe une raison précise de le préférer. Les raisons courantes sont une entente de licences Microsoft déjà en place, un produit de données ou d’analytique que l’équipe utilise déjà, ou des crédits engagés.
Passer d’AWS à Azure ou à Google Cloud ne réduit pas la complexité. Les trois fonctionnent selon un modèle de responsabilité partagée. Le fournisseur exploite les installations et les plateformes. Le client configure, sécurise et surveille ce qu’il bâtit, et il y applique les correctifs. Les trois facturent à l’usage, sur un grand nombre de lignes.
Choisissez un autre hyperscaler pour une capacité ou pour une condition commerciale. Ne le choisissez pas pour échapper aux coûts ou à la complexité.
Quand un cloud pour développeurs ou un hébergeur de serveurs dédiés convient-il ?
Un cloud pour développeurs ou un hébergeur de serveurs dédiés convient à une application classique opérée par des ingénieurs à l’aise avec l’exploitation de serveurs. Une application classique désigne ici un groupe de machines virtuelles, une base de données relationnelle, un cache et du stockage objet.
L’attrait tient à une facture plus facile à prévoir. Chaque serveur a un prix mensuel fixe, et bon nombre de ces fournisseurs incluent une allocation de bande passante avec chaque serveur.
En contrepartie, le client opère tout. Les correctifs, les sauvegardes, la surveillance, le durcissement de la sécurité et la réponse aux incidents restent à la charge de l’entreprise. Le catalogue est court. Une file de messages, un service de recherche ou un entrepôt de données devient donc un logiciel que l’équipe installe et opère elle-même.
Le guide de la base de connaissances sur la migration de cPanel vers DigitalOcean montre combien de travail d’exploitation un cloud pour développeurs laisse au client. Une entreprise qui n’a aucun ingénieur pour assumer ce travail a déplacé le problème sans le régler.
Quand une PaaS en libre-service convient-elle ?
Une PaaS en libre-service convient à une petite équipe produit qui veut pousser du code et ne jamais ouvrir de session sur un serveur. La plateforme prend en charge la construction de l’application, les déploiements, les certificats et la mise à l’échelle, dans les limites de ses forfaits.
Une PaaS en libre-service sacrifie la maîtrise. L’équipe ne peut pas ajuster le système d’exploitation, et la topologie réseau est en grande partie fixe. Les tâches d’arrière-plan ou les environnements d’exécution inhabituels peuvent mal s’insérer dans le modèle de la plateforme. Le prix par unité de calcul est habituellement plus élevé que celui d’un serveur loué, ce qui pèse davantage à mesure que l’application grandit. Le choix de régions est limité, donc vérifiez-le par rapport à toute exigence de résidence avant de commencer.
Une PaaS en libre-service opère la plateforme, pas l’application. Quand une release brise la production la nuit, la plateforme fonctionne normalement et c’est quand même l’équipe du client qui prend en charge l’incident.
Quand un cloud régional infogéré convient-il ?
Un cloud régional infogéré convient à une entreprise qui exploite une pile classique, n’a pas de personnel d’exploitation et veut qu’une seule partie réponde à la fois de l’infrastructure et de l’exploitation. Le fournisseur s’occupe du provisionnement, des correctifs, des sauvegardes, de la surveillance et de la réponse aux incidents selon un périmètre écrit. Il le fait aussi selon un accord de niveau de service (SLA), un contrat qui énonce les engagements de disponibilité et de réponse.
Un cloud régional infogéré sacrifie la portée géographique et l’étendue du catalogue. Le fournisseur a quelques sites, souvent dans un seul pays. Le catalogue couvre les serveurs, les plateformes applicatives, les bases de données et le stockage, sans les services exclusifs d’un hyperscaler. La mise à l’échelle élastique varie selon le fournisseur et le produit, donc demandez ce qui est automatisé et ce qui est un changement planifié. Bon nombre de fournisseurs infogérés établissent leur prix après un cadrage et ne publient aucune grille. Comparer les prix exige donc une proposition de chacun.
Quand vaut-il mieux rester sur AWS ?
Il vaut mieux rester sur AWS quand l’architecture est saine et que le mal vient d’une absence de responsable. Les signes sont une facture que personne ne lit ligne par ligne, des accès hérités d’employés partis, des ressources sans étiquettes et des sauvegardes jamais restaurées lors d’un test.
Ce sont des problèmes de gouvernance, et ils se règlent sur place. La base de connaissances classe les mesures de réduction habituelles dans les 12 leviers qui réduisent une facture AWS. Ce travail a besoin d’un responsable, soit une personne embauchée, soit un fournisseur qui opère le compte. L’article complémentaire sur le cloud infogéré ou AWS pour une PME propose un cadre pour choisir entre rester et déménager.
Existe-t-il une solution de rechange canadienne à AWS ?
Il existe des fournisseurs de cloud et de cloud infogéré de propriété canadienne, et certains exploitent des régions seulement au Canada. Ils constituent un choix raisonnable quand un contrat client, un responsable de la protection des renseignements personnels ou un acheteur du secteur public demande un hébergement au Canada par une entreprise canadienne.
La résidence des données au Canada n’oblige pas à elle seule à quitter AWS. AWS, Azure et Google Cloud exploitent tous des régions canadiennes. Les points qui tranchent la résidence sont les mêmes pour tous les fournisseurs. Ce sont l’emplacement des données de production, des sauvegardes et des journaux, les sous-traitants qui peuvent y accéder, et l’inscription de ce placement dans l’entente.
L’article sur la résidence des données au Canada et ce qu’il faut exiger d’un hébergeur dresse la liste des éléments à demander par écrit. La base de connaissances décrit, sur le plan technique, une architecture de déploiement uniquement au Canada. La décision juridique revient à un responsable de la protection des renseignements personnels, pas à un hébergeur.
Que coûte un départ d’AWS ?
Le coût d’un départ d’AWS comporte deux volets : le déménagement, puis la nouvelle facture mensuelle. Une comparaison juste compte les deux. Six facteurs déterminent le coût du déménagement.
- La réingénierie. Chaque service propre à AWS que l’application appelle a besoin d’un remplaçant. Les machines virtuelles et les bases de données standards se déplacent avec le moins de travail à refaire. Les fonctions sans serveur (serverless), les files de messages infogérées et les services de données exclusifs exigent une nouvelle conception.
- Le transfert de données sortant. AWS facture normalement les données qui quittent son réseau, de sorte que de gros volumes de stockage peuvent faire de la sortie elle-même un poste de coût. Demandez à AWS quelles conditions s’appliquent à un client qui quitte la plateforme. Le guide sur les coûts de transfert de données AWS explique d’où viennent ces frais.
- L’exploitation en parallèle. Les deux environnements tournent pendant les tests, la bascule et la fenêtre de retour arrière.
- Les engagements existants. La capacité réservée et les plans d’économies (Savings Plans) déjà achetés continuent d’être facturés jusqu’à leur échéance.
- Le temps du personnel. Les ingénieurs qui travaillent à la migration ne bâtissent pas le produit.
- Le nouveau travail d’exploitation. Passer à un cloud pour développeurs peut faire baisser la facture et faire monter les heures que l’équipe consacre aux serveurs.
Pour estimer le côté mensuel, exportez douze mois de factures AWS et regroupez les frais par service. Ajoutez les heures d’ingénieur consacrées aux correctifs, aux incidents et aux questions de coûts. Le calculateur de coûts cloud donne une estimation repère du gaspillage probable, pas une mesure de la vraie facture. L’article sur la façon dont l’hébergement cloud infogéré est tarifé explique ce qui fait varier un devis de cloud infogéré.
Un mandat est décrit dans le scénario type d’AWS vers le cloud infogéré. Dans ce mandat, une entreprise canadienne de logiciel-service (SaaS) a réduit son taux mensuel d’infrastructure de 54 % après une reconstruction de douze semaines, avec refonte de l’architecture, sur Cloud Compute de Stack Harbor. Ce chiffre comprend les frais d’opération infogérée. La même proposition contenait un chemin qui restait sur AWS, avec une baisse de la facture estimée à 28 %. C’est le résultat d’une seule charge de travail, pas une économie typique. Le scénario type déconseille aussi le « lift-and-shift », qui copie chaque serveur chez un nouveau fournisseur et transporte avec lui l’ancienne architecture et son coût.
Quand quitter AWS n’en vaut-il pas la peine ?
Quitter AWS n’en vaut pas la peine dans cinq situations.
- L’application est bâtie sur des services propres à AWS. Le scénario type de Stack Harbor sur une sortie d’AWS affirme elle-même que partir coûtera de la réingénierie à une telle équipe.
- L’entreprise sert des utilisateurs sur plusieurs continents. Une présence mondiale demande un fournisseur qui a de nombreuses régions.
- La charge varie de façon brusque et imprévisible. La facturation à l’usage et une mise à l’échelle automatisée éprouvée conviennent à une charge qui fluctue beaucoup en quelques heures.
- Des ingénieurs sont déjà responsables du compte et s’en acquittent bien. Une équipe qui gère la production sous forme de code et qui lit la facture gagne peu à déménager.
- L’empreinte est minuscule. Un serveur et un compartiment de stockage ne justifient pas un projet de migration.
La taille de l’entreprise ne figure pas dans cette liste. AWS peut très bien convenir à une entreprise de dix personnes dont le produit est sans serveur.
Que devrait vérifier une entreprise avant de choisir une solution de rechange à AWS ?
Une entreprise qui envisage une solution de rechange à AWS devrait répondre par écrit à ces sept questions avant de demander la moindre proposition.
- Quels services AWS l’application appelle-t-elle directement, et lesquels sont exclusifs à AWS ?
- Qui lit la facture AWS, révise les accès et répond aux alertes aujourd’hui ? Nommez la personne.
- Où les données de production, les sauvegardes et les journaux doivent-ils résider, et qui l’exige ?
- À quoi ressemble la charge sur une année : stable, ou fortement variable ?
- Quel est le coût mensuel complet aujourd’hui, y compris les heures du personnel consacrées à l’exploitation ?
- Que coûterait le déménagement selon les six facteurs ci-dessus ?
- Après le déménagement, qui applique les correctifs, surveille et intervient la nuit ?
Si la réponse à la question 1 place des services exclusifs au cœur de l’application, restez sur AWS et réglez la question de la responsabilité. Si la question 7 reste sans réponse, écartez le cloud pour développeurs. Comparez plutôt un fournisseur infogéré avec un opérateur pour le compte actuel. Si la charge est portable et que l’équipe compte des ingénieurs, un cloud pour développeurs ou une PaaS est un candidat valable.
Où se situe Stack Harbor
Stack Harbor est un fournisseur d’exploitation infonuagique gérée (MSP) de propriété canadienne, dont le siège est à Montréal, au Québec. Stack Harbor opère des environnements cloud de production, et non les TI de bureau. L’entreprise sert des PME et des agences d’environ 5 à 200 personnes qui opèrent des systèmes de production sans avoir leur propre équipe d’exploitation 24/7.
Stack Harbor est un fournisseur de cloud régional infogéré, la quatrième option de cet article, et opère aussi des comptes AWS pour les entreprises qui y restent. Son service Cloud Compute fournit des machines virtuelles, du bare metal, des VLAN privés (des réseaux internes isolés) et du stockage tout-flash dans deux centres de données à Montréal. Cloud PaaS est une plateforme applicative infogérée, avec des bases de données infogérées et de l’autoscaling. Pour une entreprise qui reste sur AWS, le service d’opérations AWS infogérées travaille au moyen d’un rôle d’accès dédié, et le compte racine (root) reste chez le client.
Les limites sont précises. Les propres régions de Stack Harbor se trouvent seulement au Canada. Sur Cloud Compute, la bascule régionale est une opération infogérée, pas automatique. La mise à l’échelle horizontale sur Cloud Compute est une opération planifiée, pas automatisée. Stack Harbor ne garantit pas la disponibilité. Son accord de niveau de service l’engage à 99,9 % de disponibilité mensuelle pour son réseau et son infrastructure IaaS, avec un crédit de service défini comme seul recours. Stack Harbor ne publie pas de prix, donc une comparaison sur grille est impossible. Une migration commence par une découverte, un mandat de cadrage court et payant qui produit un plan de migration écrit et un devis fixe. La page Confiance et sécurité expose la position en matière de conformité. Elle précise que Stack Harbor ne détient aucun rapport SOC 2, un audit indépendant des contrôles de sécurité, en son nom.
