Vous êtes plutôt LEGO, MECCANO ou KAPLA ?

Mon rôle de “solutions architect” est d’expliquer à mes interlocuteurs comment utiliser le mieux possible la plateforme cloud d’Amazon Web Services, pour que la solution soit performante, moins coûteuse, sécurisée, évolutive, et simple à gérer pour le client. Parmi les nombreux arguments que nous utilisons régulièrement, nous mettons en avant la richesse de l’offre de services d’AWS, et sur le fait qu’au-delà de répondre à des besoins immédiats, choisir AWS signifie également faire le choix de briques de constructions variées, à l’état de l’art, avec régulièrement de nouveaux services. Dans ce cadre, j’aime bien employer l’image de la boîte de LEGO à partir de laquelle on construit son système d’information. On peut aussi poursuivre un peu cette métaphore.

Un ensemble de services adaptés à tous les besoins

Avec des LEGO, on peut aussi bien fabriquer des petits et des gros camions

Les briques de construction d’AWS sont adaptées aussi bien pour des applications simples, ou pour des petits acteurs qui ont des moyens limités (le petit camion de gauche), que pour des applications complexes, avec des acteurs qui assemblent de nombreuses briques pour atteindre leurs objectifs. Tout le monde peut profiter de la qualité, de la performance de chacune des briques, quel que soit l’enjeu. C’est ainsi qu’on trouvera, parmi nos clients, des petites associations qui hébergent leur site internet via lightsail, ou des multinationales qui hébergent leurs systèmes d’information critiques. Tous bénéficient de la même qualité des briques de construction, pour des objectifs différents.

Choisir son cloud provider, ce n’est pas anodin !

On ne fait pas la même chose avec des LEGO, des MECCANO ou des KAPLA

Vous n’avez pas la même liberté, la même facilité et vous n’atteignez pas le même résultat si vous fabriquez votre camion avec des LEGO, des MECCANO ou des KAPLA. Choisir son cloud provider, c’est choisir l’ensemble de briques avec lesquelles vous voulez construire votre système d’information, le choix est donc structurant sur la diversité des éléments, sur la façon d’assembler les éléments, sur la solidité et la performance du montage final.

Le multicloud, ça peut être bancal !

Quand on mélange des LEGO et des MECCANO dans la même construction, ça donne un résultat bizarre

Mélanger des LEGO et des MECCANO, c’est possible, mais ce n’est pas simple, c’est contraignant pour assembler les pièces, et le résultat n’est pas très satisfaisant. De la même manière, monter des architectures basées sur plusieurs fournisseurs du cloud, c’est possible. Mais c’est compliqué, contraignant, et gare à ne pas faire n’importe quoi, à défaut de quoi le système construit ne fonctionnera pas bien. L’idée complémentaire, c’est que les services d’un fournisseur et d’un autre ne sont pas superposables, et se limiter à ceux qui sont similaires et compatibles ne permet pas de faire énormément de choses. Bref, faire le choix du multi-cloud, c’est ajouter une contrainte supplémentaire là où en réalité l’idée initiale, c’est de libérer la capacité d’innovation et libérer les contraintes.

Si vous avez d’autres idées pour poursuivre cette analogie des services AWS et des briques de construction, n’hésitez pas à les partager avec moi !

PS : Merci à mes enfants qui m’ont gentiment prêté leurs jouets, même s’ils se demandent encore ce que je peux bien faire avec les photos que j’ai prises…