CPQ Cloud

« Stateless, stateful, multi-tenant, single-tenant, virtualisation, micro-services, orchestrateurs, virtualisation… »

Ceux-ci, et bien d'autres termes similaires, font partie de mon vocabulaire en tant qu'architecte KBMax. Vous seriez surpris qu'aujourd'hui ils fassent partie de la vie de tout le monde, même si ce n'est pas évident. Dans le monde d'aujourd'hui, tout le monde utilise un système cloud sous une forme ou une autre, mais peut ou non être conscient des implications du service utilisé quotidiennement, telles que le coût, la sécurité, la disponibilité et la confidentialité.

« Qu'est-ce que l'architecture cloud et pourquoi devrais-je m'en soucier ? »

If you are selecting CPQ software (or any software) for your company, you may be interested in preventing wasted resources on future hidden costs, by simply investing in (or buying) future-proof software. I’ve seen many companies who were convinced they were getting a cloud application, but later realized that they had purchased ‘virtualized software’ and paid a very high price to end up getting stuck with the same version of the software forever, racking up hidden costs.

Puisque je programme depuis 40 ans, je voulais vous raconter l'histoire de l'architecture cloud de mon point de vue. Vous pouvez rechercher sur Google chacun des termes ci-dessus, mais je pense que vous pouvez mieux comprendre le « pourquoi » derrière certains des choix architecturaux après avoir appris l'histoire qui les sous-tend. Comme dans tout autre domaine, les « découvertes » sont la réponse aux problèmes et besoins actuels.

Une brève histoire de l'informatique distribuée

Ordinateurs centraux

Je vais sauter le mainframe car il est trop profond dans l'histoire ancienne de l'informatique.

Serveurs et postes de travail connectés

Commençons plutôt par le début de ce siècle, où les ordinateurs de bureau étaient courants et les serveurs étaient présents, mais uniquement pour quelques tâches telles que le partage de fichiers, l'impression, l'authentification des utilisateurs et les bases de données. Les données étaient physiquement « possédées » et le logiciel et le matériel étaient vendus ensemble. Pendant ce temps pour les utilisateurs, le logiciel était principalement une application locale avec des instances installées sur un ordinateur de bureau. La sécurité n'était pas un réel problème, même si tout le monde était un « administrateur », et certains utilisateurs avaient même un « post it » avec leur mot de passe apposé sur le moniteur. Le principal problème était le versioning du logiciel, la maintenance du matériel, la sauvegarde et la sous-utilisation des serveurs. 

Je me souviens que le "serveur" était la partie la plus chère de "l'affaire", et la plus sous-utilisée : il n'était pas rare de se connecter à un serveur et de voir que l'application CPU la plus exigeante était le texte 3D en rotation de l'écran Windows économiseur (je n'ai jamais compris pourquoi c'était le plus courant). Mettre à jour une application était une vraie galère et nécessitait plusieurs techniciens pour faire face aux différents problèmes qui surgissaient. Donc, naturellement, l'entretien n'a eu lieu que lorsqu'il était nécessaire ou inévitable. 

Informatique basée sur le Web

Ensuite, le Web a commencé à entrer dans l'entreprise de manière significative, car avoir un site Web est rapidement devenu obligatoire. Ce serveur sous-utilisé a commencé à être utilisé par les entreprises les plus avant-gardistes et les plus courageuses. Les organisations n'ont pas connaître qu'ils étaient « courageux », mais ils l'étaient vraiment, compte tenu des énormes problèmes de sécurité qu'ils ont commencé à rencontrer. Les services informatiques ont commencé à se développer : serveurs, connexions internet dédiées, périphériques réseaux, rack, câbles, onduleurs, etc…

Virtualisation de serveur

Il était temps pour un petit nouveau : la virtualisation. « Au lieu d'avoir de nombreux serveurs sous-utilisés, et si nous créions une copie virtuelle de chaque serveur, puis les mettions tous dans un seul serveur physique ? » L'idée était géniale, et honnêtement, c'est toujours une excellente idée aujourd'hui.

Mais du point de vue des logiciels de bureau, tout était exactement le même jusqu'à ce que nous commencions à voir les applications Web devenir une utilisation commerciale réelle. Une application Web est généralement divisée en 2 parties : l'interface utilisateur (interface utilisateur) construite en HTML, CSS et Javascript qui exécute la logique dans le client, et la partie restante qui est exécutée côté serveur.

On voit ici émerger un nouveau terme architectural : avec état. Avec état signifie que le serveur connaît parfaitement le client et le contexte de chaque transaction. Chaque transaction est effectuée dans le contexte des transactions précédentes, et la transaction en cours peut être affectée par ce qui s'est passé lors des transactions précédentes. Pour ces raisons, les applications avec état utilisent les mêmes serveurs chaque fois qu'elles traitent une demande d'un utilisateur. Voici le problème principal : étant donné que chaque serveur a un nombre limité de clients qu'il peut servir, la mise à l'échelle n'est pas facile. Vous ne pouvez pas simplement ajouter un nouveau serveur. Au lieu de cela, vous devez créer une logique telle que « Les clients dont le nom commence par A à G vont au serveur 1, de G à O vont au serveur 2… », et ainsi de suite. 

Mais « avec état » signifie également que le contexte est stocké sur le serveur. Parfois, le serveur contient également la base de données ou héberge différents serveurs virtuels sur le même matériel.

Comme vous pouvez l'imaginer, si le serveur tombe pour une raison quelconque… tout est perdu !

La solution à ce défi présente le terme inverse : Apatride. Un serveur sans état ne stocke pas le contexte du client, mais il exécute uniquement la requête. Le client saute entre les serveurs et un « équilibreur de charge » qui affecte dynamiquement les clients à chaque serveur, répartissant la charge. Si un serveur tombe en panne, pas de problème ! L'« équilibreur de charge » s'arrête pour acheminer le trafic vers le serveur hors ligne. Si la charge augmente au-delà de la capacité du serveur, il suffit d'ajouter des serveurs sans état supplémentaires. Évidemment, l'inverse est également vrai : si le nombre de clients diminue, les serveurs peuvent être facilement désactivés. C'est aussi ce qu'on appelle un 'piscine élastique'.

Du point de vue d'un développeur, ce moment historique a représenté un énorme changement. Nous avons dû nous éloigner du bureau, où tout était une seule application où toutes les ressources et les composants du logiciel étaient compressés. Toutes les compétences et les problèmes étaient dans une « singularité ». Cela a introduit un nouvel ensemble de problèmes : serveurs, connexions, logique frontale, logique principale, nouveaux langages et abstraction de données. Beaucoup ont essayé d'adapter leurs connaissances à ce nouveau paradigme, au lieu de partir de zéro et de se spécialiser dans certains domaines (les gens sont encore aujourd'hui coincés dans la singularité de l'application bureautique). Vous rencontrez encore régulièrement des logiciels dont vous pouvez clairement dire qu'il s'agit d'un « port » d'une application de bureau vers une infrastructure cloud, en particulier lorsque vous êtes obligé de gérer des « installations », des « fichiers » et des « versions ». 

Applications en nuage

Nous sommes maintenant en 2011 : Occupy Wall Street bat son plein, et des « applications cloud » sont enfin en cours de développement pour un « système d'exploitation cloud ». Il est important de noter que l'exécution du logiciel se faisait toujours dans des machines virtuelles. L'architecture logicielle était « monolithique », ce qui signifie que chaque serveur virtuel sans état disposait d'une copie du logiciel. L'optimisation maximale avait un composant Web et des composants « travailleurs ». Le « travailleur » était la pièce « d'exécution » comme la création de documents, la compression de fichiers, les algorithmes de calcul et les tâches de longue durée.

Cette architecture n'était pas vraiment efficace du point de vue de l'utilisation du CPU et entraînait des serveurs surchargés ou sous-utilisés. Il n'était pas non plus efficace pour les développeurs de gérer cette architecture monolithique, car pour mettre à jour une petite partie du logiciel, il fallait publier l'application sur tous les serveurs, ce qui entraînait des temps d'arrêt. L'architecture monolithique est plus facile à développer, tester et déployer… mais difficile à faire évoluer.

Ici encore, nous sommes confrontés à un autre défi qui a poussé le cloud vers l'avant : « Comment pouvons-nous décomposer une application monolithique en plus petits morceaux ? »

Microservices, orchestrateurs et conteneurs, Oh My!

La réponse aux applications cloud monolithiques est « l'orchestration avec des microservices ». Imaginons de diviser une application en éléments autonomes de fonctionnalités métier, en suivant la 'philosophie UNIX : "Faites une chose et faites-la bien". Une fois que vous avez divisé votre application en ces morceaux, vous pouvez les appeler 'microservices'. Imaginez tous ces microservices comme des éléments d'un jeu Tetris, assemblant tous les serveurs virtuels de manière à mieux utiliser les ressources CPU, mémoire, réseau et stockage.

Le 'Orchestrateur' est vraiment celui qui 'joue à Tetris', et les VM s'appellent 'Nœuds' (ou les niveaux/planches de notre jeu Tetris). Si un nœud tombe en panne, l'orchestrateur peut créer de nouveaux nœuds ou déplacer les services vers un ou plusieurs nœuds. Si vous mettez à jour un microservice, l'orchestrateur peut conserver l'ancienne version en vie, déployer la nouvelle version, puis arrêter l'ancienne version. 

Comme vous pouvez l'imaginer, l'orchestrateur avec microservices est une architecture très flexible et robuste, mais il y a un problème… quelqu'un doit gérer et maintenir l'orchestrateur !

Cela nous a conduit à réinventer la «machine virtuelle». Une machine virtuelle est un serveur logique contenant l'intégralité de la pile logicielle : pilotes, système d'exploitation et application. Une machine physique peut héberger plusieurs machines virtuelles, même pour différents clients, car elles sont complètement isolées les unes des autres. Cette approche est très puissante, mais elle n'est pas très efficace car le système d'exploitation utilise beaucoup de ressources uniquement pour « exister », et chaque machine virtuelle nécessite une maintenance telle que des mises à niveau, des correctifs de sécurité et des configurations.

UNE Récipient isole l'application et partage le système d'exploitation entre tous les autres conteneurs. Au lieu de virtualiser le matériel, comme une machine virtuelle dans un conteneur, le système d'exploitation est virtualisé.

Bon, revenons à l'architecture. Vous avez peut-être déjà deviné que le meilleur candidat pour s'asseoir à l'intérieur d'un conteneur est un microservice. Les microservices étant totalement séparés, vous pouvez héberger des « microservices contenus » de différentes instances au sein du même orchestrateur.

Sans serveur

Nous sommes à la dernière étape de notre leçon d'histoire, regardons donc le dernier terme : Sans serveur. Si l'orchestrateur est géré par quelqu'un d'autre, comme un fournisseur de cloud, le développement d'une application comme KBMax consiste simplement à développer et déployer des microservices conteneurisés. Les microservices peuvent être mis à l'échelle, déplacés, redémarrés et mis à niveau automatiquement, sans gaspiller les ressources de l'entreprise. Mais comment l'application est-elle servie à chaque client ?

La première option, Individuel, est la plus évidente pour une option « sur site », car elle implique une application dédiée et un stockage et une base de données dédiés. Il s'agit d'une application cloud avec une instance de tout dédiée à chaque client. Cette approche présente des avantages et des inconvénients : chaque client peut avoir un chemin de mise à niveau, une sauvegarde et un contrôle différents. Cependant, cela devient rapidement une ponction sur les ressources car le client a la fausse impression qu'il peut contrôler la version et la sécurité.

L'option inverse s'appelle Locations multiples: Il n'y a qu'une seule application et qu'un seul stockage/base de données. Tous les clients utilisent la même application et leurs données sont conservées côte à côte sur le même stockage/DB. Cette option est très efficace et les versions logicielles sont généralement plus fréquentes et moins intrusives. Mais il ya un hic. Si vous êtes une entreprise particulièrement attentive à la sécurité, vous ne souhaitez probablement pas que vos données soient stockées avec celles d'autres entreprises. KBMax résout ce problème avec Location hybride : Une application, mais un stockage/DB dédié pour chaque client.

Choosing a Real CPQ Cloud

Espérons que cette plongée profonde dans l'histoire du cloud computing vous aide à mieux comprendre les tenants et les aboutissants de l'architecture du cloud. Nous aimons partager ces connaissances avec d'autres entreprises, afin qu'elles puissent apprendre à repérer les applications qui ne suivent pas les tendances les plus récentes pour optimiser la vitesse, la sécurité et l'accès.

KBMax is built using the latest cloud architectures following development best practices, ensuring top performance and security for our CPQ cloud customers. We often come across customers who were sold a ‘fake cloud’ by another CPQ vendor, only to realize the grift once it was too late. Look for a future article, where we’ll discuss the differences between types of cloud infrastructures (SaaS, IaaS, PaaS, etc.) and how they can fundamentally change the customer experience and total cost of ownership. Because, yeah, not all ‘clouds’ are the same.