Chmura jest jak alkohol – część 1

Chmura jest jak alkohol – część 1

Łukasz Dziekan 2 lutego 2018

Minęło kilka miesięcy, od kiedy opublikowałem swój pierwszy wpis o naszej przygodzie z chmurą. Wtedy trochę narzekałem, trochę chwaliłem. Prawda jest taka, że jako team wiedzieliśmy wtedy niewiele. Teraz mamy już za sobą solidne 8 miesięcy pracy. Chciałbym Wam trochę opowiedzieć, czego można nauczyć się przez 8 miesięcy ze zgranym zespołem programistów, który pierwszy raz działa w chmurze. I właściwie czemu chmura jest jak alkohol i w ogóle gdzie jest to piwo/wódka/wino/whisky (niepotrzebne skreślić).

Chmura nie jest lekarstwem – tylko narzędziem. Jeśli coś robisz suboptymalnie albo po prostu źle, to będzie Ci jeszcze łatwiej popsuć to przy pomocy chmury. Z kolei jeśli robisz coś dobrze lub świetnie, to chmura pozwoli Ci wzbić się na jeszcze wyższy poziom i wyskalować Twoje rozwiązanie. Uważam to za zaletę – wbrew pozorom.

Chmura jest jak alkohol – wzmacnia dobre i złe strony w Twoim teamie

Od początku przygotowywałem zespół na to, że pewnie się pomylimy, a niektóre rzeczy będziemy musieli przepisać na nowo po pierwszej iteracji. Z drugiej strony staramy się być maksymalnie czujni na nowym gruncie. Analizujemy, co idzie gładko, a z czym są problemy. Dzięki temu mamy możliwość wprowadzenia konkretów w sposobie tworzenia architektury lub oprogramowania i wychodzenia na prostą. Bo rzeczy złe dość szybko stają się bardzo złe albo nie do wytrzymania. Dodatkowo należy pamiętać, żeby usługi PaaS stosować z umiarem i baaardzo dokładnie testować – pod kątem customizacji/performance’u. I koniecznie chować je za abstrakcją własną, bo przecież kiedy urośniemy, możemy nie potrzebować vendor locka – takiego implicite, np. na service bus. Inaczej mówiąc, trzeba wykorzystać, ale nie wolno się uzależniać. Inny przykład – weszliśmy dość mocno w użycie baz dokumentowych. Zupełnie inne modelowanie domeny i warstwa persystencji niż SQL. I kilka modeli zrobiliśmy mocno nieoptymalnie (wyszukiwanie działało bardzo wolno), ale z drugiej strony powiedzieliśmy sobie, że jak nie działa, to zmieniamy. Migracja pomiędzy modelami jest faktycznie dużo lepsza w NoSQL, i to zostało wykorzystane. Pewnie jeszcze zmigrujemy kilka razy. Właśnie tu chmura pomogła – szybko stworzyliśmy nowe bazy, zrobiliśmy skrypty migrujące i nie trzeba było sprawdzać, czy miejsca na dyskach starczy.

Na koniec wstępu jeszcze jedna ważna rzecz: to, że korzystamy z chmury (która jest dość grubą abstrakcją) na sprzęcie, sprawia, że nie możemy o tym zapomnieć. Tam, koniec końców, jest procesor, ram etc. – i takie rzeczy KONIECZNIE trzeba monitorować. Inaczej można obudzić się z niedziałającymi serwisami. Bardzo trudno będzie domyślić się, co tak naprawdę jest nie tak, bo wcale a wcale nie leci OutOfMemoryException 😊. Dopiero po jakimś czasie przychodzi pomysł i… facepalm 😊.

Powyższe zdania brzmią trochę jak coaching? Być może, ale poniżej przedstawiam kilka bardziej konkretnych przykładów.

1) Jeśli nie dbasz o czystość – zrobisz bałagan niesamowicie szybko

Tworzenie maszynek wirtualnych, komponentów w chmurze zajmuje sekundy/minuty. Przecież to jeden z głównych punktów sprzedażowych chmury, pokazujących przewagę nad infrastrukturą on-premise. Ale jeśli się tego nie zaplanuje, to bardzo szybko można utonąć i stracić rachubę. Dość powiedzieć, że jeszcze całkiem niedawno mieliśmy 27 instacji app insightów (co, jak się potem okazało, wynikało trochę z zamiaru planistów tego komponentu – my zdecydowaliśmy się mieć tylko kilka instancji), kilkanaście resource group, z czego kilka o niewiadomym zastosowaniu. Ale ogarnęliśmy się, bo… programiści zaczęli się gubić, a CTO przyczepił się do kosztów 😊. Wprowadziliśmy jednolity system nazewnictwa w subskrypcjach. Tutaj przydatne były dyskusje z Markiem Grabarzem (pozdro!) – stosujemy u nas {typ-zasobu}/{komponent}/{produkt}/{środowisko}/{GEO/opcjonalnle}. To na razie nam wystarcza. A przy okazji nauczyliśmy się, jak w automatyczny sposób zmieniać nazwy zasobów.

Co do strategii app insightów – mamy je per produkt i per środowisko. To oczywiście nie uwzględnia log managementu, ale powstanie o tym osobny wpis. Przy czym w branchu DEV wszyscy walą do tych samych app insightów – niezależnie od produktu. Dzięki temu udało się nam ogarnąć semantyczny logging i korelację logów. Kiedyś napiszemy więcej o app insightach, bo to potężne narzędzie jest. Dzięki tej jasnej strategii nazewnictwa zespół stał się bardziej produktywny, ponieważ diagnozowanie błędów, tworzenie skryptów deployujących przebiega szybciej. I wiadomo, gdzie czego szukać, używając portalu.

Bardzo trzeba uważać na domyślne ustawienia komponentów. Generalnie polecamy używanie RM template’ów per komponent, które nadpisują domyślne ustawienia – na takie, których używasz (np. włączona diagnostyka, opcje always-on etc.). Infrastructure as code jest naprawdę przepotężne – i choć jeszcze nie wszystko da się zrobić, a bywa, że czas upływa na długich godzinach szukania i kończy się rest-api albo powershellem – to zysk jest zauważalny.


2) Ulegasz złudzeniu „nieśmiertelności”

Wszyscy wiemy, że jeśli jesteś na rauszu, to czujesz supermoce, rośnie poziom pewności siebie (chyba że masz tryb upijania się na smutno). Otóż w Azure również można ulec temu złudzeniu. Jesteś adminem subskrypcji, więc tutaj szybko zakładasz maszynki, tutaj na szybkości przejrzysz logi, tutaj wywalisz komponent. Po prostu ROBISZ rzeczy. Dobrze? No właśnie nie bardzo. Wystawiasz się na niebezpieczeństwo. Posiadanie superuprawnień musi być ograniczone. Ale to z kolei spowalnia. I niestety zbudowanie dobrego systemu zarządzania uprawnieniami zabiera dużo czasu. W dodatku system uprawnień Azure jest baaardzo skomplikowany (podobnie VSTS). I nie da się tego zrobić bez automatycznych skryptów, dlatego konieczna jest delegacja obowiązków na więcej niż jednego akceptanta.

W FinAi jeszcze nie jest idealnie, ale lepiej, niż było na początku. 

  • Pamiętajcie o 2-factor dla wszystkich developerów.
  • Zabrońcie usuwania zasobów bez akceptacji drugiej ręki.
  • A potem stopniowo wprowadzajcie time-based principals (o tym też powstanie osobny wpis). My wprowadziliśmy i już kilka razy się to przydało – np. gdy migrowaliśmy appki na ASE.
  • I monitorujcie loginy.
  • Zróbcie VPN, jeśli pracujecie zdalnie.
  • Jeżeli integrujecie się z zewnętrznymi serwisami, używajcie firewalla, reverse proxy lub innego rodzaju API Gateway.
  • Wprowadźcie możliwość logowania tylko z zaufanych urządzeń (InTune).
  • Schowajcie środowiska deweloperskie za logowaniem do Waszego środowiska (np. AD lub inny LDAP). API Gateway jest ciekawym produktem, ale być może warto rozważyć nginx. 

Oczywiście temat jest tu bardzo spłycony, ale musicie zdawać sobie z niego sprawę. Tym bardziej, że jeśli używacie np. webappek, Wasze serwisy są domyślnie dostępne w internecie, a automatyczne roboty skanują podsieci Azure cały czas.

Jako że w FinAi traktujemy bezpieczeństwo strategicznie, szybko uciekliśmy od nieśmiertelności. I ja nie mam już supermocy – chyba że o nie tymczasowo poproszę (niektórzy proszę o sok z gumijagód, inni o power upa, taki wewnętrzny folklor). Warto wykorzystać keyVault – i trzymać tam wszystkie sekrety (najlepiej w więcej niż jednym keyVault na środowisko) i automatycznie wrzucić korzystanie z odpowiednich zasobów do procesu deployu + monitorować, kto się do Waszych sekretów próbuje dostać. Nie jesteście nieśmiertelni, a korzystając z publicznej chmury, musicie zmienić sposób myślenia, jeśli pochodzicie ze „świata” on-premise. W tym tekście wspomniałem kilka rzeczy, o których warto pamiętać – a jeśli zarządzacie taką firmą, która ma do czynienia z danymi, to jest absolutnie krytyczne.

3) Automatyzujesz i wygrywasz

W tym przypadku byliśmy w FinAi nieźli do początku. I tutaj Azure daje power milion. Na wszystko masz skrypt, choć za pierwszym razem, kiedy coś robisz, przekleństwa cisną się na usta. Jak wiemy, nie wszystko w Azure jest łatwo konfigurowalne lub udokumentowane. Ale NAPRAWDĘ prawie wszystko da się zautomatyzować. I to daje niesamowitego kopa, jeśli chodzi o produktywność. Nie tracisz czasu na konfigurację komponentów – prawie wszystko tworzy się za automatu (Ifrastructure as a Code przy pomocy ARM Templates), CI/CD tworzy się z automatu. Tworzysz sobie logic appa przerzucającego CV-ki na odpowiedni kanał w Teamsach. Robisz alerty na app insightach. Backupy robisz automatycznie – również odpowiednim logic appem – albo webjobem. 

Co ważniejsze, backupy automatycznie odtwarzasz (bo każdy backup jest tylko tak dobry jak informacje, które da się z niego odtworzyć). Migrujesz dane pomiędzy środowiskami w sposób automatyczny. Naprawdę: motywując od początku zespół słowami – „jeśli zrobiłeś coś raz, zrobiłeś to wystarczająco dużo razy” – możesz tylko zyskać. Jeżeli robisz coś ręcznie, to poświęć czas: na pewno są do tego API/ instrukcje powershella, logic app etc. Zyskasz ogromne poczucie efektywności czasowej, bo praktycznie zawsze kiedy będziesz coś robił, będzie to coś nowego. Poza tym wprowadzenie skryptów kilkukrotnie uchroniło nas przed błędami ludzkimi.

Oczywiście nie ma nic za darmo. Skrypty, jak każdy kod, trzeba utrzymywać, składować. Traktujcie je jak zwykły kod – trzymajcie w repozytoriach, a co wrażliwsze z nich testujcie (unit testy ftw:D). Naprawdę nie ignorujcie tego punktu: jeśli jest coś, w czym development w chmurze może Wam pomóc, to właśnie automatyzacja, przejście na kulturę devOpsową.

4) Monitorujesz albo się frustrujesz

Ponieważ masz dużo komponentów, tworzysz je automatycznie i nie masz łatwego dostępu do danych produkcyjnych, czasami rzeczy nie działają. Albo działają na przykład na playgroundzie devów, a nie działają na UAT. Albo na odwrót – to gorzej 😊. Generalnie diagnozujesz błędy, a jest ich coraz więcej. Programiści się frustrują, bo są od tworzenia nowej funkcjonalności, a nie od błędów. Zdolność wytwarzania oprogramowania zespołu spada (a powinna przecież rosnąć). Okazuje się, że monitoring i diagnostyka są niezbędne. Bez tego po prostu jest trudno. Przez kilka miesięcy zwyczajnie to ignorowaliśmy, bo przecież były ważniejsze rzeczy do roboty.

A potem, kiedy różne części systemu zaczęły dojeżdżać, okazało się, że nie współpracują ze sobą tak dobrze. I zaczęliśmy spędzać więcej czasu nad tym, co logujemy. Zrobiliśmy dedykowany middle-ware do tego. I czas diagnozowania błędów zaczął się skracać i skracać coraz bardziej. Postawiliśmy dashboard, który pokazał nam, czy komponent „leży”. Dużo technicznych logów pojawiło się w app insightach. Poprawiliśmy kilka miejsc, żeby correlation token jednoznacznie wskazywał ścieżkę requesta (zaczyna się na froncie i potem przechodzi, przez wszystkie wywołania komponentów, również tych Azure’owych jak na przykład serviceBus albo DocumentDB). Twoim przyjacielem jest trackEvent w telemetry cliencie.

Wrzuć jak najwięcej takiego trackowania, żeby wiedzieć, co się dzieje w Twoim systemie. To naprawdę pomogło – i do tego pozwoliło znaleźć kilka błędów. Co więcej, zmieniło sposób myślenia zespołu developerskiego. Zanim coś „zshipują”, myślą, czy wszystko, czego będą potrzebować, jest zalogowane: czy napisany jest health-check, czy jest skrypt monitorujący liczbę exceptionów… Czy każda wiadomość logów posiada nazwę źródła, applki, instancji, oraz jej kontekst. Mam nawet przyjazne ćwiczenie – nie debuguj, spróbuj dojść tylko z logów, co nie działa. Będzie to trudniejsze, niż Ci się wydaje, ale spowoduje, że Twoje logi staną się dużo bardziej przydatne. Dzisiaj diagnozowanie błędów zajmuje znaczniej mniej czasu i wywołuje mniej frustracji. Ale jeszcze nie jest idealnie – musimy dorobić logowania w rodzaju performance counterów, żeby dobrze diagnozować problemy z wydajnością, bo tutaj nie mamy dobrej widoczności. I kluczowe jest zrozumienie modelu app insightów – zarówno logicznego, jak i architektonicznego. On jest NAPRAWDĘ nieźle przemyślany. Wszystko to daje również zwiększony zwrot na inwestycji w automatyczne testy. Roboty chodzące po stronie zostawiają wiele śladów i można natychmiast diagnozować, czy coś przypadkiem nie padło. Jeśli nie jesteś dobry w monitoringu – popraw się. Inaczej licz się z dużą frustracją zespołu. Albo buduj monolit (ale wtedy nie wykorzystujesz potencjału chmury).

5) Życie to nie tutorial, czyli ciągle trzeba się uczyć

Azure i MSDN pokazują bardzo dużą liczbę tutoriali na wszelkiego rodzaju rzeczy. Microsoft na wszelkiego rodzaju prezentacjach pokazuje, jak szybko zrobić PoC. I nie można ich winić – wynika to z modelu sprzedaży skierowanej do sporych organizacji, a te do chmury podchodzą dość sceptycznie. Trzeba pokazać szybki upside, łatwość migracji. Jeśli jednak budujesz rozwiązanie, które od początku bazuje na chmurze, sprawy wyglądają trochę gorzej. Musisz dość głęboko przemyśleć działanie takiego komponentu jak ServiceBus (jak na przykład zaimplementować podpisywanie wiadomości albo konkurujących ze sobą konsumentów, jak zrobić serwis zarządzania topicami etc.) albo na przykład jak będzie modelować domenę w bazie DocumentDB. Z takimi bardziej in-depth materiałami jest już niestety znacznie gorzej. Tutaj muszę pochwalić, że chyba najlepszym źródłem informacji jest facebookowa grupa o Azure: https://www.facebook.com/groups/azureugpl/ – wielu ludzi siedzących w temacie, więc można liczyć na odpowiedź. Jednak ciągle trzeba wchodzić głębiej. Nie wierzcie w tutoriale, życie jest 10–100 razy bardziej skomplikowane. Tutoral nie powie Wam, jak skonfigurować service discovery, jak efektywnie zarządzać konfiguracją między środowiskami, jak zbudować architekturę systemu, która ma chronić dane użytkowników, jak budować modele na wrażliwych danych użytkowników, tak by nie opuszczały bezpiecznej strefy. Nie powie, jak robić backupy wraz z odtwarzaniem, żeby być pewnym, że Twoje dane faktycznie mają kopię zapasową, albo jak skustomizować application inisghty, tak by wrzucać w customdimensions correlation token pomiędzy serwisami. To są rzeczy wymagające poużywania tych komponentów, upuszczenia krwi i czasami wejścia w ich kod (np. na githubie jak tu Mierzenie performance na froncie w AppInisghts). Bądźcie głodni wiedzy, chmura tu nic nie upraszcza – jeśli już, to komplikuje, bo tak naprawdę Azure i dostępne tam usługi są znacznie bardziej skomplikowane niż .Net framework, który znacie z developmentu on-premise. Tylko ciągły głód wiedzy może Was uratować przed narastającą frustracją, dlaczego coś nie działa. To chyba tyle na razie w tym temacie. Mam nadzieję, że to pomoże Wam zrozumieć, przygotować się na zmianę związaną z prowadzeniem sporego projektu w chmurze.

A za tydzień kilka kolejnych punktów:

  1.  HA albo nie HA – oto jest pytanie.
  2. Chmura wspiera kulturę „own it, do it”.
  3. Komunikacja faktycznie jest potrzebna.
  4. Dane dają Ci prawdziwego kopa.
  5. Wdrażanie machine learning w praktyce.
  6. Wydajność i rozproszenie przychodzą Ci naturalnie.
  7. Musisz się uczyć, bo inaczej nic nie działa (ciągle jest jakiś preview albo coś zmieniają).

Podsumowując ten post. Tak – mieliśmy kilka miesięcy balangi. Spijaliśmy duszkiem to, co Azure miał nam do zaoferowania. Zdecydowanie byliśmy trochę na rauszu. Ale tu zaczęło trochę boleć, tam nie mogliśmy sięgnąć… Otrzeźwienie jest ważne. Trzeba patrzeć na symptomy i wyciągać wnioski. I weźcie pod uwagę, że FinAi tworzą ludzie, którzy mają średnio 8 lat doświadczenia w pisaniu naprawdę wysokiej jakości softu. Dlatego pilnujcie się, ustalajcie sobie zasady „wychowania w trzeźwości”. Z drugiej strony patrzcie też na Wasze silne strony, bo bardzo się tu uwidaczniają. Pozwalają nauczyć juniorów efektywnego podejścia. I wytwarzać kod znacznie szybciej niż bez chmury. Bo trzeba to powiedzieć: my jako FinAi nie chcemy już wracać do developmentu bez chmury. Jest ona dość uzależniająca przez to, że oddaje „sprawczość” w ręce programistów. I to trzeba wykorzystywać 😊.

 

Unia Europejska
Location icon Facebook icon Twitter icon Google+ icon LinkedIn icon Technology icon Business icon Marketing icon Phone icon Mail icon User icon Tag icon Bubble icon Arrow right icon Arrow left icon Calendar PR Contact