Wybór właściwej architektury oprogramowania dla startupów (poprzednie VS obecne)

3 września 2020 r.
Projektowanie systemu oprogramowania odgrywa kluczową rolę w ewolucji startupów. W dzisiejszych czasach obfitość technologii i frameworków oferuje o wiele więcej możliwości w wyborze odpowiedniego stosu i czystej architektury, która przynosi korzyści zespołowi i biznesowi.

W ciągu 10 lat pracy w tech start-upach doświadczyłem i byłem świadkiem, jak wykorzystanie technologii do realizacji pomysłów zmieniało się w czasie. Pracowałem nad projektami o różnym charakterze, niektóre z nich były idealne, ale pasowały do przeciętnego rynku produktowego, a inne do podproduktów, ale pasowały do rynku produktowego.

Jednak do dziś rzadko kiedy widzę silne połączenie solidnej technologii z doskonałym produktem-rynkiem pasującym do młodych startupów. Nic niespodziewanego, biorąc pod uwagę ciągle zmieniający się charakter projektów typu early age start-up. Jak wszyscy wiemy, start-upy słyną z szybkiego tempa, w którym często zmieniają się terminy i priorytety.

W tym artykule przyjrzymy się typowej architekturze oprogramowania używanej przez tech start-upy w przeszłości i porównamy ją z konfiguracją, którą nowoczesne start-upy (w tym my w Omniaz) mogą teraz zaadoptować.

Przeszłość: Problem z monolityczną architekturą techniczną

Tradycyjnie, startupy technologiczne rozpoczynają się od monolitycznej architektury technicznej (tzn. jednej aplikacji realizującej wszystkie funkcje). Celem jest stworzenie minimum wykonalnego prototypu (MVP), uzyskanie informacji zwrotnej, a następnie potencjalnie nowy, czysty start. Jednak częściej ten "czysty start" nigdy nie następuje ze względu na presję czasu, koszty i pilność sytuacji.

Zamiast tego, zespoły w końcu bazują na tym, co już jest dostępne (choć początkowo miało to być "wyrzucane" prototypy). W końcu produkt ewoluuje wraz z nowymi funkcjami i wymaganiami, dopóki nie stanie się trudny do pracy z kilkoma kluczowymi osobami, które faktycznie rozumieją, co się dzieje. Prowadzi to do wysokiej rotacji zespołu, spowolnienia rozwoju produktu, błędów i problemów z wydajnością, braku skalowalności i nieodłącznych luk bezpieczeństwa, które są trudne do wykrycia.

Z lewej: Idealna monolityczna architektura systemowa. Z prawej strony: Rzeczywistość stale rozwijającej się architektury monolitycznej. Nowe funkcjonalności nie są uwzględniane na początku i trudne do dodania w miarę rozwoju projektu.

System monolityczny ogranicza ruch w firmie i wewnątrz niej, ponieważ radykalne zmiany, plany ekspansji, migracje i inne zdarzenia zależą od elastyczności zarówno zespołu, jak i technologii. Nie wspominając już o tym, że przepisy dotyczące ochrony danych i cyberprzestępczości są obecnie bardziej nieuchronne niż dziesięć lat temu, piętrząc się na złożoności tworzenia wszelkiego rodzaju oprogramowania. W rezultacie może się okazać, że w związku z niedotrzymanymi terminami i kosztami związanymi z balonowaniem, starając się złagodzić nieprzewidziane problemy związane z działaniem systemu monolitycznego, przedsiębiorstwo rozpoczynające działalność będzie musiało zrezygnować z pewnych możliwości.

Obecny: Systemy modułowe i koherentne stosy dla ratowników

Jaka jest więc architektura techniczna, która trafia w słodki punkt między zaspokajaniem potrzeb biznesowych, zgodnością z przepisami a oczekiwaniami użytkowników?

Dla nas w Omniaz, nasz projekt rozpoczął się w sprzyjającym czasie, kiedy pewne nowe technologie ułatwiły kuratelację naszej architektury technologicznej.

Rozproszona i modułowa architektura systemu pozwala na lepszą dynamikę zespołu i możliwość wykorzystania najlepszej technologii do rozwiązania każdego problemu. Dodawanie nowych funkcji może odbywać się bezproblemowo przy wyraźnym rozdzieleniu obaw, logiki biznesowej i własności kodu.

Systemy modułowe

Mówiąc o systemach modułowych z perspektywy serwerów, mamy na myśli rozproszone struktury aplikacyjne (gRPC), które ułatwiają enkapsulację logiki biznesowej jako mikrousługi. W połączeniu z wysokowydajnymi językami programowania (Golang), jak również z językami specyficznymi dla nauki maszynowej (ML) (Python), podejście to sprawia, że baza kodowa jest łatwiejsza w utrzymaniu. Ponadto, ponieważ gRPC opiera się na językowych interfejsach agnostycznych dla definicji RPC, sprawia, że dokumentacja interfejsów jest bardzo prosta i pozwala zespołom pracującym nad różnymi stosami na łatwą współpracę.

Po stronie klienta wykorzystujemy moc React Native, która ułatwia utrzymanie jednej bazy kodowej dla platform Android i iOS. Obsługuje również integrację natywnych kodów Androida i iOS, co z kolei pozwala nam na integrację komponentów niższego poziomu napisanych w C++. Jest to kluczowe dla naszych produktów, ponieważ jesteśmy w stanie zapakować nasz zestaw SDK zasilany AR/AI do integracji z aplikacjami innych producentów.

Dzięki modułowemu podejściu od samego początku możliwe jest korzystanie z wielu języków programowania i bibliotek, które najlepiej nadają się do rozwiązywania konkretnych problemów. Jest to bardzo przydatne zwłaszcza przy łączeniu technologii takich jak AI/ML, AR, gromadzenie i przetwarzanie danych.

Dla zespołu oznacza to, że może on elastycznie skalować się zarówno pod względem różnorodności stosowanych technologii, jak i liczby osób pracujących z jedną technologią dzięki czystemu rozdzieleniu logiki biznesowej na małe bazy kodowe.

Kominy koherentne

Kolejnym aspektem jest pojawienie się technologii międzyplatformowych (React Web, React Native) oraz nowoczesnych ram API (GraphQL), które pozwalają na synergię w obrębie stosu.

Spójne stosy umożliwiają pracę zespołów cross-funkcjonalnych, szczególnie w obszarze rozwoju webowego lub mobilnego, poprzez wykorzystanie technologii takich jak React Web/Mobile. Ponieważ podobny stos i framework jest używany dla wszystkich aplikacji klienckich, zespół inżynierów ma możliwość bardziej efektywnej komunikacji, ponieważ mówi tym samym "językiem" i współtworzy wiele baz kodu. Pozwala to małemu zespołowi pracować bardziej efektywnie, dzielić się wiedzą i uzupełniać swoje umiejętności.

GraphQL jest wydajny w redukcji kosztów utrzymania API poprzez umożliwienie aplikacjom klienckim wykonywania zapytań na dostępnych schematach. Jest to duża zaleta w porównaniu z architekturą REST nie tylko w zakresie żądań zmian, ale także w zakresie możliwości zapytań tylko o wymagane punkty danych. Jednocześnie posiada ona implementacje w wielu językach, co ułatwia jej przyjęcie w obrębie stosu. Jest również doskonałym wyborem jako warstwa abstrakcyjna przed chmurą mikrousług (interfejsy gRPC ponownie okazały się tu użyteczne), ponieważ może wyeksponować wspólny, łatwy w użyciu interfejs dla aplikacji klienckich.

Infrastruktura rdzenna w chmurze

Mówiąc o modułowości i spójności stosów, nie może być lepszego przykładu niż rozproszona architektura systemu (mikroserwisy) działająca na Docker i Kuberneters. Widzimy dojrzewanie technologii konteneryzacji i orkiestracji, które są przyjmowane przez dużych dostawców chmury, odciążając wiele prac nad infrastrukturą w dłuższej perspektywie czasowej przy zachowaniu dobrych wskaźników systemowych (dostępność i wydajność) oraz widoczności (poprzez monitorowanie i ostrzeganie). Te trendy i technologie wspomagające pozwoliły nam zbudować system, który jest solidny, skalowalny i połączony z wykorzystaniem technologii open-source w chmurze-agnostyce.

W skrócie

Wciąż jednak nie ma jednego, uniwersalnego podejścia do każdego startupu lub firmy. Istnieją wady tej metody, takie jak:

  • stos różnorodności, co zwiększa liczbę umiejętności wymaganych w zespole;
  • początkowa prędkość wejścia na rynek jest wolniejsza z powodu dodatkowych komplikacji w konfiguracji systemu; oraz
  • Systemy rozproszone mają specyficzne wzorce projektowe i wyzwania.

Jeśli opracowujesz innowacyjną technologię dla produktów i/lub przedsiębiorstw, które muszą szybko rozwijać się wraz z potrzebami rynku i skalą w różnych regionach, warto zapoznać się z pomysłami zawartymi w tym artykule. Z drugiej strony, jeśli budujesz coś bardziej tradycyjnego, takiego jak platforma e-commerce, lepiej jest pracować z ustalonymi technologiami i ramami, które zawierają w sobie lata sprawdzonego i zaufanego know-how w odpowiednich dziedzinach.

Călin Ciobanu
CIO i współzałożyciel
Călin jest doskonale zorientowanym liderem technicznym i architektem oprogramowania z ponad 8-letnim doświadczeniem w uruchamianiu systemów, prowadzącym zespoły w wielu obszarach rozwoju oprogramowania. Pasjonuje się mentoringiem i rozwijaniem talentów inżynierskich poprzez zachęcanie do wymiany wiedzy, zdobywania nowych umiejętności i rozwoju istniejących.