Egy újszülöttnek minden vicc új, így én a régi viccekre szakosodtam, azokat mondom el újra és újra.

Floorshrink diaries

Floorshrink diaries

Horseshoe bend #1 – the Why

2022. június 19. - Floorshrink

horseshoe_bend.jpg

The World is full of natural wonders that are photographed in each and every minute. The bend of the Colorado river near Page is one of them. As an amateur photographer I took my own version. (don’t go in January, that is snow in the upper left corner…) Somebody also writes an article about the public cloud in every minute, so investing effort in writing the N+1st version carries as much novelty as the picture above. The sinister #1 forecasts the fact that my content does not fit in a single article, therefore it will arrive in small chunks just like the coffeehouse novels of the 1930s. Despite of this I hope that whoever invests a few minutes reading this piece, will profit from it.

Why this cloudy thing is relevant?

  • The strongest argument is bridging the ch asm between the demand by the developers (and the business behind them) to follow a zigzag path (a.k.a. going agile) and the current capability of the on prem IT infrastructure to satisfy this demand. The business wants to experiment, ever faster and of course at the lowest possible cost, while on prem IT still thinks in annual budget cycles, where rolling out a new piece of hardware takes 3-4 months from the approval. (if we consider the current chip shortage, it is easily over 5 months)
  • There are usually two complaints about IT infrastructures beyond stability: it takes ages to grow and it cannot scale down, ie. this is rigid. Originally, I drew the chart below as a fun fact to illustrate my point in a discussion with an executive: the development of IT infrastructure - beyond brute force power increase - is the capability to follow an arbitrary demand curve with an increasingly precise answer. (in the good old integral term limes delta t = 0) One of the advantages of the public cloud is the capability to support both the dynamically scaleable technology (microservices in containers) AND the tooling that can automatically provision and manage it. (aka. Infrastructure as a Code)

delta_t_tart_nullahoz.jpg

  • A colleague of mine once argued against the public cloud that since everything is changing so fast (COVID, the war in Ukraine, the looming recession, the growing inflation), one cannot plan even for 3 years, therefore we are at leisure to think about it for a few more years. While the reasoning is correct, the statement it is trying to support is dead wrong: this very unpredictability demands the ability to change direction fast. And the public cloud does exactly this: to be prepared for the unknown. It happens that a republic (“United forever in friendship and labour, Our mighty republics will ever endure.” Aha..) batters down its little brother because it dared to venture too close to countries not loved by the big brother. The Ukrainian National Bank screw around the public cloud topic for over ten years, then suddenly approved its use to banks within a week in this March. There are times when one needs to be fast.
  • My last argument: the bulk of technology innovation shows up lately in the marketplaces of the major cloud providers, aka. “cloud first”. I think we are not too far from the era when it will switch to “cloud only”. The functionality gap between the cloud and on prem version of the same product is widening every year, first there is the honey on the rope, then comes the stick (sorry dudes, this is deprecated, you have no choice.)

The rational of the deniers – a bit tousled

For the full picture we need to discuss the arguments of the naysayers.

  • “We can do the same thing on prem!” This is true that any technological advancement and process innovation can be copied and implemented in an on prem environment. I am almost as good looking as Thor, I all need to do is just a bit more exercise and I will be there in no time.
    An average hyperscale cloud provider can enumerate more SW engineers to this task that most Hungarian enterprises combined. If we accept the theory that eg. Microsoft allocates its resources to a product line based on its revenue potential AND we take into consideration that MS has roughly 160 thousand employees AND Azure was behind 22 billion USD out of the 168 billion total revenue last year, then it is fair to estimate that cca. 21 thousand people at MS are working on Azure day after day. At least one third of this army are developers with technical leaders like Mark Russinovich. This is darn hard to win this race against MS (or AWS for that matter), We should compete somewhere else.
  • “You did not have to wait for the infrastructure, this was the business messing around wasting time.”
    • In enterprise IT it takes several months from request to fulfillment to serve an infrastructure demand WHEN the hardware was already in the data center at the time of the request. If procurement starts its “Speedy Gonsales” process AFTER the demand arrived, we are talking about at least 6 months.
    • If we replace the term “fidgeting” with experimenting, then we have to accept that the business sometimes does follow a zig-zag path. Although the expression is a bit overused this is still true: the business wants to be agile, it will place its bets on multiple things, it will change its mind and sometimes will make mistakes. The best supporter to “fail fast” and “fail cheap” is the public cloud.
  • „The cloud is expensive!” – There is a large amount of truth in this statement. When used in earnest cloud services can be pretty expensive. On the other hand this statement is misleading for the following reasons::
    • The cost of on prem infrastructures is a flat fee in nature regardless the utilization of it. For the record: an average on prem enterprise IT infra runs with the efficiency of a steam engine, a Diesel engine at best. This means that it uses 20% of its capacity while you had to pay for 100%. On the other hand cloud services pricing is consumption based, ie. it will cost you dearly if you leave the lights on when not needed. Generations of IT folks grew up on the mantra that leaving the light on was okay or even a good thing since it gave a timeslot to those maintenance scripts or patches that ran throughout the night. We will need to override decade old reflexes.
    • Most enterprises carry a huge amount of technical debt and controlling departments do not even try to estimate the hidden cost of this fact. (If we draw a analogy between tech. debt and financial debt, then this becomes clear that the “interest” on this technical debt is the firm’s slower reaction to change.) If you can reduce your technical debt by using the public cloud, it will make your company go faster that is worth some money. This is the benefit that you never take into account when examining the cost of the cloud.
    • Most large enterprises cannot tell how much a given IT service exactly cost them. (true respect to those few who can.) (This is the equation that is hard to solve: ∑ i= 1 to N for all items in IT service portfolio (unit price x number of units consumed) = total IT cost) We know the prices of the cloud services, but the on prem service prices are smudged and distorted in the big common hat. It may even happen that cost transparency backfires, when the on prem folks will claim “more expensive” discretely hiding the fact they do not even know how much their stuff costs.
  • The cloud is not secure – Please put the „Common vulnerabilities in Java” string in your (Google) search window. Then, if you are not nervous enough yet, replace the Java part with dotNet, then with your favorite (mobile) OS etc.etc. How long did it take you to fix all vulnerabilities related to log4j or Heartbleed? The question is NOT that you are vulnerable or not but how long it will take to realize that you are hacked and to do something against it. I do not want to understate this topic; the last really trustworthy firewall was the two-inch airgap. I want to point out that the cloud is as vulnerable as your on prem infrastructure, and there is a chance that there are more and better trained ITSec engineers attempting to reduce the risk than in your on prem environment. Of course this is an entirely different coup of tee when the service provider (or the state) itself wants to look into your data.
  • You cannot use the cloud because of compliance requirements – to meet the requirements of PCI-DSS (Payment Card Industry Data Security Standard), SOC 2 (System and Organization Controls 2), HIPAA ( Health Insurance Portability and Accountability Act), ISO 27001 etc. is a daunting task indeed. This is so funny to hear this excuse from IT people of firms that can satisfy none of the standards above, furthermore this is not even in their plans to pull this trick. Large cloud players have done it years ago and can withstand the endoscopy of auditors on an annual basis.

Summary – what comes after the curve in the road?

IT infrastructure is becoming a commodity. This commodity is indispensable to our survival (in case of banks to the very existence), but does not bring a sustained competitive advantage compared to others who also use this technology.

The cloud, like many other technological advancements before brings something new that previous technologies could not do and this will change the rules of the game. The question is whether an enterprise can still benefit from cultivating an on prem IT infrastructure and if an on prem IT can compete with the capabilities of the hyperscale cloud providers. The answer to the first question is a possible yes, to the second one a definite no. As we know from Niels Bohr prediction is difficult especially when this is about the future, but I give it a try.

The balance (between on prem and cloud) will be influenced by the business goals of the firm (a mom-and-pop shop vs. a multinational trying to conquer the globe), the playground defined by the regulators, the sensitivity of data handled and the optimum between cost and speed.  It will vary between industries and company segments. The less legacy you carry (eg. a startup) and the further you are from the heavily regulated industries (ie. not a government) the more likely that the only on prem HW equipment you will end up with are a coffee machine and a photocopier within a few years. If you have hundreds of legacy (on prem) applications, and you are heavily regulated, chances are the balance will be around a 65-75% on prem vs.  25-35% cloud.

A bejegyzés trackback címe:

https://floorshrink.blog.hu/api/trackback/id/tr8517861895

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása