Pourquoi une approche par application des services applicatifs est importante
Je ne peux pas lire dans les pensées (mes enfants ne seraient pas d’accord, mais ce n’est pas le cas), mais je peux lire les réponses à notre enquête sur l’état de la mise en œuvre des applications. Et lorsque je les lis à travers le prisme de développeurs d’applications autoproclamés, je vois émerger une image très intéressante.
Les développeurs se soucient de la vitesse. Et la sécurité. Et l'échelle. Pas nécessairement dans cet ordre, mais ils se soucient des trois. Non seulement ils s’en soucient, mais ils reconnaissent la valeur des services d’application pour les aider à atteindre ces trois objectifs.
En d'autres termes, les développeurs ne veulent pas seulement des services d'application « d'accélération » vagues, ils veulent des services spécifiques qui fournissent des optimisations TCP et la mise en cache. Ils veulent un pare-feu d'application Web et, en plus, un certain équilibrage de charge.
Le problème est que la plupart de ces services d’application sont fournis dans un modèle d’infrastructure partagée. Chaque application dispose de sa propre « représentation virtuelle », mais elle réside physiquement sur un logiciel ou un matériel partagé.
Cela peut entraîner de réels problèmes et constitue en partie une source de frictions qui subsistent entre l’informatique et le développement d’applications. C’est cette nature partagée des systèmes qui nous a apporté des fenêtres de changement, des tableaux d’évaluation et des déploiements du samedi soir (avec de la pizza, pour nous apaiser) – les processus qui ralentissent le développement et font du déploiement une expérience frustrante pour toutes les personnes impliquées.
Nous ne déployons plus d’applications monolithiques. Même si nous n'avons pas adopté les microservices de manière maniaque et décomposé les applications en centaines de petits services, nous avons toujours davantage d'applications qui sont soumises à des calendriers de déploiement plus fréquents. Applications développées en sprints d'une semaine plutôt qu'en projets d'un an, et qui nécessitent des mises à jour plus rapides et plus fréquentes.
C’est en fin de compte la raison pour laquelle le cloud (public) a connu un tel succès. Parce que c'est mon application et mon infrastructure et que je n'ai pas besoin d'attendre Bob, Alice ou John avant de lancer une mise à jour. Parce que tout est à moi, et si ça tourne mal, c'est de ma faute.
Cette même approche est également possible (et préférable, je pense) sur site. Ce qui est nécessaire, c’est que tous les éléments qui composent la chaîne de livraison d’une application prennent en charge le même type d’approche par application que le cloud a rendu souhaitable.
Fondamentalement, une approche par application pour fournir les services réseau et applicatifs nécessaires s’apparente à la dédicace d’un sous-réseau à l’application ; un VLAN de livraison d’applications, en quelque sorte. Tout est question d’une seule application, avec des services dédiés.
Ce type d’isolement est non seulement bénéfique pour les calendriers de déploiement, mais également pour tout le monde. L'échec se produit, et lorsqu'il se produit, vous souhaitez limiter le rayon de l'explosion autant que possible. Les architectures par application impliquent un impact de panne étroitement limité, ce qui rend toutes ces personnes de garde « au cas où » heureuses car elles n’ont pas reçu cet appel. Je peux publier et déployer chaque semaine sans entrer en conflit avec les applications qui publient et déploient une fois par mois. Mon application, mes services, mon planning de déploiement.
Une architecture par application facilite également la résolution des problèmes qui surviennent en production. Et c’est souvent le cas. En fait, 50 % des développeurs ont signalé des problèmes de production après la publication du code dans une enquête Atlassian de 2017 . Il n’y a aucune chance que quelqu’un d’autre ait apporté une modification qui pourrait avoir un impact sur l’application. Vous pouvez accéder directement aux systèmes concernés plutôt que de perdre un temps précieux à déterminer quels systèmes pourraient être impliqués.
Une architecture par application s’adapte naturellement mieux au cloud, qu’il soit public ou privé, car c’est l’hypothèse posée par le modèle. Chaque application dispose d'un ensemble dédié de services d'application pour la faire évoluer, l'accélérer et la sécuriser.
La réalité est qu’une architecture par application était inévitable. Ce n'est pas la première fois que je dis ça . La gravité des applications est trop forte pour être ignorée, et la sécurité de plus en plus spécifique à chaque application nécessaire pour assurer sa sécurité signifiait qu'une approche par application allait arriver tôt ou tard.
Et c’est une bonne chose, car les services d’application que les développeurs souhaitent sont, le plus souvent, spécifiques à l’application. Ce qui fonctionne pour l’un ne fonctionnera pas forcément pour l’autre – et peut même être négatif. En adoptant une approche architecturale par application pour la livraison d'applications, vous pouvez garantir que les développeurs obtiennent non seulement ce qu'ils veulent et ce dont ils ont besoin pour faire évoluer, sécuriser et accélérer les applications, mais vous pouvez également mieux prendre en charge le modèle de libre-service qu'ils attendent du cloud, que ce soit sur site ou hors ligne.