Amazon jako jeden z dostawców chmury w hiper-skali (czy jest dobry odpowiednik tego słowa w języku polskim?) ma wyjątkową pozycję. Pozycja Amazon jest wyjątkowa przynajmniej z dwóch powodów:
-
możliwość obserwowania rynku i swoich klientów z pozycji firmy, która utrzymuje ich zasoby i rozwiązania. Nawet bez wglądu w ich kod widzi jakie problemy rozwiązują dla jakiej branży i w jaki sposób.
-
możliwość grania w grę długoterminową. Ma zasoby. Ma rozwijający się biznes. Ma czas i środki na to, aby rozwijać rozwiązania w kontekście długoterminowych trendów.
Amazon skrzętnie z tej możliwości korzysta. Objawia się to co jakiś czas nowymi usługami, ale widać to szczególnie przy okazji konferencji Amazon re:Invent, na której Amazon ogłasza nowe usługi. Często te ogłoszenia wiążą się z przekreśleniem całych gałęzi rozwiązań, które dotąd istniały na rynku jako uzupełnienie usług już istniejących.
Czasem usługi te pokazują nadchodzące trendy i kierunki rozwoju zarówno usług Amazon jak i w długim okresie szeroko rozumianego IT.
Na scenę wchodzi CodeGuru!
Na ostatnim re:Invent Amazon ogłosił nową usługę – Amazon CodeGuru. Czym jest CodeGuru? Oddajmy głos samemu Amazonowi:
(…) Amazon CodeGuru is a machine learning service for automated code reviews and application performance recommendations. It helps you find the most expensive lines of code that hurt application performance and keep you up all night troubleshooting, then gives you specific recommendations to fix or improve your code. (…)
Co w tym nowego? Takie było pierwsze pytanie większości komentujących. Fakt, takie narzędzia już istniały.
Amazon przejmie nasz kod i wykorzysta na swoje potrzeby! Pojawiły się i takie głosy.
To nie będzie działać, albo będzie działać w określonych przypadkach! To zupełnie możliwe. Może być też, że ta konkretna usługa, za jakiś czas przestanie być rozwijana albo zostanie zastąpiona czymś innym ze stajni Amazona.
To o co ten szum i czy warto się tym przejmować?
Gdyby to było tylko narzędzie do przeglądu kodu, analizy statystycznej od strony bezpieczeństwa czy dobrych praktyk programistycznych – prawdopodobnie nie.
Jeżeli jednak spojrzymy na nie jako na element większej zmiany, jako jeden z jej elementów – zdecydowanie tak!
Jaka to zmiana? Można ją z grubsza sprowadzić do następujących elementów:
- Kod w coraz większej mierze będzie działał w architekturze usług „serverless” (do tego jak rozumiem serverless za chwilę wrócimy).
- Rozwiązania będą oceniane nie tylko pod kątem spełnienia wymagań funkcjonalnych, ale też kosztu realizacji tych wymagań, rozumianych jako koszt zużycia zasobów usług w chmurze lub innych usług publicznych.
- Kod i architektura rozwiązań będą funkcją kosztu dostarczenia wartości użytkownikowi.
W takim podejściu, usługi typu CodeGuru będą stanowiły podstawę do optymalizacji kosztu kodu,
i bezpośrednio przynosiły wymierne korzyści w rozwiązaniach.
Czy AI zastąpi programistów?
Zanim przejdziemy do poszczególnych elementów, przejdźmy przez jeden komentarz/pytanie do CodeGuru i podobnych usług: Czy AI zastąpi programistów i będzie tworzyć kod?
Nie!
A przynajmniej nie w najbliższej przyszłości. Nasze umiejętności i możliwości w zakresie tego, co nazywamy AI a co lepiej jest nazwać Machine Inteligence[1] sprowadzają się do rozwiązań działających w wąskiej dziedzinie, gdzie można zapewnić duży zestaw danych oraz moc obliczeniową dla algorytmu, który będzie wnioskował na podstawie tych danych.
Obecne rozwiązania w tym zakresie dobrze sprawdzają się w dziedzinach takich jak rozpoznawanie obrazu czy analiza języka. Do poziomu AI, które będzie pozwalało na pisanie kodu bezpośrednio przez algorytm jest nam jeszcze daleko.
Programiści przez długi czas mogą spać spokojnie.
Ile kosztuje kod napisany przez programistę?
Skoro AI nie zastąpi programistów, to nadal będą oni tworzyć kod rozwiązań. Pytanie – czy programista tworząc kod, powinien zastanawiać się, ile kosztuje jego kod?
Oczywiście, programiści zawsze mieli przed sobą zagadnienie optymalizacji wydajności kodu. Nie zawsze zwracali na nie uwagę, ale ono istniało.
Przed przeniesieniem rozwiązań do chmury publicznej, w ramach lokalnych data center, koszt kodu a raczej jego wykonania, nie był czymś istotnym. Firma ponosiła koszt utrzymania całego datacenter, którego koszty oczywiście były (czasami) rozliczane na poszczególne aplikacje i systemy, ale nigdy nie było możliwości przypięcia kosztu zasobów do konkretnego kodu napisanego przez danego programistę.
Chmura publiczna zmieniła sytuację w kilku aspektach:
- Architektura usług w chmurze wymusza poniekąd (można to oczywiście ignorować i traktować chmurę jako wirtualne data center) podejście do podzielenia rozwiązania na poszczególne komponenty, które realizowane są przez nasz kod lub w ramach usług chmury publicznej.
- Komunikacja pomiędzy poszczególnymi komponentami rozwiązań odbywa się (o ile tego nie zignorujemy) jak pomiędzy niezależnymi elementami API
- Koszt każdego z elementów rozwiązania jest możliwy do rozliczenia na podstawie danych billingu od dostawcy usługi.
Co to zmienia? Zamiast jednego worka nazwanego „data center”, mamy mniejsze elementy, niektóre z nich nawet nie zbudowane przez nas, i do każdego z nich możemy przypisać jednostkowy koszt działania, jasno rozliczany ze względu na jego funkcję od strony biznesowej (o ile zadbamy o to, w ramach naszego procesu zarządzania chmurą – słowo klucz „Cloud Governance”).
Większość kodu jednak nadal działa w maszynach wirtualnych lub kontenerach pod kontrolę Kubernetes? Czy możemy odpowiedzieć na to ile kosztuje nas kod programisty, jeżeli płacimy za instancję maszyny bezpośrednio lub klastra utrzymującego instancje naszych kontenerów (czyli na końcu maszyny)?
Proszę Państwa, proszę powitać serverless!
O serverless w większości każdy już też słyszał. Głównie jako o elementach usług w chmurze publicznej – czy to Azure Functions czy AWS Lambda. Technologicznie serverless to sposób uruchomienia kodu, gdzie wszystko poniżej kodu, czyli zasoby i framework do uruchomienia kodu, dostarcza nam dostawca usługi.
Od strony technicznej rozwiązania serverless (wyszły one już poza tylko funkcje, mamy dostępne bazy danych, API Gateway itp.). mają jedną cechę – rozliczane są za czas działania i zasoby, z których korzystają w tym czasie.
Jeżeli dany zasób serverless nie wykonuje swojej funkcji, nie płacimy za jego użycie. I tutaj dochodzimy do kluczowego sposoby myślenia o podejściu serverless (do czasu aż nie znajdziemy lepszej nazwy będziemy używać tej), czyli o rozwiązaniach, które generują koszt tylko wtedy, gdy wykonują funkcje biznesowe z dokładnością do kosztu składowania danych.
Co to zmienia? Jeżeli podejdziemy w ten sposób budowania systemu to rozbijając elementy na poszczególne atomowe funkcje, mamy architekturę, w której element systemu kosztuje nas tylko wtedy, gdy realizowana jest funkcja biznesowa, za którą on odpowiada.
Nie mamy już maszyny wirtualnej, w której działa aplikacja i czeka na to, aż ktoś ją wywoła. Nie mamy zestawu funkcji służących do zarządzania i skalowania kontenerami, która czeka na to, aby przeskalować nam aplikację w momencie, gdy wymagane jest jej użycie.
Mamy kawałki kodu, które realizują konkretne funkcje i są atomowo rozliczane, co do kosztu ich działania.
A poprzez prześledzenie ciągu wywołania tych elementów kodu i zasobów przez nich używanych, jesteśmy w stanie odpowiedzieć na pytania takie jak „Ile kosztuje nas wygenerowanie jednej faktury w formacie PDF z naszego rozwiązania?” lub „Która z naszych funkcjonalności systemu generuje największy koszt na jedno wywołanie użytkownika?”.
Jeżeli jesteśmy w stanie odpowiedzieć na to pytanie, jesteśmy w stanie też zacząć optymalizować kod i architekturę rozwiązań pod tym kątem.
Na scenę powraca CloudGuru!
Co w tym kontekście zmienia się dla usług takich jak CloudGuru (jej kolejnej wersji lub następcy)?
- CloudGuru w kolejnej wersji lub jego następca, nie będzie musiał rozumieć skomplikowanych algorytmów czy logiki biznesowej w kodzie. Będzie musiał efektywnie identyfikować potencjalne sekcje kodu, powodujące zużycie zasobów dostawcy chmury, czyli wpływającej na rachunek końcowy i koszt rozwiązania w ramach krótkich elementów kodu i jego zależności zewnętrznych.
- Nie będziemy analizować skomplikowanych rozwiązań działających w ramach maszyn wirtualnych a ścieżki funkcjonalne w ramach aplikacji, złożone z wywołań kodu lub usług w modelu serverless (lub zewnętrznych usług) pod kątem kosztu ich wykonania, wyrażonego w wielkości rachunku od dostawcy.
- Optymalizacja kosztu będzie polegała na wyeliminowaniu drogich elementów kodu lub zastąpieniem ich wywołaniem gotowych komponentów w modelu serverless lub usług zewnętrznych (API).
W chwili obecnej zakładamy, że rozwiązanie działa i ponosimy jego koszt cały czas. Tego nauczyło nas ostatnie kilkadziesiąt lat w IT. Jeżeli nawet nikt nie korzysta z aplikacji, jej utrzymanie i działanie kosztuje.
Ile? To przeważnie był jeden duży worek z pieniędzmi rozliczany w dość przybliżony sposób.
W przyszłości, oczekiwanie zmieni się w kierunku tego, że jeżeli nasze rozwiązanie nie zarabia dla nas w danej chwili (zarabia oznacza tutaj dostarczenie wartości dla użytkownika) to również nie ponosimy w danym momencie kosztu jego działania.
Jeżeli już działa to oznacza, że jesteśmy w stanie odpowiedzieć, ile kosztuje nas wywołanie poszczególnych funkcji biznesowych w ramach tego rozwiązania i jesteśmy w stanie też optymalizować kod i architekturę pod tym kątem.
Co to wszystko dla nasz znaczy?
Co to wszystko ma do usługi takiej jak CloudGuru? Od usług typy CloudGuru nie oczekuję w przyszłości, że napiszę kod aplikacji. Nie oczekuję, że poprawią logikę całości rozwiązania. Oczekuje, że będę w stanie wskazać kod rozwiązania (jako całego rozwiązania, czyli również wszystkich usług i kod wdrażający to rozwiązanie) lub wskazać log z wywołań API i kodu pomiędzy komponentami usługi a w odpowiedzi uzyskam informację:
- Jaki jest koszt poszczególnych ścieżek wywołań w aplikacji z punktu widzenia zużycia zasobów platformy?
- Które elementy poszczególnych funkcji powodują największe zużycie zasobów?
- Jak mogę je zmienić lub którymi usługami bądź gotowymi funkcjami z repozytorium aplikacji serverless będę w stanie je zastąpić, żeby zmniejszyć koszt całego rozwiązania.
Oczekuję, że ta funkcjonalność nie będzie dostępna tylko dla programistów i architektów, ale będzie dostępna głównie dla użytkownika biznesowego, będącego odbiorcą danej aplikacji czy rozwiązania, który nie będzie musiał znać szczegółów technicznych kodu, ale będzie mógł zadać pytanie „Czy możemy zmniejszyć koszt drukowania tych faktur o 5%? Przy naszej skali zaoszczędzimy na tym X% kosztu utrzymania systemu?”
Brzmi fajnie, ale rozwiązania serverless jeszcze nie są na to gotowe!
To główny argument, który podnoszony jest przy tego typu rozważaniach: “To przyszłość i to daleka! Serverless nie jest jeszcze gotowy. Te problemy z cold start!”
To wszystko prawda. Wróćmy tutaj jednak do początku tego artykułu i pozycji Amazon (jak i innych dostawców):
- Amazon obserwuje trendy i zmiany, których mi nie widzimy, chociażby obserwując to co się dzieje na ich własnej platformie AWS w rozwiązaniach klientów czy we własnych systemach.
- Amazon gra w grę długoterminową i ma odpowiednie zasoby i środki aby tworzyć rozwiązania dla rzeczy, które nie są jeszcze uważane za mainstream.
Rozwiązania takie jak kontenery i podejście serverless, w końcu połączą się wygląda na to, że to co otrzymamy na końcu, będzie bliżej właśnie podejściu serverless niż platformom takim jak Kubernetes (co nie oznacza, że Kubernetes zniknie, ale to już może temat na osobny artykuł).
Jak dokładnie zostanie zrealizowane dostarczenie, zarządzanie i uruchomienie kodem jest mniej istotne, niż to, że:
- będziemy w stanie jednoznacznie określić koszt wykonania poszczególnych elementów kodu i całych ścieżek jego wykonania
- będziemy w stanie wymieniać poszczególne elementy rozwiązania na gotowe komponenty lub usługi z rynku działające w modelu serverless (nie płacisz, gdy nie działa).
I to będzie duża zmiana, która zmieni podejście do tworzenia aplikacji i celów stawianych przed programistami.
Czyli CloudGuru pozwoli nam płacić mniej?
A co jest w tym dla Amazon? W końcu taka optymalizacja, będzie pozwalała klientom zmniejszyć rachunki związane z użyciem platformy? Czy nie strzelają sobie w stopę?
W żadnym wypadku. Dzięki takiemu podejściu do rozliczania kosztu usług i aplikacji, użytkownicy będą chcieli przenieść jak najwięcej aplikacji działających obecnie jako „czarne skrzynki” do tego modelu i odejść od modelu płacenia za potencjalne użycie.
A im więcej aplikacji przeniosą na platformę Amazon (czy innego dostawcy), która będzie dostarczała takie możliwości, tym większy rachunek, jaki zostawią u dostawcy z poczuciem większej wartości jaką otrzymali.
Pamiętajmy – to jest długoterminowa gra i dostawcy chmury publicznej mają zasoby aby w nią grać.
Żeby dostarczyć taką usługę, muszą ją przetestować i nauczyć. To że CloudGuru pojawił się w ramach zasobów AWS, oznacza że skończył się etap testowania i uczenia na zasobach i aplikacjach Amazona. Teraz czas na naukę w mniej kontrolowanym świecie kodu pisanego przez użytkowników.
Na podstawie tej nauki, powstaną kolejne wersje, które będą robiły już zupełnie inne rzeczy, niż narzędzia optymalizacji kodu dostępne w tej chwili na rynku.
I to wyróżnia CloudGuru od obecnych narzędzi!
A jeżeli chodzi o obawę, że Amazon przy pomocy takiego narzędzia będzie chciał przejąć Wasz kod. Śpijcie spokojnie. Amazon nie potrzebuje kodu. Może go napisać szybciej i taniej.
Amazon obserwuje i przejmuje modele biznesu. I tutaj powinniśmy się zastanawiać jak zbudować naszą przewagę. Kod jej nie zapewni.
[1] Seeing Digital: https://www.amazon.com/Seeing-Digital-Industries-Organizations-Careers-ebook/dp/B07CKCXB88
