Ostatnie Patoszkolenie w tym roku👇
Patoarchitekci short po raz kolejny zadziwiają swoim znaleziskiem! Czy komputery naprawdę zaczęły czytać ludziom w myślach?
Ciekawe linki i inne znaleziska z tego odcinka:
Łukasz Kałużny [ŁK]: Cześć! Słuchacie Patoarchitektów w wersji short. Prowadzą Łukasz Kałużny
Szymon Warda [SW]: i Szymon Warda. Linki do tego odcinka znajdziecie na: patoarchitekci.io/43. I oczywiście dodam, że jest to format eksperymentalny, trochę krótszy. Dajcie feedback. Skupiamy się na tym, co widzieliśmy, słyszeliśmy i co nam chodziło po głowie przez ostatni tydzień. Dobrze, Łukaszu, co u Ciebie?
ŁK: Dobra. U mnie teza obserwowalna z tego roku. Nazwijmy ją: powolny koniec free tierów w usługach PaaS-owych, SAS-owych i cloudowych. W tym roku widać, że parę rzeczy się kończy. Z ciekawostek, które można… bo aż sobie potem zobaczyłem… Z większych usunięć albo zmian, które były, to Google Appsach (Workspace’ach jak teraz nazywa swoje narzędzie do pracy grupowej Google) darmowy tier z customową domeną w Gmailu. Poszedł tam częściowo… Po protestach trochę się zmieniło, ale de facto został już prawie totalnie przez nich ucięty. To jest jedna rzecz, która się pojawiła. Druga ciekawa (i następne dwa ogłoszenia będą z tej samej firmy), to Slack, który dość mocno zmienił swój free plan. Od 1 września wchodzi, że nie będzie można przechowywać dłużej wiadomości – po 90 dniach będą znikały. Więc mamy przycinanie. I trzecią rzeczą, która się pojawia i też jest ciekawa, to Heroku zaczyna mocno przycinać swój free plan.
SW: Tak, ale czy to Cię zaskakuje? No bo od czego są free plany? Od tego, aby zobaczyć, czym jest dana usługa, bo pewnie jej nie znasz. Więc się zapoznajesz. I zobacz business value. Czy Slack lub Google Apps trzeba jeszcze komukolwiek przedstawiać?
ŁK: Nie. Wiesz co… Właśnie. W zależności jak patrzeć na Discorda. Bo czy Slacka powinniśmy bardziej porównywać z Teamsami czy też z Discordem? To dość mocno zależy od punktu widzenia. Więc tak: hobbystyczne rzeczy bardzo mocno przycina. Z Heroku chyba właśnie… Też o tyle… Bo co ważne: Slack i Heroku należą do tej samej firmy, do Salesforce’a.
SW: A to tego nawet nie wiedziałem.
ŁK: Tak.
SW: To wszystko są usługi, które Heroku ma długo na rynku. To są usługi, które znamy i one po prostu free tiera nie potrzebują tak naprawdę.
ŁK: Wiesz co…
SW: Powiedziałbym, że też się zmieniają warunki rynkowe.
ŁK: Znaczy… Heroku było ciekawe, bo przez wiele lat stanowiło dla wszystkich, jako do proof of content’ów, MVP jako pierwszy wybór. Jeżeli nie programowałeś w Javie albo w .NET tylko w Rubym, Pythonie czy NodeJS to ta platforma była bezproblemowa. I jest…
SW: Zgadza się jak najbardziej.
ŁK: I jest bezproblemowa. Mieli w tym roku mocną wtopę, kiedy GitHub ich odciął (śmiech) za wyciek tokenów i nie można było deployować. Ale to już inna rzecz. Ale ciekawostka jest, że one będą właśnie teraz prawdopodobnie… W innych usługach też zobaczymy pewnie cięcie, bo patrzymy coraz bardziej na marżę i efektywność tego. I ten próg, to co powiedziałeś właśnie: próg znania rynku jest bardzo wysoki już w wielu miejscach.
SW: Tak. Ale to też bardzo fajnie pokazuje – przechodzimy teraz płynnie do mojego linku. U mnie znowu co innego… O tym, że revenue, czyli zyskowność z usług chmurowych na obecny kwartał jest tak naprawdę poniżej oczekiwań. Nie spadła, nie jest na minusie, tylko jest poniżej oczekiwań. Jest super fajny komentarz Satya Nadella odnośnie do całej sytuacji. On skwitował to tak, że to nie jest sytuacja, że klienci się wycofują z chmury. Nie. Oni po prostu… Cały Microsoft widzi dużo więcej ruchów w kierunku optymalizacji tego, co jest i optymalizacji kosztów, jeżeli chodzi o przenoszenie rzeczy i prace wokół tego. Czyli – jak on to ładnie nazwał – ludzie chcą więcej wycisnąć z chmury jako takiej. Google oczywiście też nie mógł ominąć tego, że w kontekście niepewnej sytuacji gospodarczej (bo taką mamy, nie oszukujmy się), to właściwie chmura może być całkiem niezłym wyborem z prostego powodu: nie robimy dużego kosztu na raz, a potem możemy tę usługę ładnie rozłożyć, tak że… Przechodząc już konkretnie do tego, co nas czeka tak naprawdę – wydaje mi się, że będzie nas czekało dużo większe pilnowanie kosztów, dużo więcej projektów optymalizacyjnych i dużo lepszy governance, nadzór nad architekturą i kosztami. Czyli hm… Wydaje mi się, że może to się skończyć czymś dobrym tak naprawdę.
ŁK: Wiesz co… Tak. Zobacz na przykładzie naszych konsultacji w Protopii: w czerwcu mieliśmy klienta, u którego trzeba było ściąć rachunek o połowę. Dosłownie było powiedziane, że o połowę, bo się nie spina. I się okazało, że to nie była żadna straszna rzecz, bo architektura i inne rzeczy, usługi nie były upilnowane.
SW: Tak. Nawet jak rozmawiamy z innymi klientami, bo Ty mówisz o audycie nastawionym wyjątkowo na obcięcie kosztów…
ŁK: Kosztów, tak.
SW: Ale jak przekazujemy cokolwiek, to jest opcja, że „Generalnie ok, tak wyglądają koszty”, i wokół kosztów jest więcej zasadnych pytań, które po prostu weryfikują architekturę. Nie ma takiego podejścia, że: „A! Dajmy. Będzie w porządku. Byleby się tym nie interesować”. Bym powiedział, że to nie jest zły obrót sprawy.
ŁK: Dokładnie. Patrząc na możliwości, jakie są na poziomie: rezerwacje, governance (o którym wspomniałeś), tak jak patrzymy znowu – odwołując się trochę do naszego poprzedniego odcinka o platformach – to jeżeli popatrzymy na całość, to governance i dyscypliną, w szczególności kulturą zarządzania kosztami na enterprise’owych, można naprawdę zdziałać w niektórych przypadkach cuda z kosztami.
SW: Tak. To też, jak najbardziej. Nawet automatyzacja, jeżeli chodzi o włączanie, wyłączanie czy skalowanie usługi dalej. Mimo że chmura to oferuje, ale jak popatrzymy, to są często obszary, których (jak patrzymy po audytach) u większości klientów tego nie ma.
ŁK: Tak. I jest w ogóle… Słowo „skalowanie” jest straszne dla większości, bo nie wiemy, jak skalować.
SW: To nie jest jednoznaczne, a ponieważ jest na tyle trudne do zrobienia, większość ludzi stwierdza: „Ok, nie róbmy tego, bo nie mamy żadnego powodu, żeby to robić”. No bo: „Ah! Płacimy tylko trochę więcej”. Ale w skali całej organizacji to się zbiera.
ŁK: Tak. Jeden pro tip (żeby było trochę mięsa technicznego) – jeżeli macie K8s-a, jest narzędzie, które nazywa się Keda. Ono jest od RedHat z Microsoftu i służy do… (Nawet chyba w którymś odcinku o nim wspominaliśmy…)
SW: Tak było.
ŁK: …służy do skalowania się na eventy. I może się okazać, że nie będzie Wam pasować, jak macie statyczną aplikację, ale ma piękną rzecz: skaler, który nazywa się Cron. Czyli możecie zrobić harmonogram i powiedzieć, że w godzinach roboczych trzymacie np. 3 instancje aplikacji, tak żeby mieć SLA, SLO i żeby wszystko się zgadzało. A potem w K8s-ie zmniejszacie i ustawiacie, że w harmonogramie nocnym ma być tylko 1 pod. Jeżeli autoskaler do NOD-ów macie włączony…
SW: Albo […
ŁK: Tak. Razem z Kedą, to nagle się okazuje, że klaster idzie spać pod kołderkę, utrzymuje aplikację tylko w statusie running, a z rana rozrasta się do rozmiarów produkcyjnych. I to jest jedna z takich rzeczy, które bardzo często zdarza mi się rekomendować. I to działa, jeżeli chcemy przyciąć koszty.
SW: Ja dorzucę jeszcze… Powiedziałem MSI i RedHat, bo to jest projekt CNCF
ŁK: Tak, tak. Ten CNCF-a.
SW: To jest też ważne.
ŁK: Ten CNCF-owy, ale zapoczątkowany przez nich i oddany. O!
SW: Tak, więc… Też zgodzę się – Keda jest mega fajna. Chciałem też powiedzieć, że fajnie integruje się z innymi systemami i usługami, które można stawiać w K8s-ie. Tak że… Tak – zdecydowanie dobry strzał. Jest jeszcze drugi link, który mam do podrzucenia. Całkiem fajny artykuł od Stack Overflow odnośnie zespołów i mierzenia velocity i tego, czy high-velocity teams częściej się nie wypalają. Artykuł nie jest o wypalaniu, ale jest bardziej o tym, jak mierzyć wydajność zespołów. I to się jeszcze nakłada na ciekawy wpis, prezentację z konferencji Strange Loop. Swoją drogą dobra konferencja, która mówi właśnie o tym, jak mierzyć. Mój wniosek z tego jest taki: po pierwsze mierzymy outcome, czyli co my z tego mamy faktycznie. Mierzenie velocity jak każdą metrykę można ograć. Velocity też można ograć. Nie ma większego sensu. Zespół może pracować szybko, nazwijmy tak ładnie politycznie, ale może po prostu nie produkować niczego ważnego. Zespół to jest też m.in. product owner, który ma produkować wartość biznesową. Więc mniej więcej są takie: wiemy, że zespół pracuje dobrze. To czuć po prostu. A druga to: mierzymy po business outcome’ach, w sensie: jaka jest wartość biznesowa tego zespołu i co oni wyprodukowali. Nie ma innej metryki poza tymi miękkimi, które mierzymy generalnie ankietowo: zmęczenie zespołu itd. To sobie zmierzymy spokojnie ankietami i to są miękkie metryki. To inna bajka. Ale takie typowo value metryki mierzymy tylko i wyłącznie w tej sposób. Na mój gust.
ŁK: Wiesz co… Zostałem wrzucony przez Szymona w to na zasadzie: wiesz co, dorzucę ci link. Zobaczymy, co powiesz. (Śmiech)
SW: Bardzo fajnie.
ŁK: Tak. I jak na to patrzę, to muszę się z tobą niestety zgodzić. Tak jak jakość jesteśmy w stanie zmierzyć (deploymenty i inne rzeczy wokół technikali) oraz to, jak zespół dostarcza pewne technikalia jesteśmy w stanie określić metryki jakościowe, niezawodnościowe.
SW: Tylko dorzucę jedną rzecz z tymi metrykami. Często widzę, że te metryki jakościowe są wrzucane na pałę, w sensie: „A tak musi być, bo tak jest”. Są dwa podejścia: albo robimy super i rzadko wydajemy (bo tak to najczęściej wygląda), albo wydajemy często, czasami rzeczy psujemy, ale super szybko naprawiamy. Jakość to nie zawsze jest to samo w każdej organizacji. To jest bardzo, bardzo ważne.
ŁK: Tak. Dobra wrzuta. I trzeba po prostu popatrzeć na te wskaźniki w czasie. Bo one, tak jak powiedzieliśmy, będziemy mieli w pewnym momencie… Organizacja zespołowi pozwoli być naprawdę zwinną. I najważniejsze co powiedziałeś: jest czas przywrócenia do życia, naprawy tego, ale żeby w okresie ten trend nie był szorujący o podłogę. Czyli żeby był utrzymany na, że tak powiem, stałym poziomie, a nie był na równi pochyłej w podłogę.
SW: Tak, ale to znowu wracamy do tego, że mierzymy outcome. Czyli mierzymy fakt, jak długo był błąd na produkcji albo jak długo był downtime. To są znowu business outcome tak naprawdę.
ŁK: Tak, dokładnie. Druga rzecz to jest to, co powiedziałeś: jeżeli mamy ludzi, to mierzenie wszystkich velocity, gwiazdek, punktów czy jak to nazwiemy (nienawidzę tego)… Najgorszym jeszcze jest ilość commitów, bo… (śmiech) znam…
SW: Widziałem, powiem szczerze… (śmiech)
ŁK: Żałujcie, że nie widzicie miny Szymona w tym momencie. Niekiedy na zrobienie 10 linii w kodzie potrzeba tygodnia zastanawiania się, gdzie je umieścić albo wyciąć.
SW: Doskonale wiem, jak to wygląda. Nie, ale…
ŁK: Dokładnie. Więc…
SW: Jeżeli miałbym liczyć commity… to tego jeszcze nie widziałem.
ŁK: Tak. A ja widziałem. Widziałem takie uśrednienia. Więc patrząc, powiedziałbym, że manager techniczny, osoba odpowiedzialna za tak naprawdę dowożenie wartości biznesowej, jest w stanie zobaczyć czy zespół dowozi, czy nie dowozi. Takie… Chcielibyśmy wszystko zmierzyć, naszą wydajność, ale dochodzimy do momentu, że w bardzo wielu miejscach się nie da.
SW: Tak. Wniosek jest taki, że nie powinniśmy pewnych rzeczy próbować ułożyć w liczby, bo próbowanie ułożenia pewnych rzeczy w liczby się nie uda albo spowoduje, że ludzie zaczną to ogrywać po prostu.
ŁK: Znaczy… Cały problem KPI, które są publiczne. Znaczy, co do mierzenia… Patrzenie ze swojej perspektywy, tak naprawdę, jak performuje zespół, ale nie robić… To też może powiedzmy jedną rzecz, bo to jest z mojej perspektywy istotne: takie rzeczy jak velocity, swoje patrzeć, jak zespół dowozi inne rzeczy, jako taka metryka próbując porównać niektóre elementy na podstawie magicznych osobomiesięcy albo innych rzeczy, też się przydaje z jakiegoś punktu widzenia, żeby mieć jakiś odnośnik. Ale to nie powinien być sam w sobie stricte KPI dla zespołu, który go zna i nim operuje.
SW: To są… To są KPI wewnątrzzespołowe. Ale nie są to rzeczy, które publikujemy. I broń cię panie boże, nie porównujemy go zespołowo. Bo to już w ogóle nie ma żadnego sensu, absolutnie.
ŁK: Tak. Można sobie patrzeć. Dobra. To kończymy.
SW: Kończymy. Tyle. Cześć!
ŁK: Cześć! Na razie!