Comparaison de la distribution des application : 2005 contre 2015

James Ward, qui écrit du code (sa description), a récemment écrit un excellent article dans lequel il a comparé le déploiement application aujourd'hui à celui d'il y a dix ans. L’un des secrets les mieux gardés du secteur informatique dans son ensemble est que les changements dans les architectures et le déploiement des application ont un impact direct sur la livraison des application (le processus réel consistant à garantir que les applications sont rapides, sécurisées et disponibles pour leurs consommateurs). Les changements apportés aujourd’hui par les microservices, par exemple, sont importants dans la manière dont ils vont modifier l’architecture du réseau ainsi que son modèle de déploiement.

Je sais, je sais. Vous pensez que les évolutions vers les microservices, la conteneurisation et le cloud rendent le réseau abstrait, rendant les applications moins dépendantes d'eux. Et c’est vrai, du point de vue des développeurs et peut-être même des opérateurs. Mais un réseau est toujours nécessaire ; les données échangées doivent toujours circuler sur ces canaux et les services qui résident sur le réseau sont toujours responsables de nombreuses fonctions qui accélèrent les applications, les maintiennent en sécurité et assurent leur disponibilité . Les changements dans l’endroit et la manière dont les applications sont composées et déployées ont donc nécessairement un impact sur ces services, même si l’ application n’est pas consciente de leur existence (et honnêtement, elle ne devrait même jamais le savoir). Ils sont comme des anges gardiens de cette façon.)

Ainsi, compte tenu de la relation, même si elle n’est pas réciproque de la part de l’ application, l’article de James a inspiré un regard parallèle sur les changements dans la façon dont nous fournissons des applications au cours des dix dernières années.

Architecture de déploiement

2005	2015
Ligne Conga	Plateforme

En 2005, les équipes réseau (NetOps) ont déployé les différents services application nécessaires pour fournir des applications dans ce que nous aimons appeler une « conga line ». Il s’agissait de solutions ponctuelles individuelles. Si vous aviez besoin de quelque chose pour rendre cette application plus rapide, vous déployiez un produit optimisation des performances web sur votre propre boîte personnelle et privée. Une autre case pour l’équilibrage de charge, une autre pour la sécurité des applications, et ainsi de suite. Finalement, il y avait de longues files de nombreuses boîtes, chacune devant être traversée dans les deux sens. 

En 2004, les contrôleurs de distribution application sont apparus (mais étaient très immatures en 2005) et ont commencé à évoluer vers ce que nous avons aujourd'hui, qui est une plate-forme . Ces plateformes offrent des fonctionnalités et un traitement communs et peuvent être étendues avec des modules (ou des plug-ins ou des modules complémentaires ou comme vous souhaitez les appeler). L’approche de la plateforme réduit considérablement le temps passé « sur le fil », de la même manière que la conteneurisation et la virtualisation réduisent le temps passé à voyager entre les applications et les services. Il offre également la possibilité de réduire les coûts opérationnels en partageant une base commune – la plateforme – qui normalise la gestion des différents services application nécessaires pour fournir une application aujourd’hui.

L'évolution du produit vers la plateforme est avantageuse car le déploiement des application évolue vers des architectures plus jetables et décomposées exploitant des technologies émergentes telles que les conteneurs et les microservices et le déploiement dans des environnements cloud, car ils peuvent être utilisés pour déployer une variété de services application , ou un seul, en utilisant le même cœur standardisé. Cela signifie moins de frais administratifs à mesure que l'empreinte des services application déployés s'étend et la possibilité d'ajouter des services selon les besoins à mesure que les applications se développent.

Méthodes de déploiement

2005	2015
Déploiement manuel	Déploiement programmable

En 2005, les interfaces graphiques Web commençaient à peine à être utilisées et la principale méthode de provisionnement et de configuration des services application se faisait via l'interface de ligne de commande. Ce processus, comme tous les processus manuels, prenait du temps et, à mesure que les services application devenaient plus complexes, il prenait encore plus de temps. L'introduction de problèmes dus à l'erreur humaine et l'impact qui en résulte (être dans le réseau augmente de manière exponentielle le rayon d'explosion d'une mauvaise configuration) ont nécessité une surveillance encore plus longue. Le copier-coller était courant, mais pas infaillible, et la charge administrative liée à la gestion des services était suffisamment importante pour garantir que seules les applications les plus importantes bénéficiaient des avantages de ces services.

Avance rapide jusqu’en 2015 et la révolution DevOps. La programmabilité – à la fois dans les API et dans les configurations basées sur des modèles – change tout, même dans le réseau. Les services application peuvent désormais être automatisés via des API utilisant des frameworks populaires comme Puppet et Chef, pré-intégrés à des solutions d'orchestration comme Cisco APIC et VMware NSX, et pilotés sur mesure par Python, Perl, bash et curl. Les modèles de services application permettent la standardisation, la réutilisation et encouragent le traitement de l’infrastructure « en tant que code » pour permettre aux pratiques de livraison continue de s’étendre au réseau.

Bien qu'elle ne soit pas aussi omniprésente que la livraison continue dans le développement application , la livraison application a évolué (et continue d'évoluer) pour prendre en charge des options de déploiement programmables qui réduisent le délai de mise sur le marché grâce à une fourniture de services plus rapide ainsi qu'en réduisant les coûts opérationnels grâce à l'automatisation et à la réutilisation.

Facteurs de forme de déploiement

2005	2015
Gros fer	Virtualisé

En 2005, la course à la création de matériel réseau plus grand, plus performant, plus rapide et plus performant était à l'ordre du jour. L'augmentation des vitesses Ethernet et l'explosion des applications Web ont nécessité une expansion complémentaire des gros équipements déployés sur le réseau pour répondre aux exigences des services application .

Aujourd’hui, l’accent est mis sur la densité et l’utilisation optimale des ressources. Cela signifie la virtualisation et le cloud computing, tous deux pris en charge par la virtualisation des plates-formes de distribution application . Les plates-formes de distribution application peuvent désormais être déployées dans des environnements cloud tels qu'AWS, Microsoft Azure et Rackspace, ainsi que dans une appliance virtuelle déployable sur du matériel spécialement conçu ou disponible dans le commerce. Cette capacité est une exigence, non seulement pour prendre en charge les environnements cloud, mais également pour s’adapter aux architectures émergentes telles que les microservices. Les microservices et les serveurs eux-mêmes sont aujourd’hui, comme le note James Ward, « jetables, immuables et éphémères… ».

Cela signifie que de nombreux services application entrant dans le domaine de DevOps (équilibrage de charge, sécurité des application et optimisation) doivent répondre aux critères d’un centre de données défini par logiciel . Au minimum, ils doivent pouvoir s’intégrer dans un modèle immuable et jetable à grande échelle. De nombreuses plateformes de distribution application existent aujourd’hui et, combinées à des options de déploiement programmables, sont prêtes à relever le défi.

Responsabilité de déploiement

En 2005 – et dans de nombreuses organisations encore aujourd’hui – l’équipe réseau est entièrement responsable du déploiement et de la gestion de la distribution des application . Chaque aspect de la livraison, de l'approvisionnement à l'approvisionnement en passant par la configuration, était et est encore souvent géré par les opérations réseau. Ce modèle décousu impliquait des retards dans la définition des exigences, la création de tickets et le provisionnement et la configuration manuels par les ingénieurs des services application requis pour fournir une application.

Aujourd’hui, c’est toujours le cas dans de nombreuses organisations, mais l’impact du cloud et des microservices combiné à l’adoption de DevOps change la donne. La demande d’informatique en tant que service est forte, avec un transfert de responsabilité pour la configuration des services application vers les équipes d’exploitation ou même de développement. Il est nécessaire que les services affines aux application soient situés physiquement et topologiquement plus près de l'application. Cela place DevOps fermement aux commandes et responsable de la fourniture et de la configuration de ces services.

Cela ne signifie pas que l’équipe réseau se lave les mains de la livraison des application . Il existe un segment important d’ applications et d’entreprises qui nécessitent des services application fournis de manière plus traditionnelle, axés sur la fiabilité plutôt que sur l’agilité. Ces services sont toujours, et resteront probablement, du ressort de l’équipe réseau. Mais d’autres sont et continueront d’évoluer vers la responsabilité de DevOps.

La livraison application a beaucoup progressé au cours des dix dernières années. Il est passé d’un ensemble de produits à une plateforme unifiée, a gagné en programmabilité et est passé d’un gros matériel à la prise en charge des hyperviseurs et du déploiement dans le cloud. Alors que les applications mobiles, les microservices et DevOps continuent de changer radicalement la manière dont les applications sont créées, déployées et livrées, attendez-vous à voir une évolution continue des services qui fournissent en fin de compte ces applications et les maintiennent rapides, sécurisées et disponibles.