Almost every web application leans heavily on an operating system, a database, and a variety of other lumps of code to get the job done. A modern website reuses millions of lines of code without even trying. Unfortunately, programmers love to avoid repetition, and “Don’t Repeat Yourself” turns into “Always Use an Abstraction”.
By an abstraction, I mean two interlinked things: a idea we can think and reason about, and the way in which we model it inside our programming languages. Abstractions are way of repeating yourself, so that you can change multiple parts of your program in one place. Abstractions allow you to manage cross-cutting changes across your system, or sharing behaviors within it. The problem with always using an abstraction is that you’re preemptively guessing which parts of the codebase need to change together. “Don’t Repeat Yourself” will lead to a rigid, tightly coupled mess of code. Repeating yourself is the best way to discover which abstractions, if any, you actually need. As Sandi Metz put it, “duplication is far cheaper than the wrong abstraction”.
Pragmatisme dans l’usage d’adages de développement. Must read. Ça m’a permis de trouver des mots pour des mauvais usages courants de principes comme DRY.
You would think that this last point might make Cloudflare realise that trying to stop comment spam at the CDN level is a futile idea and can only result in breaking HTTP, but no. What Cloudflare is trying to do here is a fundamentally broken practice (in fact, the whole premise of “web application firewalls” is fundamentally broken, see below) because Cloudflare is not in a position to understand the semantic meaning of HTTP traffic and is definitely not in a position to rearchitect a site operator's web application so that it understands why its own AJAX requests are randomly being denied.
In other words, since CAPTCHAs are discriminatory to robots as discussed above, Cloudflare's service is unwittingly discriminatory to the JavaScript of the very websites it serves, breaking them. Cloudflare's response to this appears to be to CAPTCHA the entire website up-front on the off chance someone might want to post a comment, though even this doesn't always work; I have definitely encountered websites which didn't do so and which had broken AJAX functionality due to the subsequent AJAX-triggered requests being denied by Cloudflare, a condition the JS code was not designed to handle (nor would there be any sane way for it to handle it anyway).
L’extrait en dit déjà pas mal. Le design de Cloudflare est contre-intuitif, et potentiellement nuisible pour les sites qu’il sert.
The bitter nerd. Another default opening position for the nerd is bitterness — the curmudgeon. Your triage: Why can’t he be a team player? There are chronically negative nerds out there, but in my experience with nerd management, it’s more often the case the nerd is bitter because they’ve seen this situation before four times and it’s played out exactly the same way. Each time:
Whenever management feels they’re out of touch, we all get shuttled off to an offsite where we spend two days talking too much and not acting enough.
Nerds aren’t typically bitter; they’re just well informed. Snark from nerds is a leading indicator that I’m wasting their time and when I find it, I ask questions until I understand the inefficiency so I can change it or explain it.
Un article plein d’humour, qui modélise des types de comportements de techos et donne quelques tips de management. Je m’y suis parfois reconnu …
Now, there is a growing awareness of the long-term cost implications of cloud. As the cost of cloud starts to contribute significantly to the total cost of revenue (COR) or cost of goods sold (COGS), some companies have taken the dramatic step of “repatriating” the majority of workloads (as in the example of Dropbox) or in other cases adopting a hybrid approach (as with CrowdStrike and Zscaler). Those who have done this have reported significant cost savings: In 2017, Dropbox detailed in its S-1 a whopping $75M in cumulative savings over the two years prior to IPO due to their infrastructure optimization overhaul, the majority of which entailed repatriating workloads from public cloud.
Yet most companies find it hard to justify moving workloads off the cloud given the sheer magnitude of such efforts, and quite frankly the dominant, somewhat singular, industry narrative that “cloud is great”. (It is, but we need to consider the broader impact, too.) Because when evaluated relative to the scale of potentially lost market capitalization — which we present in this post — the calculus changes. As growth (often) slows with scale, near term efficiency becomes an increasingly key determinant of value in public markets. The excess cost of cloud weighs heavily on market cap by driving lower profit margins.
The point of this post isn’t to argue for repatriation, though; that’s an incredibly complex decision with broad implications that vary company by company. Rather, we take an initial step in understanding just how much market cap is being suppressed by the cloud, so we can help inform the decision-making framework on managing infrastructure as companies scale.
Un article « contre-courant » sur le cloud vs OnPremise. Les chiffres sont assez dingues, mais j’imagine qu’après avoir suffisamment grossi, une entreprise a les moyens pour un shift d’une partie de ses assets OnPremise. Aussi dans l’article, une raison de continuer Kube dans le cloud, mais la raison me parait trop faible face à l’avantage des services managés. Pourquoi s’embêter à maintenir un Kube dans la phase de scaling dans le cloud quand de toute façon la culture d’infra devra basculer au moment de switcher OnPrem ? D’autant qu’au moment du scaling biz ça me parait plus important de focus sur la prise de masse que l’économie d’infra. La préparation la plus évidente reste d’avoir containerisé, et je pense qu’elle suffit jusqu’au besoin de bascule. Qu’en pensez-vous ?
