{"componentChunkName":"component---src-templates-blog-post-js","path":"/blog/itcorner-tech-meetup-1-skalowanie","result":{"data":{"markdownRemark":{"html":"<p>Kilka dni temu wziąłem udział w spotkaniu <a href=\"https://www.meetup.com/ITCorner-Tech-Meetup/events/267393261/\">ITCorner Tech Meetup</a>, którego tematem przewodnim było skalowanie. Poniżej garść notatek.</p>\n<h2>Temat</h2>\n<p>W zasadzie tylko 50% spotkania było o skalowaniu - reszta była o refaktorze legacy. Temat ciekawy jeden i drugi, ale tytuł spotkania jednak mylący.</p>\n<h2>Skalowanie</h2>\n<p>Jarosław Jedliński w swojej prezentacji opowiedział, jak jego zespół dba o to, żeby strona popularnego sklepu Euro RTV AGD nie wysypywała się w czasie czarnego piątku. Według zamieszczony statystyk - ruch na stornie w ten dzień jest kilka razy większy, dając kilka tysięcy requestów na sekundę. Ten zespół rozwija portal [https://www.euro.com.pl/] już od kilkunastu lat, co pozwoliło w fajny sposób pokazać ewolucję architektury i używanych rozwiązań. Kroki mniej więcej były takie:</p>\n<ol>\n<li>Odseparować aplikacje \"analityczne\" od tej głównej, sklepowej.</li>\n<li>Zduplikować bazę, żeby aplikacje \"analityczne\" nie zamulały dostępu do bazy dla sklepu.</li>\n<li>Dać więcej instancji aplikacji sklepowych i jakiś load balancer.</li>\n<li>Dodać cache w aplikacjach sklepowych - żeby zredukować round-tripy do bazy.</li>\n<li>Wprowadzić centralny cache, żeby oszczędzić pamięć i nie trzymać powtórek w kilku cache'ach.</li>\n<li>Wprowadzić cache dla całych requestów (Varnish) - umożliwia chwilowy offline sklepu (np. podczas wdrożenia w ciągu dnia).</li>\n<li>Dodać drugą serwerownię ze zdkuplikowaną infrastrukturą, na wypadek awarii tej pierwszej.</li>\n</ol>\n<p>Co ciekawe, cały rozwiązanie jest trzymane we własnych serwerowniach. Wydawało mi się, że to śmiga w chmurze, a jednak. Inna ciekawostka: nad rozwojem i utrzymaniem sklepu pracuje ponad 20-osobowy zespół programistów, testerów i administratorów.</p>\n<p>Piotr Gołofit z Accesto opowiadał bardziej o mądrym przepisywaniu legacy (o tym niżej), ale w działce skalowania zwrócił uwagę na ciekawy aspekt. Bardziej mówił o skalowaniu biznesowy niż technicznym, tzn. o skalowaniu produktu (aplikacji) na większy rynek (międzynarodowy). W takich wypadkach trzeba pomyśleć m.in. o:</p>\n<ul>\n<li><em>i18n</em> = czyli obsłudze wielu języków: zarówno o przetłumaczonym interfejsie, jak i potencjalnym multi-języczną obsługą danych,</li>\n<li>różnych strefach czasowych: wyświetlanie wg strefy czasowej użytkownika plus odpowiednie \"tłumaczenie\" dat i godzin wprowadzanych,</li>\n<li>obsługa różnych walut - przede wszystkim jeśli chodzi o płatności.\nCo ciekawe, w przypadku tego projektu, o którym opowiadał Piotr, były to bliskie geograficznie rynki - wyjście z Irlandii na całe Wyspy Brytyjskie - to poza ww. sprawami dochodziły różnice kulturowe (wpływające <em>de facto</em> na sposób prezentowania danych) i polityczne (potencjalny <em>brexit</em>).</li>\n</ul>\n<h2>Przepisywanie legacy</h2>\n<p>Piotr Gołofit i Łukasz Urbański w swoich prezentacjach poruszali podobny temat: dostajemy do utrzymania (i rozwijania) starą aplikację, co robimy?</p>\n<ol>\n<li>Ciągniemy to tak, jak jest - babrzemy się w legacy, conieco refaktorując.</li>\n<li>Nowe rzeczy idą po nowemu, stare powoli próbujemy przepisywać na nowo.</li>\n<li>Wywalamy wszystko i startujemy z <em>carte blanche</em>.</li>\n</ol>\n<p>Żadna z opcji nie jest idealna, obaj prelegenci udowadniali, że opcja druga - nazwana <em>strangler pattern</em> (termin wprowadził <a href=\"https://martinfowler.com/bliki/StranglerFigApplication.html\">Martin Fowler</a>) - jest sensownym rozwiązaniem. Jeżeli jesteśmy w stanie na poziomie routingu rozdzilić ruch do starej i nowej aplikacji, to możemy sobie stworzyć takie poletko z nową aplikacją w nowej technologii. Nowe moduły trafiają do nowej aplikacji, stare są po kolei przepisywane na nowo. Ale cały czas mamy jedno i drugie aktywne - na produkcji. Co więcej, analizując użycie poszczególnych funkcji, możemy wybierać do przepisana te części, które są najczęściej używane przez użytkowników. Finalnie - w świecie idealnym - na koniec w starej aplikacji nie zostaje nic, można więc w całości przepiąć się na nową wersję. Oczywiście to nie jest takie hop-siup: przykład projektu, o którym opowiadał Piotr Gołofit, to były 3 lata stopniowego naprawiania sytuacji. To wymaga metodycznego podejścia, tym bardziej, im bardziej bagniste jest legacy, do którego siadamy. Trzeba najpierw zadbać o elementarne sprawy, jak kontrola wersji, CI/CD, podstawowe testy, załatanie najważniejszych luk bezpieczeństwa - żeby móc iść do przodu. W pewnym sensie podziwiam konsekwencję, bo wiele osób widząc bagniste legacy, do którego nikt nie chce się dotykać, szybko by uciekło, byleby nie babarać się w jakichś technologiach sprzed 10 lat i byleby nie sprzątać bajzlu po kimś innym.</p>","excerpt":"Kilka dni temu wziąłem udział w spotkaniu ITCorner Tech Meetup, którego tematem przewodnim było skalowanie. Poniżej garść notatek. Temat W zasadzie tylko 5…","frontmatter":{"date":"19 January, 2020","path":"/blog/itcorner-tech-meetup-1-skalowanie","title":"ITCorner Tech Meetup #1 Skalowanie"},"fields":{"readingTime":{"text":"4 min read"}}}},"pageContext":{}},"staticQueryHashes":["3649515864","63159454"]}