Oskar Dudycz

Pragmatycznie o programowaniu

Czy to się przeskaluje... w dół?

2021-06-21 oskar dudyczArchitektura

cover

Cześć!

Dzisiaj krócej niż zwykle, bo jestem na wczasach! Niesamowite uczucie móc być znowu na plaży i nie musieć nosić maseczki. Doceniajmy te drobne chwile, póki je mamy.

Jakiś czas temu napisałem w newsletter, że nie ma dużo bardziej irytujących pytań niż “ale, czy to się będzie skalować?!” (przeczytaj więcej: https://oskar-dudycz.netlify.app/pl/czy_to_sie_skaluje/). Zwykle przedwcześnie myślimy o skalowaniu w górę. Może częściej powinniśmy zacząć myśleć o skalowaniu w dół?

Intel nie myślał i teraz traci pozycję lidera runku procesorów (przeczytaj więcej: https://stratechery.com/2021/intel-problems/). Procesory ARM, które do tej pory były kojarzone z Raspberry Pi i innymi zabawkami ze świata IoT weszły na salony. Dynamiczny rozwój smartfonów wspomógł w rozwoju mocnych i energooszczędnych procesorów, które nadają się do poważnego użytku.

Procesor Apple M1 to jedno, ale to dopiero początek rewolucji. AWS już wprowadził swoje usługi chmurowe oparte na procesorach ARM Graviton (https://aws.amazon.com/ec2/graviton/). Inne korporacje są w tyle, ale oczywiście też zaczęły pracować nad swoimi chipami ARM:

Nowe możliwości i ich ekspresowe pojawienie się ich w “pierwszej lidze”. Powoduje, że wiele firm nie nadąża z dopasowaniem swoich rozwiązań. Chipy ARM mają swoją specyfikę, do tradycyjnych bazodanowych podejśc niekoniecznie się dobrze nadają.

Parę razy w ostatnich czasach byłem pytany o Event Sourcing w kontekście IoT. Potencjalnie wydaje się to świetnym dopasowaniem. I tu zdarzenia, i tu zdarzenia. Nie jest to jednak tak trywialne, jak może się wydawać. Rzeczywiście, model IoT wydaje się zgodny z Event Sourcing, ponieważ słuchamy zdarzeń, a następnie prowadzimy interakcję. Głównym problemem jest charakter danych pochodzących z maszyn oraz częstotliwość, z jaką publikowane są zdarzenia. W Event Sourcing zdarzenia gromadzą wartość biznesową. Dane IoT są zwykle surowe. Kolejną kwestią jest to, że większość event store’ów nie jest lekka. Zostały stworzone z myślą o większych projektach enterprise. Nie zawsze można je więc uruchomić na urządzeniach IoT.

Ponadto, dość często mają one, większą częstotliwość publikowania zdarzeń niż event store’y mogą obsłużyć na sekundę. Typowym wzorcem jest najpierw zapisanie pomiarów przy pomocy lekkiego storage (np. prostych baz klucz/wartość). Następnie zgrupowanie i przetworzenie do zdarzeń zrozumiałych dla biznesu. Ta transformacja zdarzeń jest ważna ze względu na wydajność, ale przede wszystkim po to, aby nieprzetworzone zdarzenia miały znaczenie biznesowe.

W Event Store np. największym problemem dla oficjalnego wsparcia ARM jest użycie silnika V8 (https://v8.dev/) do projekcji oraz gRPC, które również ma swoje problemy z serwerami ARM. To powinno zostać rozwiązane w kolejnej wersji (wychodzącej w tym miesiącu), ale potem żmudne testy regresji.

Z podobnymi kwestiami będą się zderzały inne typy baz danych. Coraz więcej ludzi będzie oczekiwało od twórców oprogramowania możliwości uruchomienia ich na lekkich i mniejszych środowiskach. To nie tylko chodzi o IoT, ale również serverless itd.

To wpływa już bezpośrednio modele wytwarzania oprogramowania. Nie każdemu się to podoba. Np. .NET z każdą edycją jest odchudzany. Coraz mniej funkcji jest uruchamiane z automatu. Startup jest coraz krótszy i łatwiejszy. Wiele osób się zżyma, że jest to robione pod “osoby po bootcampach co się JavaScriptu uczyły” i że przecież w “dużych projektach to nie ma znaczenia”. Może w dużych, tradycyjnych monolitach nie ma, ale właśnie w tych wszystkich modelach oprogramowania, które już się pojawiły i w tych, które dopiero się pojawią już, ma bardzo duże.

Sam jestem ciekaw, w którą stronę się to rozwinie, ale przewiduję, że umiejętność odchudzania swojego oprogramowania i kodu będzie coraz ważniejsza. Coraz częściej będziemy pytać “czy to się skaluje?” mając na myśli skalowanie w dół, a nie w górę.

Co o tym sądzisz?

Pozdrawiam. Oskar

  • © Oskar Dudycz 2019-2020