Słońce między chmurami, czyli co powinieneś wiedzieć przed przygodą z Azure

Słońce między chmurami, czyli co powinieneś wiedzieć przed przygodą z Azure

Łukasz Dziekan 22 maja 2017

Dzisiaj będzie o chmurach. Ale nie o cumulusach i obłokach srebrzystych, a o modelu lub metodologii budowania aplikacji i produktów. I o tym, co może się z tym wiązać – zwłaszcza, jeśli nigdy jeszcze niczego w chmurze produkcyjnie nie robiłeś. Bo my już przez to przeszliśmy. I opowiemy Ci, jak było.

Nazywamy się FinAi i jesteśmy młodą organizacją technologiczną. Powstaliśmy jakieś pół roku temu, a ja pełnię w FinAi rolę CTO. Jestem więc odpowiedzialny za wizję naszej technologii i architektury, a także za rozwój produktu.

Co robimy?

W FinAi będziemy tworzyć rozwiązania związane z branżą finansową, nastawione na klienta detalicznego.

To nakłada na nas kilka ograniczeń, które musieliśmy wziąć pod uwagę przy wyborze technologii i architektury: regulowany status, przetwarzanie danych osobowych, strategiczne znaczenie bezpieczeństwa. Jednocześnie nie chcieliśmy zostać tym wszystkim przytłoczeni – musimy zachować elastyczność, żeby móc integrować się z wieloma innymi usługami.

Dodatkowo mamy ambicje, żeby stać się organizacją opartą o dane i wykorzystującą zaawansowane algorytmy opierające się na biometrii i uczeniu maszynowym. 

Jaka jest nasza wizja?

Biorąc pod uwagę wyżej postawione wymagania, wybranie architektury chmurowej nie było oczywistym wyborem. Nie jest tajemnicą, że usługi finansowe wciąż przyglądają się chmurze jako czemuś nowemu.

Zaś sama chmura niesie ze sobą setki wyzwań, których nie ma w modelu on-premise czy też w wykorzystaniu data center. Z drugiej strony obiecuje też wiele benefitów, których próżno szukać w tym drugim modelu.

Na samym początku (czyli pod koniec 2016 roku) nasz produkt rysował się mocno modularnie: wiele komponentów integracyjnych z innymi API/usługami, oddzielny przepływ danych analitycznych, customowe algorytmy ML, podmienialne usługi własne. Wiedzieliśmy, że będzie wymagał skalowania wszerz (wzrost liczby userów i liczby rynków, na których będziemy działać oraz dodatkowych usług, które będziemy dalej rozwijać) i będzie nastawiony na dane, wymuszając bezpieczne podejście do kodowania, pozwalając szybko prototypować i zmieniać środowiska.

Czemu właśnie Azure?

Decyzja nie była łatwa. Tym bardziej, że można było iść w modele hybrydowe (część w chmurze, część na własnych serwerach). Ostatecznie jednak postawiłem na chmurę Azure.

Zadecydowało o tym kilka czynników:

  1. Strategią Microsoftu jest chmura hybrydowa - jest więc przyjazna dla modeli aplikacji hybrydowych, w tym Azure Stack na on-premise.
  2. Jest najbardziej przyjazna dlla regulatorów (i ma najwięcej certyfikatów respektowanych przez nich i przez duże korporacje, np. ISO 27001, ISO 27012, zgodność z RODO).
  3. Bardzo dobre wsparcie dla naszego podstawowego języka backendowego, czyli C#/F#.
  4. Bo całe życie robiłem on-premise w korporacji, a potem zebrałem świetny zespół, w który uwierzyłem. I chciałem trochę zaryzykować.
Ryzyko skalkulowane za Jeffem Bezosem: każda decyzja musi być odwracalna. Musisz założyć, że masz 70% informacji na temat problemu. Jeśli się nie zgadzasz, a cię przekonają, to powiedz, że się nie zgadzasz, ale zobowiąż się to wspierać.

Próba ognia

Po kilku miesiącach muszę przyznać, że nie żałuję decyzji, choć trochę bluzgów i krwi w tym czasie popłynęło.

Wszystko już się stabilizuje. Na razie na zewnątrz widać tylko bloga. Ale już sam blog posiada kilka mikroserwisów, a sporo rzeczy devopsowych zostało przetestowanych i działa na produkcji.

Poniżej opiszę kilka oczywistości, które wcale nie są takie oczywiste, gdy wybierasz chmurę (część odnosi się konkretnie do Azure, a część ogólnie do technologii chmury):

  1. Używaj PAAS (Platform as a Service) z DUŻĄ rozwagą – to jest zupełnie inny model programowania, niż ten, który znałeś. Musisz zmienić sposób myślenia – zwłaszcza jeśli robiłeś aplikacje monolityczne dla klienta wewnętrznego. Jeśli zaś masz background produktów internetowych dla klienta masowego, może być trochę łatwiej.
  2. DevOps staje się bardzo ważny – tym ważniejszy, im bardziej idziesz w stronę rozproszonego systemu złożonego z mikroserwisów/serwisów. Nie zostawiaj sobie go na później!
  3. Bardzo szybko można sobie zrobić bałagan w subskrypcji, bo bardzo szybko tworzy się dużo komponentów, grup zasobów, środowisk etc. Dlatego ważne są konwencje i nazywanie rzeczy.
  4. Deploy jest ZNACZNIE bardziej skomplikowany (jeżeli nie używasz maszyn wirtualnych), niż zwykłe deploy on-premise.
  5. Dokumentacja jest koszmarna – naprawdę! Nie spodziewałem się, jak wiele rzeczy może być niejasnych, zgłoszonych do Microsoftu dawno temu, z odpowiedzią „pracujemy nad tym” wiszącą od roku. A znalezienie dokumentacji niektórych klas będzie niemalże niemożliwe (TSVExtractor z data lake). Wiele rzeczy jest pokazywanych na starym „portalu” Azure, czasami bez szczegółów. Jest źle, zwłaszcza jak byłeś przyzwyczajony do dobrego MSDN i dużej społeczności w „starym” .Net.
  6. To jest żywy i wciąż zmieniający się organizm – w ciągu kilku miesięcy naszego developmentu DocumentDB zmieniło nazwę na CosmosDB, dorobiło się kilku feature’ów w event Hub, ASE i pewnie mnóstwa innych, których nie zauważyliśmy. To może popsuć Wam niektóre rzeczy. Większe update'y możecie znaleźć tutaj.
  7. Brak rozbudowanej społeczności – rzadko możesz zapytać znajomych, jak coś rozwiązać. Benchmarki są trudno dostępne i czasem czujesz się, jakbyś błądził we mgle. Możesz pytać znajomych, ale to muszą być znajomi, którzy robią to na produkcji. Azure User Group na razie nie spełnia oczekiwań (i w Warszawie może z 4 osoby podniosły rękę mówiąc, że są na produkcji z Azurem).

I między innymi z powodu punktu siódmego będziemy pisali tego bloga!

Jeśli dotarłeś do tego momentu, zapraszam do drugiej części tej notki. Tłumaczę w niej, w czym Azure jest lepszy od innych rozwiązań i podaję konkretne przykłady, dlaczego warto wyruszyć w podróż w chmury :)

 

Łukasz Dziekan, FinAi.com

Warszawa, 22 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