Mis à jours 11 mai 2018 Les progrès technologiques sous-jacents créent un changement vers des fonctions axées sur les événements et les améliorations radicales dans le temps de valeur.
Le but de l’exécution de logiciels d’application est de fournir une certaine valeur commerciale. Cette dernière est fournie en créant une logique métier et en l’exploitant afin de fournir un service à certains utilisateurs.
Le délai entre la création d’une logique métier et la fourniture de services aux utilisateurs avec cette logique est le moment à évaluer. Le coût pour fournir cette valeur est le coût de la création plus le coût de la livraison.
Auparavant, les coûts étaient élevés et les préoccupations liées à l’efficacité dominaient, le délai élevé de mise en valeur étant considéré comme normal. Aujourd’hui, lorsque les entreprises mesurent et optimisent leurs activités, le temps de valeur devient un indicateur dominant, poussé par les pressions concurrentielles, favorisé par les progrès technologiques et par la réduction des coûts.
En d’autres termes, pour augmenter le retour sur investissement, vous devez trouver des moyens d’augmenter le rendement, de commencer à générer de la valeur plus tôt ou de réduire l’investissement. Lorsque les coûts dominent, c’est là que l’accent est mis, mais à mesure que les coûts diminuent et que l’impact des logiciels augmente, l’attention se tourne vers le rendement plus tôt.
À mesure que la technologie a progressé au cours de la dernière décennie, nous avons assisté à une évolution des applications monolithiques vers les microservices et nous assistons maintenant à l’émergence de fonctions pilotées par des événements sans serveur, dirigées par AWS Lambda. Quels facteurs ont conduit cette évolution ? La messagerie à faible latence a permis le passage des monolithes aux microservices, le provisionnement à faible latence a permis le passage à Lambda.
Pour commencer, il y a dix ans, une application monolithique était la meilleure façon de livrer la logique métier, pour les contraintes de l’époque. Ces contraintes ont changé et, il y a environ cinq ans, la meilleure option s’est déplacée vers les microservices. De nouvelles applications ont commencé à être construites sur une architecture de microservices, et au cours des dernières années, les pratiques d’outillage et de développement ont changé pour supporter les microservices.
Aujourd’hui, un autre changement se produit dans les fonctions axées sur les événements – parce que les contraintes sous-jacentes ont changé – les coûts ont diminué et des améliorations radicales du temps de valeur sont possibles.
Dans ce qui suit, nous examinerons en détail différentes dimensions du changement : la technologie de livraison, les capacités matérielles et les pratiques organisationnelles, et nous verrons comment elles se sont combinées pour conduire cette évolution.
Les premiers jours de l’optimisation des processus
Au début de ce voyage, le coût de la livraison a dominé. Il a fallu beaucoup de temps pour se procurer, configurer et déployer du matériel, et les installations de logiciels étaient des projets faits à la main.
Pour optimiser la livraison, la meilleure pratique consistait à amortir ce coût élevé sur une grande quantité de logique métier dans chaque version, et à publier relativement peu fréquemment, avec un délai de mise en valeur mesuré en mois pour de nombreuses organisations. Compte tenu des longs délais pour les modifications de l’infrastructure, il a fallu pré-provisionner des capacités supplémentaires à l’avance, ce qui a entraîné une très faible utilisation moyenne.
Les premières étapes pour réduire les coûts de livraison ont porté sur l’automatisation des processus. De nombreuses entreprises ont développé des scripts personnalisés pour déployer du nouveau matériel, et pour installer et mettre à jour des applications.
Le mouvement DevOps
Finalement, les frameworks communs comme Puppet et Chef sont devenus populaires, et « l’infrastructure en tant que code » a accéléré la livraison des mises à jour. Le mouvement DevOps a commencé lorsque les équipes d’exploitation ont adopté des pratiques de développement de logiciels agiles et ont travaillé en étroite collaboration avec les développeurs pour réduire le délai de mise en valeur de plusieurs mois à quelques jours.
Les scripts peuvent modifier ce qui existe déjà, mais les entreprises à forte croissance ou celles dont la charge de travail est imprévisible ont du mal à provisionner de nouvelles capacités rapidement. L’introduction d’appels d’API libre-service pour provisionner automatiquement la capacité du cloud à l’aide d’Amazon EC2 a résolu ce problème.
Lorsque les développeurs ont eu la possibilité d’automatiser directement de nombreuses tâches d’opérations à l’aide de services Web, une seconde vague de DevOps s’est produite. Les équipes d’exploitation ont créé et géré des plates-formes hautement automatisées reposant sur des API, en plus des services de cloud computing, offrant des déploiements en libre-service et une capacité d’évolution automatique aux équipes de développement.
La possibilité à déployer la capacité juste à temps et à payer à l’heure pour ce qui était réellement nécessaire permettait une utilisation moyenne beaucoup plus élevée et traitait automatiquement les pics de charge de travail inattendus.
L’âge des conteneurs
Une autre vague d’optimisation est arrivée quand le docker a fait des conteneurs assez faciles pour que tout le monde puisse les utiliser. Les conteneurs Docker fournissent un format de package groupé pratique qui inclut un ensemble fixe de dépendances, une exécution plus isolante que les processus, mais inférieure à une instance de machine virtuelle, des temps de démarrage mesurés en secondes et une économie substantielle d’espace mémoire.
En emballant de nombreux conteneurs sur une instance et en arrondissant les temps d’exécution à des minutes ou des secondes au lieu d’heures, une utilisation encore plus élevée est possible. L’outillage de livraison continue basé sur le conteneur a également accéléré le travail des développeurs et réduit le délai de mise en valeur.
Lorsqu’une quantité de travail raisonnablement prévisible arrive, les conteneurs peuvent fonctionner à des niveaux d’utilisation élevés, mais de nombreuses charges de travail sont épineuses ou tombent à zéro pendant de longues périodes. Par exemple, les applications utilisées sur le lieu de travail ne peuvent être actives que pendant 40 des 168 heures de la semaine.
Pour maintenir une haute disponibilité, il est habituel de répartir les instances d’application sur trois zones de disponibilité et même d’exiger plusieurs instances par zone. L’empreinte minimale pour un service est donc de six instances. Si nous voulons réduire à zéro, nous avons besoin d’un moyen de déclencher une partie d’une application lorsqu’un événement se produit, et de la fermer quand c’est fait.
Il s’agit d’un élément clé de la fonctionnalité AWS Lambda, qui transforme les charges de travail épineuses et à faible utilisation en une charge d’utilisation efficace à 100% en ne facturant que la capacité utilisée, par incréments de 0,1 seconde, et évolue de zéro à très haute capacité selon les besoins. Il n’est pas nécessaire de penser à des serveurs de provision ou de les provisionner, et c’est pourquoi on l’appelle souvent le modèle sans serveur.
Les progrès dans la technologie de livraison fournissent des tremplins pour des améliorations dans le temps de la valeur, mais il y a d’autres changements sous-jacents qui ont causé une série de transitions dans les meilleures pratiques au cours de la dernière décennie.
Les progrès de la technologie CPU et réseau
La taille optimale pour un ensemble de logique métier dépend des coûts relatifs en dollars et en temps d’accès des ressources processeur, réseau, mémoire et disque, combinés avec l’objectif de latence pour le service.
Pour le cas courant des utilisateurs finaux humains qui attendent une logique métier pour fournir un service, le temps total requis pour le service n’a pas beaucoup changé. La perception et les attentes n’ont pas changé autant que la technologie sous-jacente au cours de la dernière décennie.
La vitesse du processeur a augmenté assez lentement au cours de la dernière décennie, car la fréquence d’envoi des données (clock rate) atteint sa limite à quelques GHz, mais les caches on-chip sont beaucoup plus grandes, et le nombre de cœurs a augmenté à la place. La vitesse et la taille de la mémoire ont également progressé relativement lentement.
Les réseaux sont maintenant radicalement plus rapides, les déploiements courants sont passés de 1 Go à 10 Go et maintenant à 25 Go, et les protocoles logiciels sont beaucoup plus efficaces. Lorsque la pratique courante consistait à envoyer des charges utiles XML sur des réseaux de 1 Go, la surcharge de communication contraignait la logique métier à être colocalisée dans de grands services monolithiques, directement connectés aux bases de données.
Une décennie plus tard, les codages d’au moins un ordre de grandeur sont plus efficaces sur les réseaux à 25 Gbit, ce qui signifie que le coût de la communication est réduit de plus de deux ordres de grandeur.
En d’autres termes, il est possible d’envoyer de 100 à 1000 messages entre les services dans le même laps de temps que la communication et le traitement d’un message prendraient une dizaine d’années. C’est un outil clé pour abandonner les applications monolithiques.
Avancées dans la technologie de stockage et de base de données
Le stockage et les bases de données ont également connu une révolution au cours de la dernière décennie. Les applications monolithiques mappent leur logique métier aux transactions sur des schémas de base de données relationnelle (SGBDR) complexes, qui lient toutes les tables et permettent des mises à jour atomiques coordonnées.
Il y a une dizaine d’années, la meilleure pratique consistait à implémenter un petit nombre de grandes bases de données relationnelles centralisées connectées via des réseaux de stockage à des baies de disques onéreuses utilisant un disque magnétique, précédées de grandes caches.
Aujourd’hui, les disques magnétiques mis en cache ont été remplacés par des disques à l’état solide. La différence est que les lectures se déplacent de lente, coûteuse et imprévisible – puisque le taux de succès du cache varie – à constamment rapide et presque illimité. Les écritures et les mises à jour passent de rapide pour les disques en cache à imprévisible pour les disques à l’état solide, en raison des algorithmes de nivellement de l’usure et d’autres effets.
Les nouvelles architectures de bases de données “NoSQL” sont devenues populaires pour plusieurs raisons – mais les différences qui nous concernent ici sont qu’elles ont des modèles de schémas simples et tirent profit des caractéristiques du stockage à l’état solide. Les schémas simples forcent la séparation des tables de données qui seraient reliées entre elles dans la même base de données relationnelle, en plusieurs bases de données NoSQL indépendantes, entraînant la décentralisation de la logique métier.
Le service de banque de données Amazon DynamoDB a été conçu dès le début pour s’exécuter uniquement sur un disque à semi-conducteurs, ce qui garantit une faible latence extrêmement constante pour les demandes. Le modèle de stockage d’Apache Cassandra génère un grand nombre de lectures aléatoires et effectue des écritures volumineuses peu fréquentes sans mise à jour, ce qui est idéal pour les disques à l’état solide.
Comparées aux bases de données relationnelles, les bases de données NoSQL fournissent des bases de données simples mais extrêmement rentables, hautement disponibles et évolutives avec une latence très faible. L’augmentation de la popularité des bases de données NoSQL est un autre facteur clé pour abandonner les schémas et les applications monolithiques. Les schémas centraux relationnels restants sont nettoyés, plus faciles à mettre à l’échelle et migrent vers des services tels que RDS et Aurora d’Amazon.
Passer du projet au produit
Il est courant de parler de « personnes, processus et technologie » lorsque nous examinons les changements dans la technologie de l’information. Nous venons de voir comment la technologie a permis de tirer le maximum de l’utilisation et de la vitesse de déploiement avec AWS Lambda, soit une utilisation efficace à 100% pour les déploiements en une fraction de seconde.
Il a également rendu efficace la décomposition de la base de code monolithique en de centaines de microservices et de fonctions, et a dénormalisé le SGBDR monolithique en de nombreuses banques de données relationnelles et NoSQL simples et hautement disponibles.
Il y a également eu d’énormes changements dans les « personnes et les processus » au cours de la dernière décennie. Considérons un monolithe hypothétique construit par 100 développeurs travaillant ensemble. Pour coordonner, gérer les tests et fournir des mises à jour à ce monolithe tous les quelques mois, il est courant d’avoir plus de personnes qui exécutent le processus que d’écrire le code.
Deux fois plus de chefs de projet, testeurs, administrateurs de bases de données, opérateurs etc. organisés en silos, pilotés par des tickets, et une hiérarchie de gestion exigeant que tout le monde rédige des rapports hebdomadaires, assiste à de nombreuses réunions statutaires et trouve du temps pour coder la logique métier réelle !
La combinaison des pratiques DevOps, des architectures de microservices et des déploiements dans le cloud est allée de pair avec les processus de livraison continue, les organisations de « deux équipes de pizzas » basées sur la téléphonie cellulaire, et une forte réduction des tickets, des réunions et des frais de gestion. De petits groupes de développeurs et de chefs de produits codent, testent et déploient indépendamment leurs propres microservices quand ils en ont besoin.
Le ratio des développeurs aux frais généraux inverse – avec 100 développeurs à 50 gestionnaires. Chaque développeur passe moins de temps dans les réunions et attend de billets, obtenant deux fois plus de temps avec un temps cent fois meilleur à évaluer.
Un raccourci commun pour ce changement est un passage de projet à produit. Un grand nombre de chefs de projet sont remplacés par beaucoup moins de chefs de produits. Prenons un exemple un peu artificiel, 150 personnes produisent deux fois plus que 300 personnes. Doublez le retour cent fois plus tôt, sur la moitié de l’investissement. De nombreuses organisations ont fait ce genre de transition et il existe de réels exemples d’améliorations similaires.
Les premiers jours des fonctions
Les applications basées sur Lambda sont construites à partir de fonctions événementielles individuelles qui sont presque entièrement une logique métier – et il y a beaucoup moins de code standard et de plate-forme à gérer. C’est au début, mais cela semble entraîner un autre changement radical.
De petites équipes de développeurs construisent des applications prêtes à la production à partir de zéro en quelques jours. Ils utilisent des fonctions et événements simples et courts pour assembler des stockages de données et des services basés sur l’API robuste. Les applications obtenues sont déjà hautement disponibles et évolutives, très utilisées, peu coûteuses et rapides à déployer.
Comme analogie, pensez combien de temps il faudrait pour faire une maison modèle en commençant par une boule d’argile, comparée à une pile de briques de Lego. Avec suffisamment de temps, vous pouvez presque tout faire à partir de l’argile, c’est expressif, créatif, et il y a même un anti-modèle pour les applications monolithiques appelé la “grosse boule de boue“.
Les briques Lego s’emboîtent pour former une maison modèle contrainte et blocable, qui est également très facile à étendre et à modifier, en un très peu de temps. En outre, il y a d’autres briques comme les briques Lego, mais leur matière de fabrication n’est pas encore connue, et tout type de système basé sur la brique standard sera beaucoup plus rapide que l’argile formée sur mesure.
Si un accroissement de la productivité des développeurs est possible, alors le monolithe de 100 développeurs peut être réécrit de toutes pièces et remplacé par une équipe de dix développeurs en quelques semaines. Même si vous doutez que cela fonctionnerait, c’est une expérience peu coûteuse à essayer. La latence d’invocation pour les fonctions événementielles est l’une des principales contraintes qui limitent les applications complexes, mais avec le temps, ces latences diminuent.
En effet, le seuil de retour sur investissement pour savoir si les applications monolithiques existantes doivent être déplacées inchangées dans le cloud ou réécrites, dépend beaucoup de la quantité de travail nécessaire pour les réécrire. Un centre de données typique à la migration vers le cloud choisirait les applications à fort taux de changement et à grande échelle pour réécrire des monolithes aux microservices, et extraire les petites applications ou les applications gelées intactes.
AWS Lambda change l’équation, et est susceptible d’être la manière par défaut pour construire de nouvelles applications expérimentales, et cela vaut également la peine d’envisager de faire beaucoup plus de réécritures.
