Dlaczego pracujemy na Microsoft Azure (Słońce między chmurami – część II)

Dlaczego pracujemy na Microsoft Azure (Słońce między chmurami – część II)

Łukasz Dziekan 29 maja 2017

Zgodnie z zapowiedzią z zeszłego tygodnia: oto drugi odcinek moich przemyśleń dotyczących Microsoft Azure i jej wykorzystania w FinAi.

W zeszły poniedziałek skupiłem się na problemach związanych z wyborem Microsoft Azure. Żeby tym razem nie było tak mrocznie, dziś opowiem o jasnych stronach tego rozwiązania.

Jak znaleźć „słońce między chmurami”, czyli o zaletach Azure

1. Przy Azure znacznie łatwiej myśleć „mniejszymi fragmentami” – poprzez używanie PAAS, którą traktuje się jako zewnętrzny mikroserwis, z którym po prostu się integrujesz.

2. Tworzenie Proof of Concept i wprowadzanie go w życie jest naprawdę bardzo łatwe!

Tworzysz sobie testową resource group, nadajesz jej kwotę (np. 100-200$), tworzysz instancje potrzebnych komponentow (np. chcesz sprawdzić, jak działa Service Bus), wykorzystujesz template do deployment i... siup! Możesz robić loadtesty i integration testy. I masz POC postawione w 2-5 dni (w zależności od skomplikowania tego, nad czym pracujesz).

3. Wyjątkowo wygodna jest integracja z VSTS – pozwala w bardzo łatwy sposób zarządzać z deployem. Jak już Ci się go uda skonfigurować.

4. App Inisights i App Analytics – pyszne! Zwłaszcza, jeśli jesteś data freakiem.

Pozwalają łatwo oprogramować semantyczne logowanie, mają świetny interfejs analityczny i pozwalają budować zarówno insighty biznesowe, jak i techniczne. Jednak niestety nie mają funkcji analitycznych (takich, jakie ma SQL). W razie, gdyby coś szło nie tak, ostrzegają przed tym alertami. Ale uwaga, co tydzień automatyczne maile od MS mogą się nie zgodzić z tym co widzisz w panelu. Nie przejmuj się i używaj tych danych. I poświęć trochę czasu na skonfigurowanie Telemetry Providerów i zrozumienie modelu danych.

5. Budowanie data-driven company jest stosunkowo łatwe... choć musisz uzbroić się w cierpliwość i testować różne możliwości przesyłania danych – zdolność obliczeniowa jest nie do skonsumowania.

Na przykład używanie Service Bus i dokładanie subscribera, który wkłada event do odpowiedniego storage'a (np. Lake, SQL lub ELK). Dodatkowo możesz sobie jeszcze postawić po drodze Steam Analytics i dokładać lub usuwać odpowiednie kolumny.

Innymi słowy: jeśli od pierwszego dnia myślisz o danych, to możesz spokojnie przygotować architekturę tak, by Cię w tym wspierała. W FinAi od pierwszego dnia mamy zespół Data Analytics i w następnych tekstach pokażemy, w jaki sposób podchodzimy do tematu zbierania danych i przygotowywania ich pod analizę.

6. Bardzo łatwo podzielić zasoby na środowiska devowe, testowe i produkcyjne, co pomaga zarządzać release’ami i testami.

7. Wielkie wsparcie dla automatyzacji, zwłaszcza opartej na PowerShell lub REST Api. Jeśli będziesz się pilnował, to zautomatyzujesz prawie wszystko. Z drugiej strony: jeśli nie będziesz automatyzował, to najprawdopodobniej po jakimś czasie utoniesz w komponentach. My już teraz mamy ich ponad 70 i ta liczba będzie rosła. Zaprzyjaźnij się więc z AzureRM i innymi skryptami powershellowymi.

8. To być może mniej ważne i brzmieć subiektywnie, ale dla nas zaletą jest to, że mamy poczucie „pionierstwa”. Odkrywania, jak coś działa w środku.

Programujesz ostrożniej i bardziej defensywnie, bo nie ufasz mechanizmom. A to może sprawić, że Twój kod będzie lepszy. A jak coś wyjdzie, to masz wielkie „high five!” w zespole. Bo wszyscy już wiedzą, że to nie są łatwe rzeczy. A na Stack-u gotowego kodu najczęśniej nie ma.

Co jeszcze powinieneś wiedzieć – garść porad

Na zakończenie tej notki: jeszcze kilka rzeczy, które pomogą Ci, jeśli zamierzasz rozwijać swój projekt w oparciu o Microsoft Azure:

1. W naszych okolicach Azure nie jest jeszcze zbyt często stosowany produkcyjnie, zwłaszcza z wykorzystaniem komponentów PAAS. Dlatego warto korzystać ze Stack Overflow, zadawać pytania i na nie odpowiadać. Wiele pytań jest nowych i odpowiedzi trzeba szukać u innych developerów. Dodatkowo: na Facebooku jest w miarę aktywna grupa o nazwie Microsoft Azure User Group Poland. Warto się tam zaczepić.

2. Jeśli masz znajomych MVP, to do nich pisz. Jeśli znasz ludzi z Microsoftu, to do nich pisz. Im bardzo zależy na tym, żeby chmura działała, więc będą chcieli Ci pomóc.

Wiele komponentów jest świeżych i w Polsce mało popularnych (np. Azure DocumentDB/CosmosDB lub Service Fabric) więc czasami trzeba używać Twittera i globalnych kontaktów.

3. Jak już korzystasz z Support Toola, to... bywa ciężko.

Support znajduje się w Indiach i komunikacja po angielsku bywa trudna. Ale warto go wykupić, żeby ustawiać urgency zgłoszeń na wysoki. Bo inaczej trzeba będzie przejść przez dwie linie supportu, które najpierw sprawdzą, czy dobrze opisałeś to. o co Ci chodzi…. Na szczęście potem są najczęściej kompetentni ludzie.

4. Tych 200 euro, które dają "na spróbowanie”, nie wystarczy.

Niestety Azure nie jest tani, więc trzeba liczyć się z wydatkami, żeby go poznać (choć da się go zoptymalizować). Z drugiej strony: kupowanie serwerów on-premise też kosztuje, więc dla mnie to nic nowego.

Chodzi mi jednak o to, by nie dać się „omamić” niskimi kosztami Azure. Tanio będzie... ale dopiero przy osiągnięciu pewnej skali działania, jak przetestuje się już wszystkie komponenty, dociąży i zoptymalizuje infrastrukturę. Tym bardziej, że przy większych wydatkach miesięcznych – można i trzeba negocjować.

5. W związku z punktem czwartym, namów swojego przedstawiciela Microsoftu, żeby dał Ci rabat albo sponsorskie dolary. Ty się przecież dopiero uczysz! I w przyszłości zostawisz tam jeszcze sporo hajsu.

6. To, że Microsoft daje Ci jakieś komponenty i klientów „za darmo” nie znaczy, że powinieneś tak to traktować.

Traktuj to jak każde inne API, które kupujesz – może zechcesz kiedyś zmienić zależność, która jest zewnętrzna (choć ona bardzo chce wyglądać na wewnętrzną) i musi taka pozostać? Nie ufaj jej!

Testuj jej wydajność i limity - pamiętaj, że nie kontrolujesz wewnętrznej infrastruktury i nawet nie wiesz, jak to jest zrobione. Używaj wymaganego minimum, nie wykorzystuj skutków ubocznych, jak jakieś odkryjesz (albo przygotuj się, że kiedyś może się to na Tobie zemścić). To może spowodować, że Twój soft będzie przyklejony do MS i trudno będzie Ci od niego odejść,gdyby pojawił się lepszy/szybszy/bogatszy komponent.

Tak, używaj AppInisghtów, ale przez własne proxy (w każdej warstwie – JS, C#/F#, baz danych, skryptów python/R) i eksportuj te dane gdzie indziej. Używaj Service Bus, i wybierz to, co Ci akurat potrzebne (napisz interfejs klienta tego API i wykorzystuj tylko te funkcje, które są Ci teraz potrzebne).

7. Estymuj konserwatywnie.

To, że wiesz, jak coś zrobić tradycyjnie, wcale nie znaczy, że będziesz wiedział, jak to zrobić efektywnie w Azure. Coś Cię zawsze zaskoczy - przynajmniej w pierwszych miesiącach poznawania ekosystemu Azure. Najczęściej będzie kilka sposobów implementacji, które wywalą się w najgorszym momencie.

Oto nasz przykład: połączyliśmy się z API zewnętrznym i ściągaliśmy z niego kilka tysięcy eventów w ciągu jednego dnia. Przepuściliśmy to przez EventHub i chcieliśmy wstawić do Azure Data Lake. Jakież było nasze zdziwienie, że parser JSON-a nie jest given out-of-the-box – ale są przykłady MS na githubie. A po drugie: sposób serializacji ciągu eventów JSON-owych nie jest wspierany domyślnie, bo pliki wrzucane przez EventHub nie są arrayem obiektów JSON. Dopiero przestawienie jakichś (output jako Array JSON chyba) tam opcji pomogło, a coś, co wydało się prostym ćwiczeniem przełożenia JSON-ów na kilka tabelek, zajęło prawie dwa dni.

Dodaj więc do swoich estymatów 50%, lub nawet je podwój. Miej szacunek do tej platformy. Daje wielkie możliwości, ale nie jest prosta i zrozumienie jej zależności zajmie Ci trochę czasu. Ale da też satysfakcję!

8. Podejście do architektury sieciowej aplikacji to zupełnie nowy temat.

Do tej pory pewnie płynnie posługiwałeś się VNET-ami, umiałeś schować zasoby za firewallem, otworzyć odpowiednie porty. Microsoft Azure to kompletnie inny świat. Niejednokrotnie się dowiesz, że Twój „ipik” jest dostępny ze świata. Będziesz się zastanawiał, jak coś schować. Będziesz czytał o ASE, a potem zobaczysz, że jest to usługa premium. I kosztuje minimum 3x razy więcej. Podobnie z API Management...

Nasz zespół (biorąc pod uwagę, że bezpieczeństwo jest dla nas bardzo ważne) niejednokrotnie niekomfortowo czuje się z tym, że coś jest domyślnie. Jednak z drugiej strony: jesteśmy dużo ostrożniejsi. I Wam też to radzimy.

Z drugiej strony: jest to niezły profil Software-Defined Networking, a w tym kierunku idzie świat. Więc im szybciej zaczniesz się tym zajmować, tym praktyczniej będziesz znał nowoczesne podejście do networkingu.

 

Będziemy o naszych przygodach z setupowaniem opowiadać w kolejnych tygodniach. Opowiemy oczywiście tylko tyle, ile będziemy mogli ujawnić, ale mam nadzieję, że pomoże to niektórym z Was podejmować dobre decyzje. I być może rozwiąże problem, który sami napotkaliście.

Bo przygoda z Azure jest więcej, niż ciekawa. Człowiek czuje, że żyje i znowu się uczy.

Powodzenia!

 

Łukasz Dziekan, FinAi.com

Warszawa, 29 maja 2017 roku

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