Z czym do chmury?

Data: 2020-01-09
Autor: Sebastian Konkol
Z czym do chmury?

„Cloud, czy on-premises” wchodzi już na stałe do kanonu procesów decyzyjnych o sposobie realizacji przedsięwzięć informatycznych. Na szczęście mamy już za sobą czasy naiwnego rachunku kosztów i dysponujemy doświadczeniem pozwalającym na znacznie głębsze zrozumienie mechanizmów związanych z ekonomiką rozwiązań chmurowych i skutkujących racjonalizacją kosztów posiadania informatyki.

Chmura wychodzi taniej, ale nie dlatego, że możemy to w łatwy sposób porównać – wyliczenia, choć złożone, są pozytywne. Podstawowym powodem osiągania lepszych współczynników finansowych w realizacji rozwiązań opartych o chmurę jest fakt, że finanse wbudowane są w fundamenty architektury takich rozwiązań i dzięki temu tamują „wodotryski” i „specyficzność”. Jak to działa? Nie znam wszystkich tych mechanizmów, ale mogę zobrazować kilkoma przykładami.

Przykład 1. W praktyce działań składałem usługi chmurowe na AWS, czy na Azure. Kiedy konfigurujemy usługowy ekwiwalent infrastruktury (IaaS), już w samej definicji takiej usługi dostrzegamy możliwości optymalizacji kosztów (np. ograniczenie godzin dostępności infrastruktury, wyłączanie maszyn wirtualnych, automatyczne skalowanie w górę i w dół). Każda taka operacja obniża rachunek za użytkowanie usługi w chmurze. Kto jednak wyłącza na noc maszyny wirtualne we własnej serwerowni, żeby zaoszczędzić na prądzie i klimatyzacji?

Przykład 2. Wykonywanie kodu dowolnej usługi czy aplikacji w chmurze jest rozliczane za czas procesora. Programista dostaje narzędzia klasy profiler, aby móc zoptymalizować kod pod kątem wymaganej mocy obliczeniowej – używając ich obniża późniejsze koszty działania aplikacji. A kiedy tworzymy kod dla aplikacji pracujących on-premises, kto optymalizuje kod pod kątem użycia zasobów? Przecież wiadro procesorów jest tańsze, niż czas programisty, testera i wdrożeniowca.

Przykład 3. W ramach jednego ze spotkań Cloud Challengers, w ramach fantastycznej przygody pod nazwą FutuRentals, śledziłem historię wytworzenia startupu technologicznego. Jak to w startupie, wiedza o kosztach, które „mogą zabić” to wiedza kluczowa. Jednym z takich elementów dla FutuRentals, z racji potencjalnego kosmicznego skoku popularności, była skala operacji na bazie danych wzrastająca silniej niż wykładniczo. Eliminacją takiego ryzyka okazało się przejście na działania na bazie danych realizowane wsadowo – koszty takich operacji rosły liniowo ze wzrostem skali działania. W przypadku tworzenia rozwiązań on-premises, kto zastanawia się nad trybem zapisywania danych w bazie danych, żeby ją odciążyć? Nie tylko nie patrzymy na wskaźniki kosztu na takim poziomie szczegółów, ale nie mamy nawet szansy posiadać takich oszacowań.

Jak widać z powyższych przykładów, o raczej fundamentalnym charakterze, chmura promuje praktyki, które – choć dostępne także dla rozwiązań on-premises – nie są włączane do codziennych działań informatyki w większości ze znanych mi firm. Ale to nie koniec.

Inna perspektywa dotyczy wykorzystania gotowych rozwiązań chmurowych. W takich przypadkach użytkowany jest SaaS w jak najbardziej standardowej postaci, bo dzięki ekonomii skali koszty użytkowania takich systemów (np. Salesforce, Google Apps, Success Factors) stają się bardzo rozsądne. Taki efekt nie ogranicza się jednak do SaaS. Nieco paradoksalnie, korzystanie z chmury, powodujące standaryzację w oparciu o technologie jednego dostawcy usług chmurowych, skutkuje konsolidacją zakupów u tego dostawcy (rozważania ryzyka odłóżmy na bok). Stajemy się więc beneficjentami standaryzacji wykonywanej dla nas przez dostawcę usług chmurowych.

Jeszcze inna perspektywa zasadza się na budowaniu całych ekosystemów zapewniających dostęp do nieskończonej puli komponentów dostarczanych przez niezależnych dostawców. Wymaga to narzucenia silnych standardów (sic!) opierających się na rozwiązaniach promujących reużycie (np. AWS Lambda). Skoro reużycie, to także korzystanie z rozwiązań niszowych, których samodzielne zbudowanie byłoby absurdalnie kosztowne, czy też możliwość podmiany użytkowanego rozwiązania konkurencyjnym.

Widać więc jasno, że w przypadku chmury standaryzacja i wynikający z niej ekonomiczny efekt skali nie są już (i nigdy już nie będą) celem czy dążeniem. Są one po prostu podstawą konstrukcji rozwiązań.

Na koniec jeszcze jeden, nieoczywisty efekt ekonomiczny. Kto liczy zużycie energii elektrycznej na zasilanie serwerowni czy jej klimatyzację? To nie są popularne metryki, jednak współczynniki sprawności energetycznej (PUE, Power Usage Effectiveness) są absolutną podstawą dla racjonalizacji kosztów. Dla nowoczesnych chmur publicznych wartości tych wskaźników lokują się w okolicach 1,1 i nawet poniżej, podczas gdy dostępne komercyjnie kolokacje osiągają wartości na poziomie 1,3 czy nawet 1,4, a i tak są to wartości nieosiągalne dla własnych centrów przetwarzania danych. Dla uzmysłowienia, koszt zasilania i klimatyzacji to ok. 40% całości wydatków na posiadanie data centre, a produkcja energii elektrycznej stała się tak poważnym zagadnieniem politycznym, że dostawcy usług chmurowych budują wręcz własne elektrownie oparte na źródłach odnawialnych. I są w tym wyścigu absolutną awangardą.

Do tego dochodzą przyziemne aspekty O&M, jak wspólny, po prostu działający monitoring dla całości usług, ułatwienia zarządzania całością środowiska i automatyzacji tych operacji, czy obniżenie kosztów „ubezpieczenia od poważnych awarii” (możliwość odtworzenia całego data centre na drugim końcu świata) i wiele innych.

Ergo, obniżanie całości TCO – jak chyba w żadnym wcześniejszym przypadku – jest realizowane nie tylko przez odbiorcę rozwiązań informatyki, ale także przez dostawcę, który zaczyna wręcz narzucać (sic!) metody skutecznego obniżania TCO dla odbiorcy.

Wiemy, że istnienie chmury wprowadza zmiany w niemalże każdym obszarze posiadania technologii informatycznych, zmienia także w sferze finansów. Zmiany te wnikają jednak tak głęboko w merytorykę prac, że nie można tworzyć rozwiązań pomijając ten element. Architekt musi więc stać się także specjalistą od inżynierii finansowej w swoim obszarze działania – to architekt może wprowadzić największe oszczędności w sposobie tworzenia rozwiązań. Nie uciekniemy od tego, a wręcz zachęcam do zorientowania na takie zagadnienia, bo – z moich doświadczeń – zdolność do racjonalizacji kosztów posiadania informatyki będzie stanowić o sukcesie rynkowym przedsięwzięć biznesowych.

Witaj, Cloud Economy!

komentarze 2 dla

  1. Szymon pisze:

    Pozwolę sobie zacytować “Kto liczy zużycie energii elektrycznej na zasilanie serwerowni czy jej klimatyzację”. No to niby patrzymy na koszta czy nie? Energia elektryczna jest bardzo dużym obciążeniem finansowym, i zawsze powinniśmy ją uwzględniać. Dlatego, też tworzymy energooszczędne procesory. Cały ten i inne artykuły to są kompletne brednie. Idziemy dalej -> “automatyczne skalowanie w górę i w dół”. Przychodzą święta i ruch na stronie wzrasta o 400%. Szybciej jest wyskalować maszynę czy dokupić serwer? a co po świętach? Będziemy utrzymywać bez sensu serwery, które cały czas działają, ponieważ znowu cytując “Kto jednak wyłącza na noc maszyny wirtualne we własnej serwerowni, żeby zaoszczędzić na prądzie i klimatyzacji”. Zaprzecza Pan sobie sam w 2 akapitach. Artykuły te są całkowicie bez sensu i pokazują zakłamaną rzeczywistość. OnPrem jak i chmura mają swoje wady i zalety, lecz w tych artykułach tego się nie dowiemy. Doceniam i szanuję zaangażowanie, lecz osobiście uważam, że całość tutaj przedstawiona nie nadaje się całkowicie na bloga.

  2. Dziękuję za zaangażowanie w lekturę i ten komentarz. Ma Pan prawo do swojej opinii, a ja do formułowania swojej. I to jest cudowne, że możemy się tak pięknie różnić. Także w zakresie “wystawiania ocen”.
    Staram się pisać prościej, ale nie mogę podkreślać wężykiem – sarkazm i niedopowiedzenia są tak długo ciekawe, jak długo nie są wyjaśniane. Tak właśnie chcę pisać – wymagając od odbiorcy refleksji. Głębszej. Kontrowersyjnie? Oczywiście – zgodnie z zamierzeniem. Nie piszę o podstawach, dlatego nie znajdzie Pan w moim blogu trywiałów w stylu podstawowe wady i zalety rozwiązań chmurowych.
    Sprzeczności tu nie ma. Może pomogłoby dodatkowe zdanie / zdania wyjaśnienia, bo za duże skróty myślowe. Ale Pan przecież doskonale wie, co sądzi, prawda? :-)

Pozostaw komentarz