Jeśli myślisz, że FinOps i FinOps Framework to to samo, to masz problem większy niż sześciocyfrowe rachunki AWS. Łukasz i Szymon tłumaczą różnicę między prostym podejściem a frameworkiem. Czy FinOps Framework to kolejny potwór jak SAFe? Spoiler: jedno mieści się na kartce, drugie w stustroniowym brulionie.
Dowiesz się, dlaczego architektury referencyjne to życzeniowy marketing księgowych, jak 1% utylizacji może rujnować budżety i dlaczego osierocone dyski generują więcej kosztów niż wartości. Od rightsizingu przez rezerwacje po metryki typu cost per transaction - wszystko z konkretnymi przykładami z pola walki. Plus bonus: dlaczego środowiska testowe działające 24/7 to najprostszy sposób na spalenie budżetu bez żadnej wartości biznesowej.
Zamiast płakać nad kolejnym rachunkiem za chmurę, posłuchaj jak crawl, walk, run w praktyce i sprawdź, czy twoja organizacja potrzebuje dedykowanego FTE do FinOps, czy może wystarczy przestać przepalać pieniądze na niepotrzebne zasoby.
Słuchasz Patoarchitektów dzięki PROTOPII – firmie, w której Łukasz i Szymon działają na co dzień, wspierając zespoły IT na każdym etapie: od projektowania, przez wdrożenia i migracje, aż po optymalizację i zabezpieczenia. Oferujemy też mentoring i szkolenia dostosowane do potrzeb każdej firmy, niezależnie od wielkości. Sprawdź nas: protopia.tech
Discord 👉 https://discord.gg/78zPcEaP22
Linki i ciekawe znaleziska:
OpenCost Supports the FinOps Open Cost and Usage Specification (FOCUS)
| [Assessments | Azure Well-Architected Review](https://learn.microsoft.com/en-us/assessments/azure-architecture-review) |
| [OpenCost — open source cost monitoring for cloud native environments | OpenCost — open source cost monitoring for cloud native environments](https://opencost.io/) |
| [Microsoft Cost Management | Microsoft Azure](https://azure.microsoft.com/en-us/products/cost-management) |
| [Pricing Calculator | Microsoft Azure](https://azure.microsoft.com/en-us/pricing/calculator) |
| [Azure Advisor – Azure Best Practices | Microsoft Azure](https://azure.microsoft.com/en-us/products/advisor) |
GitHub - opencost/opencost: Cost monitoring for Kubernetes workloads and cloud costs
| [Cost optimization quick links - Microsoft Azure Well-Architected Framework | Microsoft Learn](https://learn.microsoft.com/en-us/azure/well-architected/cost-optimization) |
Set Custom Cost and Usage Budgets – AWS Budgets – Amazon Web Services
GitHub - infracost/vscode-infracost: See cost estimates for Terraform right in your editor💰📉
Azure Well-Architected Framework - Microsoft Azure Well-Architected Framework
| [Cloud Billing documentation | Google Cloud](https://cloud.google.com/billing/docs) |
AWS Well-Architected - Build secure, efficient cloud applications
Łukasz Kałużny: Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…
Szymon Warda: I Szymon Warda. Linki do tego odcinka o dziwo w opisie lub na Patoarchitekci.io i gdzieś ogarniacie, wierzymy w Was. Taki mały quest. Dobrze Łukaszu, o czym dzisiaj?
Łukasz Kałużny: Dzisiaj odcinek, który, można byłoby robić dużo anegdot, gdyby nie wszystkie NDA-e, czyli problem kosztów w chmurach. I czym jest ten magiczny jednorożec o nazwie FinOps?
Szymon Warda: Tak i czym się różni FinOps od FinOps Framework tak naprawdę, bo to bywają trochę inne rzeczy, raczej podobne, ale nie do końca to samo.
Łukasz Kałużny: Dobra, może w ogóle zacznijmy od problemu jaki jest, czyli marnotrawienie kasy na chmurę.
Szymon Warda: To się nazywa wydawanie.
Łukasz Kałużny: Ja bym powiedział przepalanie, bo ono idealnie obrazuje w niektórych przypadkach.
Szymon Warda: Dokładnie, dobrze. To co widzimy najczęściej?
Łukasz Kałużny: Jak podejdziemy to będzie taka, nazwijmy to marnotrawstwo, o którym powiedzieliśmy. I jeżeli teraz popatrzymy, tam będzie kilka takich rzeczy. Pierwsze, chyba najczęściej, to jest najprostsze, z naszej praktyki, jak pomagamy zoptymalizować rachunki, to jest, że robimy cloud jak onprem. Czyli upfront, nie wiedząc, upfront wrzucamy już te całe docelowe zasoby, aplikacja startuje na produkcji, jest prawie nieużywana, ale my już dajemy na przykład, powiedzmy, że w Kubernetesie robimy klaster na 10 node’ów, tak przykładowo, a wystarczą 3 na początek.
Szymon Warda: Ja bym nie powiedział, że to jest docelowe zasoby. To jest takie bardziej życzeniowe zasoby, które będą za ileś tam lat często albo w ogóle się nie ziszczą, albo zostały wyssane z centrum statystyk, z wiadomo skąd. Inną rzeczą, którą widzę, to jest to, że też często jest opcja taka, że zabawy zabawkami chmurowymi, czyli użyjmy sobie czegoś. Czemu? Bo tak. I kompletnie nie patrzymy w ogóle czemu to jest potrzebne i wychodzi w tle.
Łukasz Kałużny: I właśnie ja bym jeszcze dorzucił, bo one chodzi w tle, to się łączy, też robi jak onprem, czyli mamy rzeczy, które są nie doutylizowane. Czyli zamiast zżerać na przykład te minimum 50% zasobów, powiedzmy średnio, to rekordy, to widziałem po 1% w ciągu miesiąca. To takie moje, pamiętam, kurde, czuję się staro z chmurą, ale mogę powiedzieć tak z 8 lat temu, kiedy robiłem pierwsze takie optymalizacje, miałem przykład systemu BI-owego, który potrzebował, jedyny pik na 45% miał w momencie cotygodniowego dużego ładowania, bo codzienne małe trzeba było się z lupą przyglądać kiedy procesor wyskoczył.
Szymon Warda: Tak, tak, mówimy typowy taki oversizing. Dobra. Co dalej mamy?
Łukasz Kałużny: Najbardziej znienawidzone, za co nas koledzy od vendorów, dostawców chmurowych znienawidzą. Ale kolejną rzeczą to są architektury referencyjne dostawców, czyli te przepiękne diagramy w Architecture Center, które mówią jak coś zrobić. I one mają bardzo ważną rzecz. To jest, powiedziałbym, że najlepsza referencyjna architektura życzeniowa marketingu i księgowych od Hyper Skylerów, czyli nawrzucajmy wszystkich usług jakie się da w jak najwyższych tierach.
Szymon Warda: Tak, no to jeszcze dorzucę rzecz ostatnią, czyli osierocone zasoby. To chyba też widujemy często. To jest jeszcze piękna rzecz z racji oczywiście na bezpieczeństwo te wszystkie maszyny. Teraz już jest trochę mniej popularne, ale zdarzało się, że wchodziło się nagle różne maszyny wirtualne i nikt nie wiedział po co, nikt nie wiedział do czego i działo się.
Łukasz Kałużny: Ale wiesz co, moją ulubioną to są na przykład, jak ktoś tam przestawił konfigurację na przykład dysków na Kubernetesie i nagle patrzysz 50 czy 60 odłogiem leżących dysków i za każdego tam grosik do grosika spada. Czyli ogólnie rzeczy, które zostały gdzieś zostawione i tyle i nigdy nie sprzątnięte.
Szymon Warda: Dane często się pojawiają, że nagle patrzymy, a te 100 checkouty mają tam terabajtów.
Łukasz Kałużny: Ja bym Szymon jeszcze dodał jedną rzecz do osieroconych zasobów.
Szymon Warda: No.
Łukasz Kałużny: Jest ona nieoczywista, ale nazywa się logi.
Szymon Warda: Oj tak, tak, tak, tak i przechowywanie i ile tam siedzą.
Łukasz Kałużny: Tak. I taki rekord słuchajcie, z naszej pracy, to był jeden taki radosny projekt z dwa lata temu, gdzie pomogliśmy posprzątać. Okazało się, że rachunek wynosił za rozwiązanie za środowisko produkcyjne i deweloperskie za prod non prod łącznie 60 tysięcy dolarów miesięcznie za system, co jest już niemałą kwotą, z czego 30 tysięcy euro stanowiły logi, które były nieużywane.
Szymon Warda: Słuchaj, ale tak idziemy anegdotami i logami, to mam jeszcze jednego takiego konika. Application Insights, który został włączony i tam sobie chodzi w tle i nikt z niego nie korzysta.
Łukasz Kałużny: No właśnie tak. Dlatego mówię, że logi, monitoring, trace’y potrafią być osierocone.
Szymon Warda: Jak się z nich korzysta, to faktycznie to jest fajna opcja, ale różnie z tym bywa, różnie widujemy.
Łukasz Kałużny: Dobra i chyba trzeba przejść, bo wybuchł nam teraz tak, bo mówimy sobie, że dzisiaj o FinOpsie, ale wspomniałeś o FinOps Frameworku, więc chyba trzeba byłoby zacząć wyjaśnić różnicę czym jest FinOps a czym FinOps Framework.
Szymon Warda: To jak Scrum i Safe Framework, tudzież Scrum Framework. Jedno mieści się na jednej kartce, drugie mieści się w brulionie 100 stron właściwie można powiedzieć.
Łukasz Kałużny: Tak, założenie powstało sobie FinOps Foundation, to jest chyba 2000, w ciągu ostatnich lat, o tak, powstała inicjatywa FinOps Foundation. I powstał tam framework. Czyli z jednej strony mamy cloudowe Financial Operations, które się spopularyzowało, bo trzeba patrzeć inaczej niż na rachunki za CAPEX-owe serwery, które wstawiamy do data center. A fundacja… Właśnie, to chyba dobre porównanie Szymon, że zrobiła FinOps w wersji Scaled Agile Framework, czyli zrobiła kobyłę moim zdaniem w postaci frameworku. I tutaj bym chyba wrzucił jedną taką istotną rzecz przy tym od razu, bo przejdziemy sobie przez ten FinOps Framework, bo jak każda rzecz ma dużo dobrych elementów, takich ustrukturyzowanych, tylko trzeba mieć świadomość, że do tego potrzeba mieć… Zastanawiałem się, kiedy powiedzieć, że FinOps Framework to jest te miejsce, którym można się zainteresować. To kiedy możesz poświęcić dedykowaną, pierwsze dedykowane FT na to, że można zacząć go używać i masz odpowiednią skalę, czyli być może już duży zespół cloudowy, naście zespołów i takie blisko sześciocyfrowe rachunki miesięcznie za te cloudy.
Szymon Warda: Ja bym pokusił się o to, że niekoniecznie to jedno FT więcej niż jedno FT, bo tam tej roboty [niesłyszalne 00:07:10].
Łukasz Kałużny: Żeby zacząć.
Szymon Warda: Ról jest dużo. Raczej temu frameworkowi warto się przyjrzeć. On ma swoje, to, co już mówiłeś, ma swoje dobre elementy, które można brać tu i teraz, nawet przy małych zespołach. Ale wykorzystywanie frameworka jako frameworka całego, no to tak, to… Może inaczej, jak wykorzystujemy frameworki do Scruma, to też taki moment może być do wykorzystania frameworków do kosztów.
Łukasz Kałużny: Dobra i można go tak samo jak Scruma zgwałcić i też może zadziałać.
Szymon Warda: Oj tak, tak. Dobrze.
Łukasz Kałużny: Dobra.
Szymon Warda: To może od tego zacznijmy.
Łukasz Kałużny: Dobra i od razu będziemy mówić gdzie wejdziemy głębiej, gdzie nie. Czyli zasady i one są, je można po prostu brać, o tak, od tej strony. Persony i to jest rzecz, która jeżeli wejdziecie w detale, jest potężna.
Szymon Warda: Jest rozdmuchana, bym powiedział.
Łukasz Kałużny: Tak. Następnie…
Szymon Warda: Ona ma wartości w dużych organizacjach, bo tam jest dużo ewangelistów, są ładnie przypisane odpowiedzialności, jest konkretny podział i widać, że ten framework jest zbudowany wokół tego, żeby rozkręcić FinOpsa w organizacji, żeby tym zarządzać. Ale jest tego dużo.
Łukasz Kałużny: Następnie mamy fazy, tutaj w to też wejdziemy, bo jest wartościowe. Są domeny, czyli obszary rezultatów biznesowych i tutaj coś tam wspomnimy, ale… Inaczej, jeżeli nie planujecie robić full blown wdrożenia, nie patrzcie na to, troszeczkę poza zobaczeniem, że jest i tyle, tak z naszej perspektywy.
Szymon Warda: Ja bym powiedział jedną rzecz, tam zerknąć, żeby wiedzieć, w których obszarach można myśleć o oszczędnościach i jak do tego podejść, ale na spokojnie.
Łukasz Kałużny: Dobra, kolejną rzeczą są zdolności, 22 funkcjonalne obszary.
Szymon Warda: Pomińmy.
Łukasz Kałużny: Tak, pomińmy. Warto oczywiście… Inaczej, warto to przeczytać. To nie jest tak, że… Tutaj bardziej chodzi o to, żeby nie rzucać się na implementację takich rzeczy od razu, ale zrozumieć w ogóle o co chodzi. Kolejnym elementem jest, jak zawsze to jest pozytyw tych najnowszych frameworków operacyjnych, które powstają, czyli maturity model, model dojrzałości. I to też taki must have, żeby wiedzieć gdzie jesteśmy.
Szymon Warda: I nowość z tego roku.
Łukasz Kałużny: Scope’y i tutaj ok, pójdźmy sobie w tym. Scope’y, chodzi o to, że framework też zaczął z cloudu, idzie do onpremowych rzeczy, innych niż tylko utylizacja chmury.
Szymon Warda: Dobra, to nie odwlekając, zaczynamy. 6 zasad kluczowych dla FinOpsu. Pierwsze - zespoły muszą współpracować.
Łukasz Kałużny: Wyświechtane na maksa, ale prawdziwe.
Szymon Warda: Ja to wiele razy mówiłem, elementami technologicznymi nie rozwiążemy problemów ludzkich. Więc trzeba ze sobą spotykać się i gadać. Drugie Łukaszu.
Łukasz Kałużny: Trójkąt Toyoty w wersji FinOps Framework, czyli wartość biznesowa, napędza decyzje technologiczne. I to jest tak, faktycznie jak będziemy w KPI-ach, tam też wspomnimy o tym, bo to KPI-e, które znajdują się w FinOps Frameworku, dobrze pewne rzeczy pokazują. I tutaj właśnie szukanie kompromisu między kosztem, jakością, szybkością.
Szymon Warda: Tak, to…
Łukasz Kałużny: Czego realnie potrzebujemy.
Szymon Warda: To jest najważniejszy element, że tam będą kompromisy. Kompromisy będą zawsze. Dobra, kolejne. Każdy bierze odpowiedzialność za swoje użycie technologii. Czyli zespoły decydują co się dzieje i mają być za to, jak ładnie się mówi, accountable. Ja z tym mam pewien problem, bo to może brzmieć jako takie, że a to używajcie sobie co chcecie. Jednak pewne rzeczy będziemy standaryzowali, że pewne usługi, z pewnych korzystamy, z pewnych nie korzystamy, więc też ostrożnie. To nie jest takie, że pozbywamy się [niesłyszalne 00:11:05], architektury i tak dalej, dalej trzymamy standardy.
Łukasz Kałużny: Raczej to chodzi o to, że przejmujemy odpowiedzialność i patrzymy. To o rzeczach, o których potem wspomnimy, że to też powinniśmy, powinniśmy proaktywnie patrzeć na koszty, ale też nie przesadzać w drugą stronę, żeby to nie było: niech się dusi, bo nie wydam więcej.
Szymon Warda: Tak. Dane FinOps powinny być dostępne, aktualne i dokładne.
Łukasz Kałużny: No i teraz to jest tak. Potem sobie podejdziemy o jednej inicjatywie. To jest prawda, o tak, z tym się tutaj zgodzę. Zabawa zaczyna się, kiedy wychodzimy poza jednego dostawcę chmurowego.
Szymon Warda: Znaczy ja myślę sobie, bo to też nie jest tak, że na ile te dane są transparentne, na ile crosszespołowo to jest widziane i kto to widzi. Bo to też często będzie odbitka, że sorry, jest zbyt duża widoczność kto co właściwie robi i powinny być dostępne, powinny być widoczne i aktualne.
Łukasz Kałużny: Tylko, jak powiedziałem, porozmawiamy o narzędziach. To jest coś, co na przykład w danym cloudzie oglądasz na lokalnych dashboardach cloudowych, bo potem pokazuje się jeszcze FinOps powinno być umożliwione centralnie, czyli że powinno być scentralizowane. I tutaj te raporty centralne się przydają, pozwolą trochę lepiej popatrzeć. Jeżeli popatrzymy, mam problem z tym trochę, bo i to jest taki obszar z tych… To jest chyba najgorsza zasada teraz realnie, bo negocjacje są dostępne tylko dla coraz większych.
Szymon Warda: Zgadza się, ale to też ten punkt pokazuje centralnie, że czasami tak jest, doskonale wiemy, że korzystanie z potencjalnie może na przykład droższej maszyny czy czegokolwiek innego, w ramach standardu mamy większą zniżkę. Czasami się bardziej opłaca. Pewne rzeczy faktycznie warto manipulować centralnie, żeby jednak nie mieć takiej drobnicy totalnej. Ale tak, te opcje negocjacyjne są coraz gorsze. To się z Tobą w zupełności zgodzę.
Łukasz Kałużny: Tak. No i ostatnia rzecz, to jest korzystanie ze zmiennego modelu kosztownego dostawcy, czyli pay-as-you-go, serverlessów i innych takich elementów, jak byśmy to przetłumaczyli technicznie.
Szymon Warda: Tak, będziemy mieli zasoby, które będą długofalowe, będziemy mieli zasoby, które możemy sobie skalować góra-dół i mieć tą zmienność.
Łukasz Kałużny: To co, chyba teraz cykl FinOps, który ma ten trzyfazowy cykl z frameworku, który ma… Znaczy inaczej, jak każda rzecz iteracyjna ma sens i nie będzie dla Was niczym nowym.
Szymon Warda: Tak. Pierwsza faza.
Łukasz Kałużny: Lecisz Szymon.
Szymon Warda: Inform. Cel - dostarczenie widoczności kosztów i stworzenie wspólnej odpowiedzialności. Co tam robimy? Alokacja kosztów, benchmarking, budżetowanie, prognozowanie, zbieranie, analiza danych o kosztach, użytkowaniu i efektywności chmury. Musimy mieć bazę, żeby w ogóle od czegoś zacząć, wiedzieć, gdzie jesteśmy.
Łukasz Kałużny: I ta praktyka, słuchajcie, pójdzie do tego, że to są tagowania zasobów w zależności od cloudu. Ważną rzeczą chyba w narzędziach, powiedziałbym najbardziej istotną z tego, co trzeba wyciągnąć, to jest popatrzenie sobie na te raporty, które są, zakładanie budżetów i patrzenie na ustawienie alertów i innych takich rzeczy, żeby widzieć, jak faktycznie wygląda. Bo też bądźmy realistami o tej skali. To, co było trochę powiedziane przy tej części zasadach, że każdy bierze odpowiedzialność za użycie swojej technologii i wykorzystanie tego, to jest troszeczkę pójście właśnie w tą część całą, gdzie mamy w cloudzie budżety, prognozy i można na to położyć alerty, zobaczyć jak to wygląda. No i potem sprawdzić, jak to wszystko, jaką mamy efektywność tego użytkowania.
Szymon Warda: To jest najbardziej mrówcza robota, czyli przypisanie cost center, przypisanie jakie to są środowiska i dowiedzenie się w ogóle, kto za to płaci.
Łukasz Kałużny: Ale tak, tylko to jest podejście trochę: jak ułożymy nasze zasoby w chmurze? Bo zauważ, że jak pójdziemy sobie do tych wszystkich cloud adoption frameworków, to jest jedna z sensownych rzeczy, żeby upfront ułożyć sobie, że jak dajemy resource grupę, to charge’ujemy tą resource grupę, tam mamy jakieś centrum kosztowe wspólne. Dlatego też w niektórych modelach ta decentralizacja w postaci “dajemy ci subskrypcję i za nią Cię charge’ujemy” jest dobrą rzeczą.
Szymon Warda: Tak, taka granulacja na poziomie subskrypcji, że tam robisz sobie co chcesz i dokładnie wiemy, który system w której subskrypcji siedzi. Zgadzam się.
Łukasz Kałużny: Dobra, następne.
Szymon Warda: Optimise, czyli optymalizuj. Cele - redukcja marnotrawstwa w chmurze i poprawa efektywności działania, implementacja różnych strategii optymalizacji, rightsizing zasobów, czyli żeby chodziły tak, jak mają chodzić, wybór opłacanych usług i modeli cenowych i optymalizacja stawek, zobowiązań i rabatów.
Łukasz Kałużny: Ja bym powiedział, że to trzeba patrzeć na różnych poziomach, bo tak jak mówimy o… Bo rezerwacje można patrzeć per cała umowa, w zależności tam jakie mamy usługi, jak i lokalnie. I to jest teraz taka rzecz, że trzeba patrzeć na optymalizację z poziomu zespołu gdzieś, a potem całego dostawcy chmurowego, bo to jest też taki istotny element, który w tym występuje, że patrzymy lokalnie i całościowo.
Szymon Warda: Tak, optymalizuj. Tylko jedna uwaga, trzeba iść w tej kolejności - usuwać, czego nie potrzebujemy, downsize’ować to, co możemy, a na końcu dopiero robić rezerwację. Bo widziałem takie sytuacje, że nagle: a to rezerwujmy, wyklikujmy, idziemy.
Łukasz Kałużny: Centralnie, tak. Najpierw rightsizing i to jest chyba rzecz. Tutaj mogę Wam dołożyć jeden tip, który rekomendujemy klientom. To są per znane typy zasobów. Najczęściej to są jakieś bazy, rzeczy, za które płacimy stale, maszyny wirtualne, to jest utylizacja CPU albo utylizacja capacity zasobów, bo tutaj wychodzą bardzo ciekawe rzeczy.
Szymon Warda: Przy bazach jeszcze RAM, to jest bardzo ważne, bo często tam jest tak, że RAM jest nie za bardzo, a RAM jest bardzo mocno wykorzystywany.
Łukasz Kałużny: Tak, tylko Szymon, teraz mamy dużą elastyczność tych rodzin, maszyn wirtualnych, które mają mało core’ów, dużo RAM-u. Np. na 1 core 8GB RAM-u, więc tutaj dlatego od tej strony trochę patrzę, że ten CPU i te globalne capacity jest taką pierwszą metryką do zaalertowania, że coś jest nie tak.
Szymon Warda: Czy tak, ona jest pierwszą, żeby zerknąć, ale nie jest jedyną.
Łukasz Kałużny: Nie.
Szymon Warda: Tam wchodzimy w szczegóły.
Łukasz Kałużny: Jest alertującą.
Szymon Warda: Ok, tu się możemy zgodzić, tak, jak najbardziej. Dobra, ostatnie, operate - operuj. Cel - definiowanie, śledzenie, monitorowanie KPI oraz polityk governance. Działania - wyrównanie celów chmurowych i biznesowych, ciągłe monitorowanie wydajności, zarządzanie politykami governance, ocena wpływu biznesowego poprzez metryki jednostkowe i oparte na wartości.
Łukasz Kałużny: Tak, ładnie. Wiesz co? I chyba wspomnimy sobie o tym przy KPI-ach, które gdzieś mamy dalej na liście, żeby pokazać co można liczyć, jak można na to patrzeć. I mamy tam i biznesowe i techniczne metryki, które nam wydają się dobrze to odzwierciedlać.
Szymon Warda: Mówiąc prosto, cel operate to jest taki cel, który się nigdy nie kończy, ta iteracja. I jak my mamy z tym żyć, żeby się nie zarobić.
Łukasz Kałużny: Tak, kółeczko, kółeczko, kółeczko, kółeczko, jak we wszystkich ostatnio rzeczach. Dobra, modele dojrzałości, o których wspomniałem, że są ok. Nazwy są piękne, bez crawl, walk, run, czyli pełzanie, chodzenie i bieganie. I teraz jeżeli popatrzymy sobie, to crawl oznacza, że zaczęliśmy. Bo powinno być jeszcze poziom 0.
Szymon Warda: Powinien być poziom 0, bo crawl to jest takie… Bo co on w ogóle ma? Minimalne raportowanie narzędzia, podstawowe KPI, początkowe procesy i polityki, skupienie się na nisko wiszących owocach i możliwości rozumowania, ale nie powszechnie przyjęte. I to już brzmi jak taki, powiedziałbym, taki całkiem niezły.
Łukasz Kałużny: Raczej zaczęliśmy tego realnie pilnować na poziomie organizacji, bo to jest właśnie ten moment, kiedy informacja do organizacji poszła i został zaakceptowany fakt. Bo jeżeli mamy już podstawowe KPI, oznacza, że ktoś zaczyna, i podstawowe procesy, to że zaczynamy sprzątać.
Szymon Warda: To, czego brakuje, to podstawowe KPI-e i początkowe procesy. To są te elementy, których często właśnie brakuje, widzimy, że tak to ominęliście odrobinkę.
Łukasz Kałużny: Tak, bo wcześniejsza faza nazywa się ad hoc, czyli przekraczamy budżet, a za drogo, tzw. pospolite ruszenie.
Szymon Warda: Tak, tak, tak, tudzież wchodzi ticket i nagle trzeba z kosztami zejść w ciągu miesiąca z wartości.
Łukasz Kałużny: Jeżeli chodzi o walk, to że te możliwości, które mamy w ramach frameworka podejmowanych procesów są dobrze zrozumiane i stosowane. I to jest chyba clue tego punktu, że zaczynamy to realnie stosować, że główne wymagania są pokryte i zautomatyzowane, uprocesowione, główne, takie elementy, które potrzebujemy, bardziej już agresywne cele KPI i umiemy powiedzieć, nie obsługiwać, powiedzieć jakie mamy edge case’y w organizacji.
Szymon Warda: Tak, są zidentyfikowane, już wiemy, że to nie jest tak różowo, że tylko sobie wyklikamy kilka rezerwacji i będzie fajnie.
Łukasz Kałużny: Tak. I ten run to jest, że już pierwsze pojęcie wyklucza jego realność, pełne zrozumienie i stosowanie przez wszystkie zespoły.
Szymon Warda: Tak, to tak brzmi bardzo ambitnie bym powiedział.
Łukasz Kałużny: Tak, bardzo wysokie cele KPI. Automatyzacja jako preferowane podejście do FinOpsa i umiejętność procesowo zaadresowania tych trudnych przypadków brzegowych.
Szymon Warda: Co jest tutaj dla mnie ważne faktycznie w tym bieganiu? To jest ta automatyzacja, czyli posiadanie procesów, które… Na przykład tworzymy wirtualkę, to ją na przykład jak robiliśmy w jednym projekcie, to było to, że po tagu one są na przykład ubijane albo zmniejszane, skalowane w dół, na przykład na noc i tak dalej, że pewne rzeczy już przeszły do platformy i już zespoły nie muszą się martwić, tylko wklejają atrybuty.
Łukasz Kałużny: Wiesz co Szymon, tak, idąc od innych naszych klientów, na przykład to, że razem z wystawieniem, na przykład tam rodzajem właśnie platformy na bazie Azure’a od razu wystawiamy alerty i budżety. Budżety i do niego zrobione alerty hurtem. Czyli dostajesz już na dzień dobry, dostając przestrzeń dla projektu dostajesz już z góry zestaw narzędzi. I teraz chyba trzeba powiedzieć, że nie wszędzie ten… I to jest tutaj mądrze określony w tym frameworku, że nie wszędzie… Trzeba dostosować poziom dojrzałości tych różnych elementów do organizacji i jej potrzeb, bo one będą zupełnie różnie wyglądały.
Szymon Warda: Czyli nie ma sensu aplikować dużego frameworka od razu do siebie, jeżeli nie jesteśmy organizacją w pewnym rozmiarze. Pewne rzeczy mogą poczekać. Dobra, może przejdźmy teraz przez domeny.
Łukasz Kałużny: Dobra. I chyba pierwsza jest najważniejsza z tego wszystkiego, zrozumienie użycia tych zasobów cloudowych u nas w organizacji i struktury kosztowej tego. Zrozumienie tego, w jaki sposób używamy jej w organizacji. I to będzie właśnie chyba dwie rzeczy, które powiedziałbym, że to jest podstawowa… Jest to raportowanie, to są alokacje, raportowanie i wykrywanie anomalii, że tak powiem, jeżeli można to ładnie określić.
Szymon Warda: Tak, lecimy dalej. Qualifying business value, czyli połączenie, coś, co chyba najczęściej się nie udaje, czyli połączenie kosztu i jaką mamy wartość biznesową. To często się nie udaje, bo nie wiemy, jak to połączyć, albo też nie ma chęci. To też się zdarza.
Łukasz Kałużny: Wiesz co, kurde, to jest tak jak ze startupami, scale’upami, coś… Inaczej, jest wartość biznesowa, dopóki marża się zgadza, to albo scaleup’ujemy, to nikt na to nie patrzy.
Szymon Warda: Dokładnie tak to właśnie wygląda. Często po prostu też nikt nie chce wziąć na klatę tych pewnych zasobów. Jest przepychanka, kto właściwie za to odpowiada.
Łukasz Kałużny: Tak, optymalizacja. No i to jest proste, że zapewniamy w tym, że faktycznie zapewniamy wartość przez tą optymalizację. Co może oznaczać, że nasze zasoby są realnie dobrze dobrane i płacimy za nie dobrą cenę. Bo chyba tylko tyle, tak to można podsumować.
Szymon Warda: Tak, też mi się tak wydaje. Kolejne, ostatnie, Cloud FinOps Practice Operations, czyli skuteczne zarządzanie FinOpsem jako całość. Czyli operacje, całe praktyki, procesy i governance wokół tego, mamy to ładnie ogarnięte. I tyle chyba.
Łukasz Kałużny: Dobra, jeżeli tam polecimy, to jeszcze mamy w tym persony, o których powiedzieliśmy. I tam jest w sumie, jeżeli teraz popatrzymy, to leci sobie w ogóle od kadry wykonawczej, która jest odpowiedzialna za efektywność, skupienie zespołów. Potem mamy tam właścicieli zespołów, którzy są za to, właścicieli produktów, zespoły inżynierskie, zespoły finansowe, oddzielnie zespoły zakupowe i procurement i oddzielnie ci praktycy FinOps, którzy dokonują tutaj całości ewangelizacji, chyba tak to można określić.
Szymon Warda: To są takie grupy, bo tam jeszcze one się rozbijają na większe szczegóły. Zostawmy, tyle jest. Jak macie dłuższą chwilę, to możecie sobie przez te wszystkie persony przejść. Mamy lepsze rzeczy do robienia teraz.
Łukasz Kałużny: Dobra. Bardzo pozytywna rzecz, która powstaje, to jest Focus. I to jest już rzecz, bo wejdźmy sobie teraz z samego frameworku do rzeczy takich technicznych. Jedną z dobrych rzeczy w FinOps Foundation to jest inicjatywa Focus, czyli ujednolicenie danych billingowych. To jest FinOps Cost and Usage Specification. I słuchajcie, o co chodzi? Bo w każdym dużym cloudzie metryki wyglądają różnie, w różny sposób są nazywane. I tutaj jest podejście, żeby wystandaryzować, żeby centralnie, jako że to są rzeczy powtarzalne, to fundacja ma na celu wystandaryzować to do jednego wspólnego formatu metryk, które można potem raportować i oglądać.
Szymon Warda: Dobra, to teraz takie pytanie, czy to się przyjmie? Bo załóżmy Cloud Events przyjęło się jako format i faktycznie prawie wszyscy dostawcy chmurowi z tego…
Łukasz Kałużny: Wiesz co, patrząc się, że w tym FinOps Foundation Ci duzi dostawcy są. Bo teraz tak, popatrzmy sobie na to w ten sposób Szymon, że ci duzi dostawcy pomagają, jeżeli o to chodzi z tym.
Szymon Warda: Są obecni, może tak.
Łukasz Kałużny: Są obecni. I teraz jest pytanie, w którym momencie z tym Focusem zaakceptują fakt i to zrobią? Czy to jednak będzie po prostu specka implementowana przez third party narzędzie?
Szymon Warda: I tu właśnie się rozbijamy. A te szkolenia, będziemy mieli format, czy ten format da nam jakiekolwiek możliwości porównywania, czy załóżmy rozbicie będzie inne i tak dalej.
Łukasz Kałużny: Wiesz co, chyba ja bym powiedział, że to jest ułatwienie budowy centralnych raportów.
Szymon Warda: Które i tak będziemy musieli przepuszczać przez jakieś narzędzie do mapowania, które nam powie i ujednolici, czym to właściwie te elementy są.
Łukasz Kałużny: Raczej Focus pomaga Ci powiedzieć, że masz to pochodzące na przykład w jednym tym, że na przykład będzie taki sam… Raczej service name trafi w jednym wystandaryzowanym formacie, bo każdy ma go inaczej opisanego w rachunku.
Szymon Warda: Tak, więc jeżeli chodzi o Focus, mamy duże nadzieje. Oby się wydarzyło. Praktyki?
Łukasz Kałużny: Wiesz co, jak pójdziemy sobie na narzędzia, to ja bym to rozbił na 3 elementy. Pierwsze, te natywne dostawców chmur, czyli mamy w AWS-ie Cost Explorer, budgety i inne te elementy. W Azure będzie cost analysis i budgets i też ten advisory, AWS tak samo ma Advisora, czy podobne elementy w GCP. Oni chyba mają FinOps Huba i Cloud billing + recommender. Więc tam jest ileś takich elementów, które są te narzędzia. I to jest rzecz istotna, że zespół powinien móc zobaczyć koszty i powinniśmy mieć setupowane w tych narzędziach budżety i alerty. Alerty na przekroczenie, alerty na przekroczenie forecastu, bo to jest istotne. Teraz ktoś może mi zarzucić, całkiem słusznie, że na przykład w Azure forecasty nie działają prawidłowo i są, mają ssanie, ale są good enough.
Szymon Warda: Znaczy inaczej, nie to, że nie działają prawidłowo. One mają pewne założenia, które nie zawsze się sprawdzają.
Łukasz Kałużny: Jak referencyjne architektury.
Szymon Warda: Dokładnie. One przyjmują, że skoro tak używasz, tak będziesz używał i będzie pewien wzrost, cały czas będzie sobie szło do góry. Tak to wygląda. Ale z reguły sama wartość, liczba wystarczy, bo z pewną wiedzą, co właściwie robiliśmy, jak to wygląda, będzie w porządku.
Łukasz Kałużny: Tak. Następny element, który bym tutaj, słuchajcie, dorzucił, to jest coś, co nastawione na duże firmy, czyli third party produkty. I z tym mam tutaj taki problem, że one wyglądają zwykle, działy jakieś właśnie takie, może nie zakupowe, tylko zajmujące się w dużych organizacjach, jakby to ładnie teraz określić, szukam prawidłowej nazwy na to.
Szymon Warda: Pilnowanie pieniędzy.
Łukasz Kałużny: Tak, pilnowaniem pieniędzy w IT. Szukają. Jednym z takich przykładów, które widziałem w praktyce, które nawet dobrze to pokazywało, to były softy od licencjonowania właśnie typu Snow od Software Asset Managementu. Tam one się pojawiają. Też multum produktów się pojawiło od VMware chyba, nie wiem, czy tego nie porzucił. IBM miał coś swojego. Plus parę innych rzeczy na tym wyleciało. I jak jesteśmy przy, byliśmy przy Focusie, warto bym zaznaczył, jest takie rozwiązanie, które nazywa się Open Cost, które też jest teraz w tym, w zeszłym roku trafiło do inkubacji CNCF-u. I z Open Cost, to co bym dorzucił, to jest to, że już od dwóch lat podpięli się pod tą inicjatywę Focus. To jest pierwsza rzecz. Druga rzecz, mają ciągle w becie taki moduł od, musiałbym sprawdzić czy w becie dokładnie, ale mają też moduł od raportowania kosztów cloudowych, w takim podejściu multi cloud.
Szymon Warda: Raczej tak patrząc po tym co się dzieje w repo, to… Znaczy jaki mam z tym problem? Tam głównie są trzy osoby aktywne, ale w ciągu ostatniego miesiąca zamknęli ponad 121 issue’sów. To jest dużo.
Łukasz Kałużny: Raczej tak, jeżeli tam popatrzymy, tych commitów jest sporo. To nie jest tak, że o: adding filtering allocation API, tutaj ten. Co tam dalej? Trim port name for node. Dobra, to nie, fix data structure of response, raczej ciągle tam coś się dzieje. To nie jest tak, że to są skrypty podbijane, tylko ciągle taki powolny, spokojny rozwój na developie jest robiony. Więc jest to, można powiedzieć i to, że jest ciągle develope na głównym ustawionym domyślnym branchu, to też mówi, że to się rozwija troszeczkę. Więc tutaj jest i tak jak popatrzymy właśnie jedno to jest Kubernetes, a drugie takie realne multi-cloud cost monitoring dla tych trzech dużych dostawców + set pluginów i rzecz przyjemna, wystawianie metryk prometheus’owych Szymon, tego wszystkiego z API jako Prometheus.
Szymon Warda: Tak. Potem powiemy sobie często cały FinOps wykłada się na tym, że: no bo mamy klaster Kubernetesowy i tam mamy wszystko właściwie i liczymy koszt tego jako jeden klaster, a to też można ładnie rozbić. Kubernetes też daje możliwość rozbicia wewnątrz.
Szymon Warda: Open Cost, Cube Cost takie coś pokazuje. Dorzuciłbym jeszcze jednego toola akurat terraformowego w tym miejscu, ale tam jest też cała dziedzina, czyli Infra Cost.
Szymon Warda: Właśnie tak zastanawiam się czy o nim nie zapomniałeś. Dokładnie.
Łukasz Kałużny: Nie, to właśnie chciałem jako kolejne. I to jest trochę w ramach takiej dojrzałości. Czyli Infra Cost, słuchajcie, pozwala Wam… Jest to niby open source, ale cała wartość polega na tym, jak wstawicie to z pełną licencją, ale pozwala Wam na pull request na przykład zobaczyć, jak potencjalnie może się zmienić cena. Czyli robicie sobie na pull request, analizujemy pull request ze zmianą w Terraformie i na podstawie pliku stanu i dostępu do API billingowego jesteśmy potencjalnie w stanie wyliczyć, ile może się zmienić nasz rachunek przez wprowadzoną zmianę.
Szymon Warda: Tak, tylko błagam, to nie jest tylko po to, żeby patrzeć na wpis w logu, tylko żeby potem od tej wartości zrobić inny flow akceptacji pull requesta, ewentualnie który wchodzi na produkcję albo gdziekolwiek indziej. Nie budujmy kolejnych dashboardów tylko po to. Taka moja mała uwaga.
Łukasz Kałużny: Tak i przyjemne jest w sumie, że pierwsze 10 aktywnych inżynierów, jak to oni określili, kosztuje tysiaka miesięcznie za 10 osób. I to teraz mówi, że jak bardzo, że trzeba trochę większej, większego rozmiaru, żeby to miało sens używania.
Szymon Warda: Dokładnie. Dobrze. To co, lecimy chyba przez taki mega sensowny obszar teraz. Metryki.
Łukasz Kałużny: Tak. I słuchajcie, takie trzy obszary mamy, które są z FinOps Frameworku. To są takie ekonomiczne. Potem mamy efektywność chmury i metryki budżetowe. I słuchajcie, te metryki ekonomiczne, one są mocno biznesowe, ale użyłem już ich dobre tam z 7-8 lat temu, jak FinOps Foundation nie było, to są koszt per transakcja i koszt per klient naszego rozwiązania chmurowego.
Szymon Warda: I to są bardzo ważne metryki. Czasami jest ciężko je policzyć i ciężko mapować, głównie ciężko przez opór biznesowy i jak do tego podejść tak naprawdę.
Łukasz Kałużny: Raczej tylko, że to mówimy ile kosztuje nas infrastruktura chmurowa na użytkownika miesięcznie. To jest takie coś, trzeba popatrzeć. I słuchajcie, ja miałem taki projekt IoT konsumenckiego, gdzie referencyjna architektura, gdybyśmy robili to referencyjną architekturą, to ubijała projekt. Po prostu referencyjna infrastruktura IoT Microsoftu ubijała projekt. Po prostu już na papierze koszt użytkownika miesięczny utrzymania urządzenia nie spinał się w ogóle finansowo z zyskiem.
Szymon Warda: Mam bardzo podobną sytuację, też właśnie w IoT, że kompletnie się nie skalowało. Okazało się, że bardzo proste zmiany, jeżeli chodzi o użycie i projekt właściwie jest niezauważalny, jeżeli chodzi o koszty. Tak że można.
Łukasz Kałużny: I wyszło na to, że taniej jest… To jest ta rzecz, mokry sen niektórych osób, że taniej było to nakodować samodzielnie względem zestawu feature’ów, które były potrzebne.
Szymon Warda: To tu akurat zejście z paru wymagań spowodowało, że koszt poleciał bardzo mocno w dół. Dobrze, efekty, czyli tu jakie mamy? Cost per transaction, cost per customer. Dalej idziemy.
Łukasz Kałużny: I to jest ważne, w szczególności jak idziemy, to nie jest system wewnętrzny, tylko patrzymy na efekt skali, jest to główny system w firmie, warto zobaczyć.
Szymon Warda: To też nie musi być super dokładne. Nam chodzi o trend, ogólną wartość uśrednioną mimo wszystko.
Łukasz Kałużny: Tak, jest to dla firm produktowych żyjących trochę z techu można powiedzieć, że ten system informatyczny, jak to ładnie się określi, realnie wspiera biznes i na nim jest największa marża, zysk firmy generowany.
Szymon Warda: Dobra, to teraz idziemy w drugą stronę kompletnie - metryki efektywności chmury. I tam utilization rate i waste percentage, czyli coś, co właściwie możemy samodzielnie sobie spokojnie polecić. Czyli to, co mamy, jak bardzo jest zużywane i ile rzeczy jest osieroconych, bo one będą występowały.
Łukasz Kałużny: Tak.
Szymon Warda: Tu warto powiedzieć o targetach, czyli jakie cele chcemy mieć. Utilization rate - utylizacja na poziomie 80-90% dla większości zasobów. To jest ważne w większości i to też jest średnia, jak to będzie wyglądało. Waste percentage - mniej niż 5% zasobów w formie sierot, czyli nieużywane, niepotrzebne.
Łukasz Kałużny: Tak. Jeżeli chodzi o utylization rate, to trzeba powiedzieć sobie, tak jak powiedzieliśmy o tych alertach na nieużywanie zasobów. Chodzi o to, żeby nie przepalać gotówki na to, że coś stoi włączone i jest prawie nieużywane.
Szymon Warda: Dobra, to teraz ostatnia grupa.
Łukasz Kałużny: Dobra.
Szymon Warda: Budżetowe.
Łukasz Kałużny: Tak, i tutaj jest budget variance, czyli różnica między aktualnymi a budżetowanymi kosztami. Czyli faktycznie w jaki sposób… Żeby śledzić, czy to, co zaplanowaliśmy jest faktycznie wykonywane. I tutaj jest, dla niektórych może być to bardzo duży, dla niektórych bardzo mały odchył, w zależności jak popatrzymy, bo mówi, że akceptowalny taki odchył na tym KPI powinniśmy powiedzieć pomiędzy 5 a 10% niezgodności.
Szymon Warda: To są małe odchyły mimo wszystko.
Łukasz Kałużny: W zależności… Słuchaj, tylko że wiesz, od skali jeżeli masz milionowy rachunek na przykład rocznie, to już te 10% jest widoczne. To wiesz, wszystko zależy od skali.
Szymon Warda: Tak. I ostatnie to jest właściwie forecast accuracy, czyli to właśnie, co przewidywaliśmy, jakie będzie, jak dokładnie to wygląda. To jest o tyle ważne, żeby wiedzieć, czy projekt zaczynać i na czym będzie chodził. Bez przegięcia tutaj należy, bo to może prowadzić do tego, że będziemy robili oversizing, więc też trzeba być człowiekiem.
Łukasz Kałużny: Tak, forecast accuracy, właśnie jak blisko ten spending jest zgodny z forcastem, bo to jest w tym. I słuchajcie, tutaj widziałem już over engineeringi własnych modeli ML-owych, żeby lepiej robić anomaly detection i inne rzeczy. Wiecie co, to jest taki KPI, tak jak powiem, że jakbym miał powiedzieć jakie stąd KPI-e zaimplementować, to jest utilization rate, który da się zautomatyzować, waste precentage i odchyły od budżetu. To są takie trzy metryki, które powinniśmy śledzić. Na przykład dokładność forecastów, jeżeli nie idziemy w customowe toole i inne takie rzeczy, nie ma sensu tego na przykład dotykać i patrzeć na ten KPI.
Szymon Warda: Nie ma sensu. To Wam trochę wyjdzie z założonych budżetów u dostawców chmurowych. Tam będziecie mniej więcej widzieli jak to wygląda. Dobrze. To co, zbierzmy ten temat do kupy, powiedzmy co nie, jak my to widzimy i takie jak do tego w ogóle podejść realnie.
Łukasz Kałużny: Dobra, FinOps Framework z pudełka to kobyła.
Szymon Warda: Rozdmuchane dla naprawdę dużych, dużych organizacji.
Łukasz Kałużny: Jest rozdmuchany. Jest mądra rzecz, która tam jest powiedziana, że poziom dojrzałości w obszarach powinieneś dopasować do swoich potrzeb i możliwości. Tutaj za to jest chapeau bas. Ale ja bym powiedział, że powinniśmy mieć…
Szymon Warda: Czy to była referencja z Mikołajka? Chapeau bas!
Łukasz Kałużny: Było w tym…
Szymon Warda: Pozdrawiamy przedszkolaków.
Łukasz Kałużny: W tym, aż będę musiał sprawdzić, bo teraz to…
Szymon Warda: To jest z Mikołajka.
Łukasz Kałużny: Dobra, ale wracając, bo mnie wybiłeś. Więc FinOps Framework, jego taka pełniejsza implementacja, to są, powiedziałbym w zależności ile tego przepalamy i czy mamy ten pierwszy etat, który zajmie się tym full time, bo to jest w ogóle praca w… Realnie, jeżeli popatrzymy, to jest praca trochę full time’owa, pilnowanie takiej rzeczy.
Szymon Warda: Jest. Ale nawet jeżeli chodzi o samego frameworka, to ten pierwszy etap dojrzałości wydaje mi się, że jest krytyczny, żebyśmy wiedzieli, co wydajemy, żebyśmy mieli budżety. Etap, na którym możemy wiele rzeczy ogarnąć technicznie, bez angażowania całej organizacji.
Łukasz Kałużny: Czyli można powiedzieć, że powinniśmy polecieć w przeglądy, nawet cykliczne przeglądy. Szybki przegląd, powiedzenie sobie co i jak. Alerty i budżety w narzędziach dostawców.
Szymon Warda: Jak najbardziej. Tym bardziej, że te przeglądy i alerty często mamy z pudełka u dostawców. To nie jest duży wysiłek.
Łukasz Kałużny: Rezerwacje. I teraz rzecz, która będzie, metryki, to jest już taki dalszy krok, robienie właśnie tego. Śledzenie pierwszej to utilization RAID, a reszta metryk to już potem. Bo pamiętajcie, budżety też pozwolą na popatrzenie na te metryki w skali. I ostatni element to review architecture i rzeczy, które mamy wdrażane. I chyba z tego najważniejsza myśl, którą widzimy na co dzień u klientów, to nie boimy się różnego rodzaju skalowań.
Szymon Warda: Tak i automatycznie i kronowych.
Łukasz Kałużny: Tak, czyli właśnie dynamiczne skalowanie poprzez dodawanie, zabieranie. Albo tak jak Szymon powiedział, że on/off na przykład tam, gdzie się da włączyć/wyłączyć usługę. Czy rzecz, która jest straszna, że założyliśmy albo dostawca założył w projekcie, że będzie taki size i jest strach przed zmianą i opór przed zmianą zasobu na przykład w dół. To jest też częsta rzecz.
Szymon Warda: To jest z takich rzeczy, małe pierdoły, ale to też potrafi dać niezłe oszczędności mimo wszystko. To są te odpowiednie archiwizacje danych na blobach. To też potrafi długofalowo, szczególnie jeżeli chodzi o retencję danych, na przykład musimy przetrzymywać ze względu na prawne rzeczy, potrafi też sporo kasy zaoszczędzić.
Łukasz Kałużny: No tam gdzie, ale musisz mieć tego sporo, żeby odczuć to na rachunku.
Szymon Warda: Widywałem takie rzeczy.
Łukasz Kałużny: Dobra.
Szymon Warda: To co? Tyle.
Łukasz Kałużny: To co? Trzymajcie się. Na razie.
Szymon Warda: Hej.