[lutecki]

Przy jakiej wielkości serwisie warto myśleć o AWS? Szukam czegoś skalowalnego pod projekt na Django, który ma szansę być duży, nawet mędzynarodowy, ale 900 USD na start (bo tyle z kalkulatora mi wychodzi za przestrzeń, bazę danych i web) to IMO dużo.

#hosting #webdev #internet

[bi-tek]

@lutecki: wszystko jest zależne od liczby Userow, na początek do 100-200(w tym samym momencie) dałbym to na vps

[karid]

@lutecki: digitalocean chyba jakiś czas temu odpalił ficzer automatycznego skalowania

[zwierzak40]

@lutecki: Musisz przeliczyć, za mało danych żeby Cię wyręczyć. Weź pod uwagę spore zniżki za instancje jeżeli są one zamówiony na dłuższy czas. Z tego co pamiętam to nawet 50% zniżki.

Dobrze jest nie pchać się w cloud zbyt wcześnie, chyba że jesteś pewny, że tego potrzebujesz (duży, zmienny ruch) i że potrzebujesz tego od razu na skalę globalną. W przeciwnym razie lepiej zacząć od VPS -> dedyk -> rozdzielnie

[lutecki]

@zwierzak40: właśnie tak myślę że do początkowej fazy (zakładając że nie jest się "startupem" czyli czymś co na tylko generować koszta i ruch) są lepsze rozwiązania niż cloud.

[Jurigag]

@lutecki: może DO taniej wyjdzie?

[ppawel]

@lutecki:

ma szansę być duży

To nie dzieje się samo, na pewno będziesz trochę wcześniej wiedzieć, że czas się przesiąść na rozwiązanie skalowalne. No i IMHO lepiej niespodziewanie musieć zainwestować niż w zmiany niż niespodziewanie musieć ciąć koszty...

[Zergall]

@lutecki: Chyba nic z tego nie będzie, bo AWS zostało rozwiązane w 2001 ( ͡° ͜ʖ ͡°)

[zwierzak40]

@lutecki: Ja miałem projekt zakończony porażką, gdzie zaczynałem od Oktawave - masa niepotrzebnych kosztów, bardzo drogie szczególnie operacje dyskowe gdy jest ich dużo. Kolejny projekt nad którym obecnie pracuję, mimo że także zawiera chmurowe rozwiązania to jest znacznie bardziej mniej rozrzutny, a w każdej chwili gotowy do przeniesienia na wysoko-skalowalną infrastrukturę. Część (ta najbardziej niestabilna pod kątem potrzeb infrastrukturalnych) jest w ogóle wydzielona do mikroserwisów, które w obecnej fazie alpha obsługują tanie VPSy, a docelowo prawdopodobnie AWS Lambda. Reszta, bardziej stabilna będzie mogła dłużej pozostać na bardziej budżetowych rozwiązaniach.

Druga sprawa - projekty rozwijają się zazwyczaj zdecydowanie wolniej, niż jakby chcieli ich twórcy. A gdy projekt osiąga tak duży sukces, że serwery nie wyrabiają, to wtedy pieniądze przestają grać większą rolę i zawsze - pod kątem sprzętu - znajdzie się dobre rozwiązanie. Już lepiej skupiać się na skalowalności samej aplikacji.

Ewentualnie jakimś półśrodkiem, jeżeli np. nie chce Ci się bawić w zarządzanie serwerami (ja np. nie lubię się w tym babrać mimo dość sporego doświadczenia) to możesz skorzystać z jakiegoś rozwiązania PaaS - np. polskiego Unicloud. Unicloud korzysta z Jelastica, który z kolei jest wykorzystywany w firmach właściwie na całym świecie. Wyjdzie drożej niż VPS czy dedyki, ale zapewnia pewną skalowalność (pod wieloma względami nawet lepszą niż AWS, e24cloud, Oktawave itp, ale pod wieloma gorszą) i koszty odpowiadające zużyciu zasobów. Dla projektów we wstępnej fazie świetne rozwiązanie. I przede wszystkim - bardzo wygodne z perspektywy

[lutecki]

@zwierzak40: Dzięki za podzielenie się wiedzą i doświadczeniami. Widać, że są spore :-) Jestem w trakcie ustalania szczegółów z firmą programistyczną która (prawdopodobnie) będzie to kodowała. To czy backend party o Django to dobry czy zły pomysł to oczywiście inna sprawa (też muszę zasięgnąć rady), ale napisz proszę na czym polega przygotowanie aplikacji pod chmurowe rozwiązania? Chciałbym z nimi to przegadać aby - jeśli - serwis się rozrośnie, nie będzie

[zwierzak40]

ale napisz proszę na czym polega przygotowanie aplikacji pod chmurowe rozwiązania?

@lutecki: To dziesiątki i setki niuansów, które trzeba wziąć pod uwagę, ale niestety są one zależne niemal od wszystkiego. Od języka, frameworka (niektóre mają narzędzia do łatwiejszego wdrożenia na chmurze), technologii pobocznych (np. różne bazy powinno się nieco inaczej obsługiwać, podobnie jak z storagem obiektowym - patrz np. eventual consistency czy szerzej CAP theorem), ale przede wszystkim potrzeb i strategii ich realizacji. Inaczej powinno się napisać program księgowy, gdzie zgubienie jednego wpisu w bazie danych (np. faktury VAT) po tym, jak widział i mógł zapisać ją użytkownik i nadpisanie tego samego numeru inną fakturą - innego klienta - może mieć katastrofalne skutki. Podczas gdy piszesz aplikację np. zbierającą dane z tysięcy stacji stacji meteorologicznych to zgubienie nawet dużej procentowo ilości danych nie będzie tragiczne. Jeszcze inaczej należałoby podejść do systemu obsługującego np. centrum ratunkowe (w sensie 112 itp.) - tam lepiej przez chwilę nie wiedzieć co się dzieje na drugim końcu Polski niż utracić całkowity dostęp do aplikacji. Analogicznie, w aplikacji księgowej żeby zapobiec nadpisywaniu, gdy "fragmenty" aplikacji rozrzucone lokalizacyjnie utracą połączenie - należy im odebrać prawo tworzenia numerów faktur VAT i ich generowania, zostawiając tą możliwość tylko jednemu (najważniejszemu oddziałowi). W takiej sytuacji dobrze jakby numer faktury był generowany z jednego miejsca. (to wszystko przy założeniu, że prawo narzuca wspólną numerację w obrębie całej firmy, żeby pokazać jak to wygląda).

Inny problem - zarządzanie plikami. Na początku masz jedną instancję w chmurze i wszystko gra. Nagle masz nagły skok użytkowników. Zobacz, co się dzieje z plikami, które oni generują lokalnie. W pierwszej opcji - każda instancja ma pliki "swoich" użytkowników (i trzeba gdzieś zapisywać gdzie są pliki konkretnego użytkownika), w drugiej opcji - można zrobić synchronizację plików pomiędzy instancjami. Tylko wtedy każdy plik kosztuje (w sensie bajtów, ale i pieniędzy) tyle razy, ile masz instancji. Teraz na szczęście jest storage obiektowy (jak S3, e24files, bardzo tani Backblaze B2, OVH object storage). Ale znowu - konsystencja jest różna dla różnych magazynów. A potrafi nawet w ramach samego S3 być odmienna dla różnych regionów ( ͡° ͜ʖ ͡°). W niektórych aplikacjach,

[lutecki]

@zwierzak40: Dzięki za wykład. Widzę (ale nie rozumiem) ile jest problemów do rozwiązania przy aplikacji która "może być duża". Napisałem Ci PW.

[Oktawave]

@lutecki @zwierzak40 Generalnie to mamy rozdziawione usta, widząc, że takie dyskusje są w ogóle w naszym Internecie możliwe. Szacunek, Panowie.

Zachęcamy też do przetestowania rozwiązania z nami:

1. można zacząć od programu Freetier (https://www.oktawave.com/pl/freetier), zobaczyć, jak się komuś pracuje z