Pourquoi ne voudriez-vous pas utiliser le Cloud Computing

Notre entreprise envisage de passer de l’hébergement de ses propres serveurs à EC2 et je me demandais si c’était une bonne idée.

J’ai vu beaucoup de choses sur le cloud computing (et plus précisément EC2) qui font x, ou peut-il y arriver, mais ma vraie question est la suivante: pourquoi ne voulez-vous PAS l’utiliser?

Si vous étiez en train de créer une entreprise, quelles sont les raisons (en dehors du coût) que vous choisiriez pour gérer vos propres serveurs?

Je sais qu’il y a beaucoup de calculs de coûts que vous pouvez faire en ce qui concerne la bande passante, l’utilisation du disque, etc., mais il y a bien sûr d’autres coûts liés à la maintenance de votre propre serveur. Pour le bien de cette discussion, je suis prêt à considérer les coûts à peu près égaux.

Je me souviens que Joel Spolsky a écrit un peu de flou à ce moment-là, mais je n’ai pas réussi à le trouver.

Quelqu’un a des raisons?

Merci!

Je peux penser à plusieurs raisons pourquoi ne pas utiliser EC2 (et je parle de EC2, pas de maillage en général):

  • Fiabilité : Amazon ne donne aucune garantie quant à la disponibilité / le temps d’arrêt / la sécurité de l’EC2
  • Sécurité : Amazon ne donne aucune garantie quant à la divulgation de vos données
  • Persistance : la continuité de vos données (y compris l’effort de configuration du système) est compliquée par rapport à EC2
  • Management : il existe très peu d’outils de gestion intégrés pour un cloud déployé sur EC2
  • Réseau : le réseau virtuel qui permet aux instances EC2 de communiquer présente des limitations assez pénibles (latence, absence de multidiffusion, emplacement topologique arbitraire)

Et pour finir ça:

  • Coût : sur le long terme, si vous n’utilisez pas EC2 pour absorber les pics de trafic, cela coûtera beaucoup plus cher que d’investir dans vos propres serveurs (les serveurs bon marché comme Supermicro coûtent quelques centaines de dollars…)

D’un autre côté, je pense toujours que EC2 est un excellent moyen pour absorber le trafic de pointe non sensible, si votre architecture le permet.

Quelques questions à poser:

Quelle est la disponibilité prévue et comment les temps d’arrêt affectent-ils votre entreprise? Quel type d’accord de niveau de service pouvez-vous obtenir, quelles sont les pénalités pour ne pas en avoir reçu, et dans quelle mesure êtes-vous certain que les objectives de disponibilité du SLA seront atteints? (Ils peuvent être meilleurs ou moins bons pour garder les systèmes en place que vous.)

Quelle est la sensibilité des données que vous proposez de mettre dans le cloud? Encore une fois, nous abordons la question de la sécurité que promet le fournisseur, des pénalités et indemnités contractuelles et de la confiance que vous accordez au fournisseur. De plus, il peut y avoir des exigences externes. Si vous traitez des données relatives à la santé aux États-Unis, vous êtes soumis à des exigences très ssortingctes. Si vous traitez des données de carte de crédit, vous avez également des responsabilités (contractuelles, non légales).

Dans quelle mesure sera-t-il facile de sortir de l’arrangement, le service ne devrait-il pas être ce qui était attendu, ou si vous trouvez une meilleure offre ailleurs? Cela inclut non seulement récupérer vos données, mais également certaines versions des applications que vous avez utilisées. Considérez les possibilités de faillite de votre fournisseur (Amazon ne fera pas faillite de sitôt, mais ils pourraient se séparer d’un fournisseur de cloud qui pourrait alors faire faillite) ou procéder à une réorganisation interne. Gardez à l’esprit qu’une entreprise en difficulté peut ne pas être en mesure de répondre à vos attentes en matière de service.

Combien d’indépendance allez-vous avoir? Allez-vous exécuter leur logiciel ou logiciel que vous choisissez? Comment sera-t-il facile de reconfigurer?

Quel est le schéma de tarification? Est-il possible que les factures atteignent des niveaux inacceptables sans avertissement adéquat?

Quel est le plan d’urgence? Idéalement, il exécute votre logiciel sur des serveurs situés à un endroit différent de celui où la catastrophe s’est produite.

Que pense votre service juridique (ou mandataire social) du contrat? Existe-t-il un mécanisme de règlement des différends et, dans l’affirmative, est-ce juste pour vous?

Enfin, que comptez-vous sortir du passage au cloud? Qu’est-ce que vous êtes prêt à payer? Sur quoi pouvez-vous faire des compromis et de quoi avez-vous besoin?

Les données hautement sensibles peuvent être mieux contrôlées. Et il y a une législation; Certaines informations sensibles à la vie privée, par exemple, peuvent ne pas quitter le pays.

En outre, à l’exception de Microsoft Azure en combinaison avec SDS, les magasins de données ont tendance à ne pas être relationnels, ce qui constitue une gêne dans certains cas.

Peut-être l’inquiétude que cette grande entreprise sera plus probablement approchée par un agent Smith du gouvernement pour espionner tout le monde qu’un petit fournisseur quelque part.

Une grande entreprise – plus de clients – plus de données à regrouper et à reconnaître des modèles – plus de ressources pour organiser un système de surveillance sophistiqué.

Peut-être que c’est plus un fantasme mais qui sait jamais?

Si vous n’avez pas de paranoïa, cela ne signifie pas pour autant que vous ne soyez pas surveillé.

Le gros est le suivant: si Amazon tombe en panne, vous ne pouvez rien faire pour le restaurer.

Je ne parle pas des scénarios catastrophiques dans lesquels l’entreprise disparaît. Je veux dire que vous êtes à la merci de leurs temps d’arrêt, avec peu de recours de votre part.

  • Sécurité – vous ne savez pas ce qui est fait pour vos données
  • Dépendance – votre entreprise est désormais directement liée au fournisseur

Il existe différents types de cloud computing avec de nombreux fournisseurs différents. Cela me rendrait nerveux de coder mes applications pour qu’elles fonctionnent avec un seul fournisseur de cloud. que vous deviez spécifiquement coder pour ..amazon et Microsoft je crois que vous devez coder spécifiquement pour cette plate-forme – peut-être aussi google.

Cela dit, j’ai récemment largué mes propres serveurs dédiés et je suis passé à la plateforme Mosso Cloud de Rackspaces (qui n’a pas besoin de codage propriétaire) et je suis vraiment très content. Réduire mes coûts de moitié et les performances sont bien meilleures qu’avant. Mes bases de données de serveur SQL s’exécutent désormais sur des versions de serveur SQL d’entreprise de 64 bits avec 32 G de mémoire vive – ce qui m’a coûté une fortune sur mon infrastructure de fournisseurs précédente.

En ce qui concerne le manque de chance quand le cloud est en panne, c’était vrai si mon serveur dédié tombait en panne – ça ne l’a jamais été, mais s’il y avait un crash matériel sur mon serveur dédié, je ne suis pas sûr qu’il revienne en ligne tout plus rapide que rackspace pourrait apporter leur nuage.

Manque de contrôle.

Placer votre logiciel sur le cloud de quelqu’un d’autre représente un transfert de contrôle. Ils peuvent créer une limite de taille de téléchargement de fichier ou des limites de mémoire susceptibles de nuire à votre application. Une vulnérabilité de sécurité dans leur panneau de contrôle pourrait entraîner le piratage de votre site.

Les problèmes de sécurité ne sont pas pertinents si votre application effectue son propre cryptage. Amazon stocke alors des données chiffrées qu’ils n’ont aucun moyen de déchiffrer.

Mais en plus des problèmes de disponibilité, Amazon pourrait décider d’augmenter les prix à leur guise. Si vous en dépendez, vous devrez simplement le payer.

Dépend de combien vous faites confiance à votre propre infrastructure par rapport à un service cloud tiers. À mon avis, la plupart des entresockets (du moins pas liées à l’informatique) devraient choisir la dernière.

Une autre chose que vous perdez avec le cloud est la possibilité de choisir exactement le système d’exploitation que vous souhaitez exécuter. Par exemple, le dernier kernel Linux de Fedora disponible sur EC2 est FC8, et la dernière version de Windows est Server 2003.

Outre la question de la fiabilité, de la fiabilité et du coût, la question de la propriété des données se pose. Lorsque vous localisez des données sur le serveur de quelqu’un d’autre, vous ne contrôlez plus qui affiche, accède, modifie ou utilise ces données. Bien que les opérateurs de cloud computing puissent limiter votre access, vous ne disposez d’aucun moyen pour limiter les leurs ou limiter ceux auxquels ils donnent access. Oui, vous pouvez chiffrer toutes les données sur le serveur, mais vous n’avez aucun moyen de savoir qui possède un access root au serveur lui-même et des moyens d’empêcher les autres de télécharger vos données chiffrées et de les ouvrir. Vous perdez le contrôle de vos données. Selon le type d’applications que vous utilisez et le caractère propriétaire des données impliquées, cela pourrait engendrer des risques de sécurité et / ou de responsabilité d’entreprise.

L’autre facteur à considérer est ce qui arriverait à votre entreprise si Amazon et / ou EC2 disparaissaient soudainement du jour au lendemain. Bien que ce soit une position apparemment absurde, cela pourrait arriver. Seriez-vous en mesure de remplir rapidement le trou et de restaurer le service, ou vos applications potentiellement générasortingces de revenus pourraient-elles dépérir pendant que le personnel informatique se démènerait pour obtenir des serveurs et de la bande passante pour les remettre en ligne? De plus, qu’adviendrait-il de vos données? Le disque dur du cloud contenant toutes vos informations existe toujours, quelque part, et pourrait poser un risque potentiel de responsabilité en fonction des informations que vous avez stockées: éléments tels que des informations personnelles, des enregistrements de transactions commerciales, etc.

Si je commençais ma propre entreprise maintenant, je passerais par les tracas de l’achat et de la maintenance de mes propres serveurs, alors j’ai conservé la propriété des données. Je pourrais contrôler l’access root au matériel, ainsi que contrôler qui peut accéder et modifier les données.

Questions de sécurité sans réponse.

Vraiment, est-ce que tu veux que ton adresse IP soit là, où tu n’es pas celle qui la contrôle?

La plupart des environnements informatiques en nuage sont au moins partiellement spécifiques au fournisseur. Il n’y a pas de bon moyen de déplacer des choses d’un nuage à un autre sans avoir à réécrire beaucoup. Ce type de locking vous met à la merci d’un fournisseur en ce qui concerne les temps d’arrêt, les augmentations de prix, etc. Si vous louez ou possédez vos propres serveurs, les fournisseurs d’hébergement et les colos sont interchangeables. Vous avez toujours la possibilité de vous déplacer ailleurs.

Cela peut changer à l’avenir, à mesure que ces choses deviennent normalisées, mais pour le moment, si vous vous attachez au cloud, vous devez vous en tenir à un fournisseur spécifique.

C’est un peu comme le commentaire “Pourquoi utiliseriez-vous Linux” que j’ai reçu il y a de nombreuses années? La réponse a été que c’est une solution à la recherche d’un problème.

Alors, quels sont vos buts et objectives pour passer à EC2?

Je serais intéressé de savoir si vous souhaitez toujours passer à un cloud, si c’était le vôtre.

Le cloud computing a rapproché un peu la programmation parallèle, mais vous devez toujours comprendre comment l’utiliser au mieux – sinon vous allez perdre des cycles de calcul et de la bande passante.

Re-architecturer votre application pour une utilisation plus efficace d’un service de cloud computing n’est pas une mince affaire.

Outre ce qui a déjà été dit ici, nous devons considérer l’uniformité dans l’ensemble des activités. Toutes vos applications vont-elles être hébergées dans le cloud, ou uniquement dans la plupart des cas? Est-il suffisant de déclencher l’utilisation du cloud alors qu’il vous faut encore du personnel pour gérer quelques serveurs spéciaux?

En particulier, il peut exister un matériel spécial dont vous avez besoin pour communiquer avec de tels modems afin d’accepter des données entrantes, ou des cartes vocales qui émettent des appels téléphoniques automatisés. Je ne sais pas comment ces choses pourraient être gérées dans un environnement cloud.