(English follows)

De nos jours, le terme DevOps est partout. C’est le petit nouveau, la nouvelle star, dans toutes les entreprises technologiques. Avec des concepts de bases qui sont des piliers avérés d’une bonne culture d’ingénierie (équipes pluridisciplinaires, systèmes à flux tiré, transfert de connaissances à l’échelle et hyper-collaboration), il ne s’agit pas d’une surprise que les principes derrière ce « buzzword » font énormément de sens lorsque votre marché niche est la livraison logicielle et que vous ne vivez pas dans l’âge de pierre.

J’aimerais tout d’abord partager mon opinion sur un aspect particulier de ce nouveau désir des entreprises à « adopter le DevOps ». Le sujet émerge souvent lors de discussions entourant le délai de mise en marché. C’est par contre ce que j’aime appeler un morceau de licorne.

La licorne est un rêve. C’est l’accomplissement ultime d’une idée ou d’un produit. C’est, par exemple, le but ultime d’Elon Musk et de sa révolution spatiale : coloniser Mars. Nous savons tous que ce n’est pas impossible, mais nous ne savons pas à quel point cette réalité est loin de la nôtre. Nous ne savons même pas par quel chemin y parvenir.

Un morceau de licorne, c’est une miette de cet objectif que nous adorons contempler. C’est le vaisseau qui nous amènera sur Mars. C’est un objectif qui nous semble plus atteignable dans un futur proche.

Le morceau de licorne sur lequel les entreprises semblent fantasmer lorsqu’elles parlent de DevOps est le déploiement en continu. J’entends souvent : « Savais-tu que Netflix publie des changements en production des MILLIERS de fois par jour? » Honnêtement, qui n’aimerait pas en faire autant?

Alors, pourquoi les entreprises veulent atteindre cet objectif? Parce que ça semble un accomplissement impressionnant. Mais au-delà de la vanité, est-ce que la vraie raison ne devrait pas être : « parce qu’un très court délai de mise en marché est un avantage économique puissant »?

Imaginons un instant que nous vivions dans un monde merveilleux, où par un pouvoir incroyable, nous pouvons publier des changements en production à n’importe quel moment. J’agite ma baguette magique et en un instant, votre processus complet de déploiement, incluant les essais de qualité, est complètement automatisé et très facile d’utilisation. Regardez maintenant votre tableau de bord attentivement, vous devriez voir apparaître les premières livraisons d’une seconde à l’autre.

Rien.

Attendez, il y a sûrement une erreur, regardez encore un peu.

Toujours rien.

Parmi vos équipes, laquelle a le temps de cycle le plus bas? En d’autres termes, combien de temps votre équipe la plus rapide prend pour livrer une fonctionnalité au point d’être prête à publier en production?

Si vous avez plusieurs équipes qui ont toutes des temps de cycle relativement bas, disons une semaine, alors probablement que vous verrez quelques changements apparaître en production à chaque semaine. Si leurs performances sont moindres, vous devrez prendre votre mal en patience. À moins d’avoir des temps de cycle extrêmement bas, vous verrez rapidement que ce pouvoir magique n’était pas si utile que ça tout compte fait.

Mais est-ce à dire que le déploiement en continu ne fait aucun sens? Voyons un peu le problème sur un angle économique. Le déploiement en continu abaisse le coût de déploiement (coût de transaction) à presque zéro. Dans le monde réel, l’implémentation du déploiement en continu est rarement simple. Les entreprises tendent alors à débuter leur chemin de croix par un focus accru sur la réduction de la taille des lots. En théorie, c’est un excellent premier pas qui devrait nous amener au bout du voyage.

De plus petits lots sont plus faciles à réaliser, donc ils coûtent moins cher. Nous déployons plus fréquemment, et ce faisant, nous augmentons notre expertise en déploiement rapide, ce qui veut dire plus simple et moins coûteux.

Il s’agit donc d’une amélioration, mais le jeu en vaut-il la chandelle? À réduire la taille du lot, vous pourriez aussi bien vous retrouver dans une situation où le coût d’implémentation de vos déploiements en continu dépasse largement la valeur qu’ils apportent.

Si vous voulez vraiment réduire votre temps d’atteinte du marché, vous devriez plutôt garder le focus sur le flux de travail complet, du début à la fin de votre cycle de développement. Améliorez seulement la queue du cheval et il ne courra pas plus vite.

Examinons un peu ces trois variables :

• Taille du lot (batch size);
• Coût de ne pas avoir la fonctionnalité (holding cost);
• Coût de livraison (transaction cost).

À moins d’avoir vraiment une baguette magique ou d’avoir déjà payé le coût d’implémentation du déploiement en continu, on observe plus souvent qu’autrement une situation où le plus de valeur se situe dans un compromis.

Bon, vous ne devriez quand même pas prendre une décision sur la simple base de ce graphique. Ceci n’est après tout qu’un article de blogue! Vous auriez par contre avantage à prendre les mesures dans votre contexte et baser vos décisions sur de vraies données. Acceptez l’évolution et améliorez-vous en expérimentant, pas simplement sur le fait que vous voulez impressionner vos amis! Comme le dit si bien Adam Savage (mon Mythbuster préféré) : « Rappelez-vous les enfants, la seule différence entre faire des bêtises et la science est de l’écrire ». Si vos mesures indiquent que de petits lots font du sens dans votre contexte, allez-y!

En gros, vous devriez fixer votre fréquence de livraison en fonction de la valeur des éléments à livrer, de vos temps de cycle bout en bout et du coût total de la réalisation d’un déploiement (incluant la coordination).

Si votre goulot d’étranglement n’est pas au niveau de votre processus de déploiement, vous devriez commencer par adresser les goulots dans votre flux de production de valeur. Admettons que votre goulot se trouve au niveau de votre processus de déploiement, c’est probablement le meilleur endroit pour un goulot. Est-ce que ça veut dire que vous devez arrêter de vous améliorer? Loin de là, vous devriez simplement garder en tête que vous devez améliorer les performances du système au complet.

Ne vous détrompez pas, tout ce qui vient du monde DevOps est normalement très cool et vous devriez vous y intéresser. Demandez-vous simplement si vous connaissez suffisamment la nature et l’endroit de vos goulots. Maintenant, quel est le meilleur endroit pour commencer à vous améliorer?

—

Continuous deployment : the unicorn of DevOps

The word DevOps is everywhere. It’s the absolute new kid on the block in every tech organisation. With concepts that were already proven to be pillars of good engineering culture, like strong cross functional teams, pull systems, wider knowledge spread throughout the workforce and hyper collaboration, it’s no surprise that the principles behind our new favorite buzzword make a lot of sense when you are delivering software and happen not to live in the Stone Age.

I want to share my thoughts on a particular side of this new need a lot of businesses seem to have with “moving to DevOps”. It is often discussed when someone is pitching the idea. It’s what I like to call : “ a piece of unicorn”.

A unicorn is a dream. It’s the ultimate pinnacle of an idea or a product. It’s the ultimate goal of Elon’s Musk’s revolution to space travel : to colonize Mars. We know it’s not impossible and acknowledge how far fetched it is from our reality and how “that would be the ultimate goal, but we’re not shooting for that in the short term”.

A piece of unicorn is just what it sounds like, a part of this unicorn we love to look at. It’s the spaceship that’ll bring humans to Mars in Musk’s genius unicorn plan, something somewhat more achievable in the near future.

The piece of unicorn I see business fantasize about when talking DevOps is continuous deployment. I often hear : “Did you know that Netflix pushes changes to productions THOUSANDS of times per day?!” Why is this the part we are most impressed with? It sure is an awesome feat, who wouldn’t love to be able to do the same?

So, why? Probably because it looks impressive. Deep down, the real reason should be: “Because a short time to market can be a very strong economical advantage.”

Let’s play a game and say that we live in a fantasy world where, with some magical power, I can enable you to push changes to production at any rate you want. I would just move some magical wand and your whole deployment process, including QA, would be fully automated and easy to use. We would surely look at your dashboard and start to see rolling changes to production? Nothing. Let’s wait a bit more. Anything?

What is the lowest cycle time of any of your team? In other words, how many times your fastest team can be done with a feature to the point where it’s ready for release? If you have multiple teams pushing features and they all have relatively low cycle time, let’s say a week, then maybe yes, you’ll see a couple of changes pushed to production per week. If it’s longer, or you have less teams, it will be longer. Unless you have teams with very low cycle times, you will soon notice that this magical power was not that useful and that you are far from actually having continuous deployment as a real need.

Don’t get me wrong, continuous deployment has a lot of economical value. It enables you to bring the costs of actually releasing, or the transaction cost, virtually to zero. In the real world, implementing continuous deployment is rarely an easy feat, so businesses tend to start by focussing on smaller batch size. In theory it might makes sense, because it seems like a reinforcement loop, and it probably is. The reasoning being that smaller releases are easier to execute, so they cost less. Smaller releases call for a higher deployment frequency, which means teams master the process faster, releases are easier to execute, so they cost less.

However, like with any other improvement : make decisions based on facts. Don’t make the mistake of blindly taking the route of reducing batch size without measuring, or else you might find out too late that the cost of reducing the size of your deployments and eventually implementing continuous deployment is higher than the value it provides.

If you want to shorten your time-to-market, you need to focus on flow from the start of your development cycle to the end of it. Focusing on reducing the size of your releases without having a very low cycle time has little to no value, because you likely don’t have this need yet.

Let’s break it down to three variables :

• Batch size : the size of the batch being released;
• Holding cost : the cost of not having the features released at a given time;
• Transaction cost : what it costs to do the actual delivery.

Unless you’ve got yourself a magical wand, or have already paid the cost of implementing continuous deployment therefore driving transaction cost close to zero, we can often observe a situation where the most value is within some kind of middle ground, like this :

Now you shouldn’t make any decisions based on this graph, this is just some blog post. Measure those and make decisions based on real data, evolve and improve by experimentation, not by “guesstimation” or “what would be impressive”, and always remember Mythbuster’s Adam Savage’s wise words : “Remember kids, the only difference between screwing around and science is writing it down”. If your metrics say very small batch size are the way to go, then by all means, find a way to reduce it. If you find out that it does not make economical sense to reduce batch size, focus on optimizing value delivery and flow upstream of the deployment process. If you are already focusing on those areas, then take a look at transaction cost and holding cost and try to optimize for total cost.

In other words : is your release process your actual bottleneck? If it is not, you should work on other areas of your value delivery pipeline first. If it is, then you should ask yourself if having a bottleneck at the end of a system is a bad thing. It probably is the best spot to have a bottleneck. Does that mean you should not improve on this area? Of course not! It only means you should be careful to improve the flow throughout the whole system. In other words, keep the bottleneck at the end of the hose, but make sure it is large enough so that water can flow.

If you end up with a big large enough hose that you need continuous deployment tools to get that water out, then you should shop for new techs to help you do that, and perhaps Googling the word “DevOps tools” can point you to the right tech.

Don’t get me wrong, DevOps is usually pretty cool and you should do it. Just ask yourself first if you know enough about your process bottlenecks. Now, where is the best place to start?