Kontakt

Aleksander Dytko - RST Software

Aleksander
Dytko
+48 532 626 248

Jak nie przepalać budżetu budując startup? Jak nie przepalać budżetu budując startup?
Bez prostych odpowiedzi - Podcast

#5 - Jak nie przepalać pieniędzy budując startup?

 

  • Od czego zacząć budując infrastrukturę startupu?
  • Jak dobrać zespół?
  • Jak zarządzać kosztami?

Co znajdziesz w #5 odcinku?

W 5 odcinku porozmawiamy o tym, na co zwrócić uwagę rozwijając własny startup lub projekt IT, aby nie narazić się na wydatki, których można uniknąć. Porozmawiamy o tym jak zarządzać kosztami i na co zwracać uwagę, żeby tych kosztów niepotrzebnie nie generować. Gościem odcinka jest Łukasz Szramko – Delivery Lead w RST Software Masters.

 

Zagadnienia, które poruszamy:

  • Od czego zacząć budując infrastrukturę startupu?
  • Jaka jest różnica pomiędzy architekturą a infrastrukturą IT?
  • Czy od razu skupić się na budowie modułowej?
  • Jak dobrać zespół do realizacji projektu?
  • Jak podchodzić do skalowania systemu?
  • Jak zarządzać kosztami i nie przepalać pieniędzy?

Delivery Lead w RST Software Masters. Człowiek odpowiedzialny za skuteczne dostarczanie produktów i rozwiązań. Niegdyś programista backendu, a od wielu lat menadżer prowadzący zespoły i projekty deweloperskie.

Łukasz Szramko
Gość odcinka

Łukasz Szramko

Humanista z nałogiem technologicznym, entuzjasta rzeczy pięknych i niekoniecznie funkcjonalnych. Developer, grafik, animator. Lubi ołówki i orzeszki w pikantnej skorupce.

Robert Zatycki
Gospodarz podcastu

Robert Zatycki

Wszystkie odcinki znajdziesz na:

Minuta po minucie, czyli o czym rozmawiamy

00:00 | Historia pewnego rozwiązania, które sprawiło kłopoty

 

02:40 | Jak zacząć pracować nad projektem IT w startupie?

 

05:37 | Monolit czy modułowość?

 

07:32 | Jak tworzyć zespół developerski?

 

08:56 | Jak obciążenie systemu wpływa na koszty?

 

17:25 | Na jakie rozwiązania stawiać budując startup?

Podcast Czas

Transkrypcja nagrania

W pierwszym odcinku naszego podcastu opowiadałem historię o tym, jak kilka lat temu budowaliśmy portal społecznościowy dla pewnej branży i jak to się nie za dobrze skończyło. Dzisiaj dopowiem do tej historii pewien epizod. Wiadomo, że kiedy zaczynamy myśleć o projekcie systemu czy aplikacji, to staramy się wziąć pod uwagę wszystko wiele aspektów. I używając naszej wiedzy, znajomości rozwiązań chcemy sprostać wymaganiom tego systemu – chcemy wszystko przewidzieć. W naszym przypadku było dokładnie tak samo. W związku z tym, że nasz serwis miał być wielką platformą społecznościową, to wybierając bazę danych do niego, nasza uwaga padła na Neo4j – bazę grafową. Żeby nie wchodzić w szczegóły, powiem tylko, że baza grafowa zdecydowanie lepiej nadaje się do takich zastosowań niż baza relacyjna, a w tamtych czasach już Facebook korzystał z grafowej bazy, więc z naszego punktu widzenia ten wybór był nie dość, że słuszny, to jeszcze bardzo na czasie. Ale… Neo4j, którego wybraliśmy był wówczas w bardzo początkowej fazie. Większość problemów, które spotykaliśmy trzeba było rozwiązywać z autorem tego silnika – nie było wówczas nawet natywnego interfejsu z PHP, ale najbardziej frustrujące były sytuacje, kiedy po dwutygodniowym sprincie chcieliśmy wdrożyć kod, a w międzyczasie pojawił się update silnika Neo4ja i nasz kod przestawał po prostu działać. Trzeba było go przepisywać. Takie sytuacje były dosyć częste. Traciliśmy czas, rosła frustracja, rosły koszty projektu, bo nie posuwaliśmy się do przodu i zamiast korzyści z potęgi tej bazy mieliśmy same problemy. I po iluś miesiącach zapadła decyzja, aby wycofać się z tego rozwiązania i przenieść dane na inną bazę. No ale to były dawne czasy. A jak jest dzisiaj? Jak możemy takich ślepych uliczek unikać?

Dlatego w dzisiejszym odcinku podcastu „Bez prostych odpowiedzi” poszukamy odpowiedzi na pytanie, jak nie przepalać pieniędzy budując startup albo jakiś projekt IT? Czym się kierować? Na co zwracać uwagę wybierając infrastrukturę i architekturę systemu? A w poszukiwaniu tej odpowiedzi pomoże Łukasz Szramko – Delivery Lead w RST Software Masters, czyli człowiek odpowiedzialny za skuteczne dostarczanie produktów i rozwiązań. Niegdyś programista backendu, a od wielu lat menadżer prowadzący zespoły i projekty deweloperskie. Łukasz sporo tych projektów wdrożył, dlatego chętnie skorzystamy z jego wiedzy i doświadczenia. I zacznijmy od tego jak zacząć? Mamy już zbadany nasz pomysł na startup, na projekt albo aplikację i już wiemy, że jest odpowiedzią na potrzeby użytkowników. To to jak mamy dobrze zacząć?

ŁUKASZ SZRAMKO
Jak zacząć? Pierwsze, co musimy zrobić, to zebrać grupę ludzi, którzy mają pojęcie o technologii. Osoba, która jest odpowiedzialna za ten produkt musi przedstawić tę wizję i zespół musi zadać wiele pytań, żeby spróbować nakreślić jakąś architekturę tej aplikacji – żeby wiedzieć, jak ten produkt ma się rozwijać. Bardzo dużo będzie pewnie pytań biznesowych, ale tak naprawdę pod spodem kryją się też pytania technologiczne, które do osoby nie technicznej nie są zadawane wprost. Więc na pewno typowe startupy robi się tak, że staramy się robić to w miarę prosto po to tylko, żeby nie generować zbyt wielkich kosztów i żeby móc ten produkt jak najszybciej wprowadzić na rynek.

ROBERT ZATYCKI
Czyli jak zawsze kluczowy jest czas? Mamy tutaj dwa aspekty architekturę projektu i jego infrastrukturę. Te rzeczy są z pewnością ze sobą powiązane, ale nie są tożsame.

ŁUKASZ SZRAMKO
Tak jak powiedziałeś – te rzeczy są faktycznie powiązane. Infrastruktura to jest to, co jest pod spodem – mogą się tu kryć urządzenia, jakieś technologie, które zapewniają działanie dla tego startupu. A architektura to sposób ułożenia tych klocków, które budują budują ten startup w aplikacje. Jedno z drugim jest powiązane, bo sposobów na zbudowanie aplikacji jest mnóstwo, tak samo jak sposobów na uruchomienie tej aplikacji na danej infrastrukturze. Fajnie, jak osoby odpowiedzialne za jedną i drugą rzecz komunikują się ze sobą, bo wtedy da się zbudować optymalne rozwiązanie. I tutaj pod hasłem optymalne się kryje wiele rzeczy: optymalne ze względu na wydajność, dostępność, na akceptowalne koszty – tych zmiennych jest wiele.

ROBERT ZATYCKI
To jak według ciebie należy podchodzić do pracy nad projektem.

ŁUKASZ SZRAMKO
Podejście chyba najlepsze, to jest małą łyżeczką, czyli budujemy od czegoś małego. Wrzucamy to na rynek tak szybko jak się da i jak widzimy, że jest potrzeba zeskalowania, to skalujemy. Nie powinno się robić tak, że zamykamy się na trzy miesiące – trzy miesiące to może za mało – ale zamykamy się na rok, budujemy coś ogromnego, wrzucamy to na rynek po czym się okazuje, że fajnie super to działa jest rozwiązanie zeskalowane, ale po co, jak klientów mamy dziesięciu na godzinę i palimy pieniądze. Startup może już na siebie zarabia, ale niewystarczająco na to, żeby nawet pokryć koszty tej infrastruktury. Więc tutaj trzeba znowu dopasować rozwiązania do bieżących potrzeb, do tego jak się ono będzie się rozrastać.

ROBERT ZATYCKI
No tak, ale ale przecież często na etapie projektowania mamy taką pokusę brania pod uwagę wszystkiego, także tych usług, które może będą potrzebne w przyszłości. I poświęcamy czas na to, żeby wszystko planować, rozbijać klocki modułów na serwisy, a to zwiększa stopień skomplikowania i pochłania w dużym stopniu ten czas.

ŁUKASZ SZRAMKO
Czasami warto na początku wyjść od monolitu po to, żeby tak naprawdę poznać tę aplikację, bo przy zwinnym podejściu ten produkt się buduje cały czas i te obszary, które można wydzielić później w moduły, które będą skalowalne, które będą zapewniały wysoką dostępność, tak naprawdę wydzielają się dopiero później, gdy już poznamy faktyczne potrzeby. Więc czasami nie warto na początku iść w rozwiązania stricte modułowe, no bo może tak naprawdę nie odgadniemy tej potrzeby i zrobimy coś na wyrost.

ROBERT ZATYCKI
Zapewne na początku życia produktu tak jest, bo dobrze wiemy, że szybko dostarczony produkt daje większą szansę na sukces, ale też wiemy jakie zalety i możliwości daje oparcie systemu na modułach.

ŁUKASZ SZRAMKO
Ta modułowość gwarantuje nam to, że możemy skorzystać z gotowych rozwiązań z półki, np. modułu płatności czy jakiegoś modułu uwierzytelniania, a resztę dopisać samemu. I gdy zobaczymy, że na przykład te usługi z półki nam się już nie skalują albo są za drogie, to możemy to wymienić na własny moduł. I tutaj jest pełna dowolność. Takie podejście modułowe pozwala popełniać mniejsze błędy.

ROBERT ZATYCKI
Czyli warto skupić się na efektywności i korzystać z takich usług czy rozwiązań, które w krótkim czasie sprawią, że ta nasza aplikacja będzie działać?

ŁUKASZ SZRAMKO
Na pewno istnieje bardzo dużo usług, które pozwalają ci tak naprawdę zbudować taką aplikację, nie bawiąc się w kodowanie, tylko poskładać ją z jakichś klocków. Ale myślę, że to jest takie rozwiązanie, które się sprawdzi na takim bardzo wczesnym etapie, gdzie próbuje się zrealizować pomysł. Gdy chcsz iść dalej, to już musisz mieć dedykowany zespół, który będzie świadomie i kompetentnie korzystał z tych gotowych rozwiązań na rynku.

ROBERT ZATYCKI
A jak taki zespół wybrać? Zbudować? Dobrać?

ŁUKASZ SZRAMKO
Ważne żebyśmy ten zespół dobierali tak, żeby on się wymieniał kompetencjami, żebyśmy mieli jakąś zastępowalność – to też jest ważne, chociaż na etapie budowania startupu ciężko mieć jakiś duży zespół. Więc też fajnie by były to osoby zaufane, które doradzą technologicznie i które mają doświadczenie w budowaniu takich rzeczy wcześniej. Bo można bardzo szybko coś zbudować, co finalnie nie będzie produktem, który się skaluje i który jest odpowiedzią na potrzeby użytkownika.

ROBERT ZATYCKI
A mówiąc o potrzebach użytkownika, żeby je rozpoznać i znać, musimy cały czas trzymać rękę na pulsie.

ŁUKASZ SZRAMKO
Tu jest bardzo ważna rola osoby, która odpowiada za ten startup, tego Produkt Ownera, który powinien zdiagnozować te potrzeby, a później to powinno zostać przełożone na technologie w taki sposób, żeby w miarę elastycznie później móc ten produkt rozwijać. Dlatego trzeba stawiać na prostotę i elastyczne podejście, które zapewni nam możliwość wprowadzania zmian czy poprawek.

ROBERT ZATYCKI
A to elastyczne podejście, to zagwarantowanie sobie takiej możliwości rozbudowy czy przebudowy systemu aplikacji, z której korzysta na dzisiaj stu użytkowników do rozmiaru potrafiącego obsłużyć ich tysiąc albo więcej?

ŁUKASZ SZRAMKO
Rozmawiamy o skali i o tym, jakie będzie obciążenie tego systemu, więc naturalnym jest, że inaczej to będzie planowane i inna będzie infrastruktura dla 100 użytkowników, a inna dla miliona. Bo ta skala tysiąca, to troszkę za małe porównanie. Tutaj faktycznie trzeba operować na tej dużej skali lub małej skali, bo inaczej ten produkt od strony architektury infrastruktury powinien wyglądać.

ROBERT ZATYCKI
To co będzie bardziej korzystne? Zapewnienie sobie możliwości skalowania czy budowanie od razu dużego systemu?

ŁUKASZ SZRAMKO
No i tu nie ma prostych odpowiedzi. Wszystko zależy od budżetu – czy możemy najpierw wprowadzać proste rozwiązania, które nie są skalowalne, żeby pozyskać klientów, a później się martwić o tą skalowalność – czy już wiemy, że faktycznie produkt jest na tyle rewolucyjny, że już uderzamy w rozwiązania, które się skalują, które możemy później niewielkim kosztem rozbudowywać.

ROBERT ZATYCKI
Ale z drugiej strony, w odróżnieniu od tego, co było kiedyś dzisiaj chyba jest dosyć łatwo, mając do dyspozycji cały szereg usług typu SaaS, mając do dyspozycji tak modną chmurę, opierać nasz system na cudzych zasobach, a przez to mieć swobodne możliwości rozbudowy.

ŁUKASZ SZRAMKO
W obecnej chwili, a raczej już przez dłuższy okres czasu widzimy, że jest trend na rozwiązania typu serverless czy mikrousługi. Są takie basewordy bardzo mocno używane i często, może nie do końca rozumiane, ale historycznie to było tak, że aplikacje webowe, czy serwery webowe uruchomione były na jakiś dedykowanych serwerach i właściciel miał pełną kontrolę nad tym, co tam się działo i tak naprawdę taką prostą usługę można było postawić małym zespołem, gdzie każdy odpowiadał za całość usługi – czyli jak to się mówi fullstack – i postawi serwer i zaimplementuje backend, frontend – kiedyś się w ogóle nie było mowy o takim rozgraniczeniu. Frontend robił developer PHP, jak ja pamiętam robiło się też część frontendową za pomocą jakichś szablonów, ale wcześniej wszystko pisało się, mówiąc brzydko, z palca. I to ewoluowało. Były jakieś tam usługi alokacji serwerów, gdzie się te maszyny powstawiało, później przyszedł świat wirtualizacji, gdzie już nie było fizycznych maszyn, tylko były wirtualne maszyny, które można było bardzo szybko wykupić i dostać faktycznie dostęp do kolejnej maszyny. I takie usługi można było dzięki temu skalować. Później powstały takie giganty jak np. Amazon, gdzie tych serwerów było bardzo wiele no i nawet taka wirtualizacja powodowała to, że część z tych maszyn nie była wykorzystana. Potem wyszły takie rozwiązania jak konteneryzacja, czyli tak naprawdę wydzielanie tej części serwera na jakieś tam usługi – to już można bardzo elastycznie sobie alokować te zasoby i dzięki temu też ten model rozliczeń mógł być taki elastyczny dla klienta końcowego. Te idee się dalej gdzieś tam rozwijają, powstają rozwiązania takie jak serverless i tutaj wchodzą rozwiązania takie jak AWS Lambda czy Google Cloud, które dają możliwość uruchomienia swoich usług w postaci jakichś malutkich aplikacji czy funkcji, które działają tylko wtedy, kiedy przychodzi do nich użytkownik końcowy. I też płacisz za nie tylko wtedy, gdy są one używane. Ma to swoje bardzo duże plusy, bo faktycznie można przy małym ruchu niewiele płacić za te usługi. Ale znowu, gdy przychodzi duży ruch, to trzeba mieć bardzo dużą świadomość tego, że można bardzo dużo pieniędzy spalić przez nieoptymalne zastosowanie.

ROBERT ZATYCKI
Ale my nie chcemy przepalać pieniędzy, więc jak się przed tym chronić?

ŁUKASZ SZRAMKO
Trzeba mieć wiedzę. I tak jak powiedziałem na początku, kiedyś cała ta wiedza mogła być w jednej osobie i ona była odpowiedzialna od A do Z za całość, a teraz mamy bardzo ścisły podział na role. Wchodzi mocno kultura DevOps, która jest odpowiedzialna za usługi chmurowe i przez chmurę rozumiem tutaj rozwiązania AWS, czy Google, czy Azure. I tam tych gotowych pudełek jest bardzo dużo i też należy korzystać z nich świadomie, bo nie wszędzie będą one dobrze użyte i finalnie trzeba patrzeć przez pryzmat potrzeb, ale też bardzo mocno przez pryzmat kosztów, które mogą niekontrolowane urosnąć bardzo mocno.

ROBERT ZATYCKI
To w jaki sposób te koszty kontrolować?

ŁUKASZ SZRAMKO
Ważną rolą jest, żeby monitorować usługi, które mamy wykupione w chmurze, bo nie sztuką jest postawić 10 serwerów, 10 klastrów, które pod spodem mają wiele instancji, za które będziemy płacić setki dolarów. Tylko sztuką jest wykorzystać te zasoby optymalnie. Dlatego tak ważny jest monitoring, żebyśmy wiedzieli jak sensownie wykorzystać infrastrukturę, żeby to było optymalne kosztowo, żeby tak naprawdę na końcu zarobić na tym startupie i nie palić pieniędzy w chmurze. Takie przykłady z życia, w których ja gdzieś tam uczestniczyłem, to na przykład ilość użytkowników w danej jednostce czasu. Na bazie tego można sobie skalować usługi, w AWS można to bardzo łatwo robić. Możemy dostawiać serwery albo je usuwać w zależności od tego, jaki mamy ruch na startupie, na usłudze, na produkcie.

ROBERT ZATYCKI
Czyli mówiąc inaczej, jeżeli moi użytkownicy korzystają z systemu po godzinie 17, a rano, w południe nie wykazują większej aktywności, to czy ja mogę tak sobie ustawić te usługi, żeby ilość serwerów zwiększać po południu, a np. po północy je wygaszać? I w ten sposób oszczędzać pieniądze?

ŁUKASZ SZRAMKO
Możesz tak zrobić, tylko tu się trzeba zastanowić czy warto pójść w rozwiązania serverless, które w teorii będą sobie same to kontrolowały, bo tak jak powiedziałem usługa działa wtedy, kiedy ty z niej korzystasz, albo pójść w rozwiązania, gdzie jest ten specjalista, który będzie zarządzał tą infrastrukturą w taki sposób, że będzie ją odpowiednio do jakiś parametrów wejściowych jak np. liczba użytkowników skalował. I tutaj też chyba warto postawić na takie rozwiązanie, gdzie mamy jakieś instancje działające, takie „wygrzane”, które tak naprawdę poradzą sobie z jakimś bieżącym ruchem, a tylko skalować w górę lub w dół, adekwatnie do tego, jak przychodzą i odchodzą użytkownicy. Takim przykładem ze świata deweloperskiego jest to, że bardzo fajnie takie rozwiązania sprawdzają się przy developmencie, gdzie mamy programistów pracujących w godzinach np. od 8 do 16 i nie ma sensu utrzymywać środowiska deweloperskie poza tymi godzinami, bo nikt z nich nie korzysta. Więc po co za nie płacić, jak można je wyłączyć? I to samo można przełożyć na produkcyjne zastosowania. Możemy zarządzać kosztami i to jest rola specjalistów, żeby po prostu taką informację przekazać i żeby oni informowali właściciela produktu, że są takie możliwości, że są takie rozwiązania, żeby to zrobić optymalnie kosztowo. Ale tutaj musi być duża świadomość.

ROBERT ZATYCKI
Świadomość i czujność, bo przyjście prawdziwych użytkowników do systemu pokazuje na ile mieliśmy rację, a na ile to były tylko nasze założenia czy wyobrażenia.

ŁUKASZ SZRAMKO
Przyjście użytkowników to naprawdę waliduje pomysł już na gotowym rozwiązaniu. I tutaj faktycznie my możemy się spodziewać czegoś, a dostaniemy coś, co nas zaskoczy – coś, czego się nie spodziewaliśmy – jakieś inne użycie naszej usługi.

ROBERT ZATYCKI
Następuje moment prawdy.

ŁUKASZ SZRAMKO
Tak, następuje moment prawdy i możemy albo się miło zaskoczyć albo niemiło zaskoczyć. I też pytania na etapie produkowania tego rozwiązania: czy my wcześniej jakoś walidowaliśmy te nasze oczekiwania, bo może być tak, że gdzieś pominęliśmy etap testów wydajnościowych i nam się wydaje, że ta usługa będzie działać dobrze dla tylu użytkowników, ile oczekujemy, a później się może okazać, że tych użytkowników jest jeszcze więcej, a nasza usługa i tak nie działa nawet dla tej liczby, którą prognozowaliśmy. Także już na etapie produkowania ważne jest robienie różnego rodzaju testów wydajnościowych, bezpieczeństwa – to też jest ważne. Wchodzimy w jakieś rozwiązania, które dotykają na przykład płatności, to tu trzeba bardzo mocno zadbać o bezpieczeństwo.

ROBERT ZATYCKI
To jeszcze wróćmy do mojej historii, która jest pretekstem do zwrócenia uwagi na to, że gdy staramy się nadążyć za trendami, za nowościami, które być może niekoniecznie staną się standardem w przyszłości, to możemy wpaść w ślepą uliczkę, która odbije się na naszej kieszeni.

ŁUKASZ SZRAMKO
To, o czym trzeba pamiętać to to, żeby nie zatracić się w takim podejściu, które obserwuję u programistów Javaskryptu, czy też innych technologii, że codziennie wychodzi nowy framework. Powinniśmy postawić na rozwiązania sprawdzone, stabilne, a nie podążać za tym, co rynek gdzieś tam nam narzuca i co jest w danej chwili modne. Musimy się skupić na tym, żeby to było stabilne, bo finalnie to będzie jakiś produkt, którego będą używać użytkownicy.

ROBERT ZATYCKI
I o tym musimy pamiętać budując startup albo własny projekt. To nasi użytkownicy go zweryfikują, a my powinniśmy umieć zareagować w odpowiednim momencie na ich potrzeby i móc zmieniać nasze usługi tak, aby im odpowiadały. Czy nasz budżet to wytrzyma? Nigdy nie wiadomo. Dlatego budując architekturę i infrastrukturę naszego projektu przepalajmy pieniędzy tam, gdzie to po prostu nie ma sensu.

Na dzisiaj tyle. Dziękuję za wysłuchanie naszej audycji do końca i zapraszam na kolejny odcinek. Nie zapomnijcie o subskrypcji naszego podcastu na swojej ulubionej Platformie. Wtedy wiemy, że to co robimy ma sens. Możecie również podrzucić mi kolejne tematy. Adres jest w opisie odcinka.

Do usłyszenia!

Nasz serwis internetowy używa plików cookies do prawidłowego działania strony. Korzystanie z serwisu bez zmiany ustawień dla plików cookies oznacza, że będą one zapisywane w pamięci urządzenia. Ustawienia te można zmieniać w przeglądarce internetowej. Więcej informacji udostępniamy w Polityce plików cookies.