Ja wszystko małe i średnie robię w technologii Serverless.
Różni dostawcy chmurowi oferują swoje rozwiązania ale ja używam AWS.
Statyczne strony stawiam na S3 Bucket - kosztuje to grosze nawet przy dużym ruchu.
Dynamiczne napędzam AWS Lambda i DynamoDB.
AWS ma usługę Amiplify , która ułatwia stawianie takich stron (czy to statycznych czy z backendem) i nie trzeba się samemu bawić z konfigurowaniem każdej innej usługi samemu.
Zasługą serverless jest, że się usługi do pewnego stopnia skalują automatycznie, resilience usług AWS, reliability strony (jak się wie co się robi) oraz cena - bo ta zależy głównie od popularności strony (więc jak ludzie jej nie używają to płacisz grosze za hosting). Wadą jest szybkość jeśli potrzebujesz aby strona ładowała się poniżej pół sekundy (ale dalej masz pewne opcje, które jak chcesz wydać kasę umożliwiają Ci przyspieszenie wszystkiego).
Dobrym rozwiązaniem są też Vercel oraz Netlify - zwłaszcza jak piszesz strony w nowoczesnych frameworkach jak SvelteKit czy Vue - bo Ci dostawcy hostingu stron wspierają nowoczesny wokflow budowania stron oraz super łatwy deployment z tych nowoczesnych frameworków przy minimalnej konfiguracji.
@koszotorobur nie masz awersji do bycia "provider-bound"? Czy traktujesz to biznesowo-pragmatycznie, że skoro teraz się opłaca to teraz tak robisz, a jak AWS zacznie robić praktyki monopolistyczne to się zaczniesz martwić?
Tak czy siak, brzmi jak w chuj dynamiczna iteracja. Dobra porada dla ludzi którzy chcą coś zrobić.
@wombatDaiquiri - zawsze w jakiś sposób jesteś vendor locked - czy to przez providera hostingu czy przez frameworka jakiego używasz do robienia strony.
Wiadomo, możesz sobie wszystko napisać w czystym HTMLu i JavaScripcie, i robić deploymenty skryptami do gołego Linuxa - a jak już jesteś ogarnięty to budować kontenery i je uruchamiać na serwerze przy pomoc Compose - wtedy wszystko będzie przenośne... niemniej:
Ciągle działająca instancja/VPS/bare metal server kosztuje i do tego potrafi się wywalić i jak nie masz jakiegoś Auto Scaling czy auto restartu z monitoringu to musisz sam ręcznie naprawiać
Pisanie bardziej skomplikowanych rzeczy w czystym HTMLu i JavaScripcie pochłania mnóstwo czasu i jest trudne do utrzymania
Ja jestem pragmatykiem bo za długo już w tym wszystkim siedzę i wolę jak mi wszystko działa - a jak upadnie to się samo ma się podnieść abym nie musiał się o to martwić i spędzać czasu na naprawianiu (co jest niezwykle ważne jak już się ma kilka stron i klientów trujących dupę). Do tego lubię jak strona nie generuje kosztów jak jest nieużywana.
Jak już się tak boisz bycia zależnym od providera hostingu to ogarnij SvelteKit bo on ma możliwość budowania strony przygotowanej pod różnych dostawców (dzięki adapterom ) a także do działania pod NodeJS Server, który można uruchomić na każdym Linuksie lub skonteneryzować (a co za tym idzie uruchomić na każdym VPSie, instancji w chmurze czy nawet na serwerze bare metal pod Twoim biurkiem czy Centrum Danych)... no ale wtedy jesteś znowu zależny od Frameworka
Jak sam nie sprawdzisz jak różne podejścia działają, czy jesteś w stanie je ogarnąć, czy Ci pasują i jakie koszty generują (nie tylko koszty hostingu ale developmentu, deploymentów oraz supportu) to nie będzie wiedział co wybrać
Aha, no i oczywiście ja robię wszystko co możliwe jako kod by jak najmniej robić ręcznie:
@koszotorobur ja planuję (a właściwie już działam) sobie ustawić pod biurkiem k8s i za pomocą tunelowania od cloudflare z niego hostowac strony. Ale to dość specyficzny setup więc zastanawiałem się jakie są popularne. Twój brzmi pragmatycznie i sensownie. Godnie polecenia.
@wombatDaiquiri - ja już przez to wszystko przechodziłem i prywatnie i profesjonalnie a więc pozwól, że podzielę się spostrzeżeniami:
Posiadanie własnego klastra K8s jest świetne do nauki ale ktoś ten klaster musi utrzymywać (OS Patching, K8s versions upgrade, monitoring)
Nawet jak ISP oferuje Static IP i symetryczny upload to dalej jest to pewnie zwykły dostawca internetu domowego - więc jak zaczniesz coś hostować dla klientów to szybko zobaczysz jak kiepskiej jakości jest to internet (bo dotkną Cię problemy których wcześniej nie zauważałeś). W centrach danych jest wielu dostawców, co mają ogromną przepustowość i skonfigurowany automatyczny BGP Failover - coś co zaczniesz doceniać jak będziesz mieć problemy ze swoim ISP.
Jeśli będziesz tunelował ruch to tunele też padają, więc musisz monitorować i ogarnąć jakiś automatyczny restart tunelu.
Nie wiem ile nodów będziesz miał w swoim klastrze ale komputery też padają i dyski w nich też - więc będziesz musiał zainteresować się rozwiązaniami, które pozwolą Ci mieć data redundacy and reliability... no i robienie automatycznych backupów.
Jeśli oprzesz wszystko na kontenerach to musisz mieć swój wewnętrzny container image registry do trzymania w nim obrazów kontenerów i robienia rzeczy w nieupośledzony sposób - kolejna usługa do hostowania
Cokolwiek padnie to Ty musisz sprawdzić i naprawić - pierwsza nocka zarwana na to to może być fun... kolejne już niekoniecznie
Musisz ogarnąć sobie jakiegoś UPSa aby w razie braku prądu serwery mogły się normalnie powyłączać - do tego dobry UPS chroni przed przepięciami w sieci i jest szansa, że on się tylko spali w czasie burzy a nie Twoje serwery
Ja może jestem już za stary i maiłem swoje szanse na nauczenie się tego wszystkiego - więc teraz preferuję wygodę i kiedy rzeczy po prostu działają przy moim minimalnym udziale.
@wombatDaiquiri Zależy, najczęściej AWS, a jeśli projekt jest typowo mój, to mam taką jakby chmurkę w domu postawiona na rasberrach w matrycy i tam sobie mam postawione serwisy S3 i hostuje u siebie.
Standardowy load balancing I autoscaling backendowy Docker plus jakieś skalowanie manualne na cap w razie potrzeby jak klient nie chce płacić więcej.
Najlepiej zaczac od azura/aws/gcp jak masz pewność że klient będzie płacić za utrzymanie.
@vinclav - do swoich pierdół to self-hosted może i starczy - ale w przypadku profesjonalnych rzeczy nie lubię mieć zależności od mojego sprzętu, mojego ISP i mojego dostawcy energii.
Serverless na AWS sprawdza się wymienicie właśnie dla klientów, którzy mają problem z płaceniem bo nieużywane usługi Serverless od AWSa nie generują dużych kosztów (a jak klient stara się przycwaniaczyć i generuje duży ruch gdy zamówił "małą stronkę" to AWS oferuje dobry monitoring oraz można ustawić throttling dla backendu na AWS API Gateway).
@vinclav o to mam pytanie - w jaki sposób dostajesz ruch do swojej sieci lokalnej? To się jakoś dogadać trzeba z OSP indywidualnie czy zewnętrzne IP to standardowa oferta?
@wombatDaiquiri Raczej nie nastawiam się na duży ruch, dlatego nowe rzeczy wrzucam na Netlify (w przypadku użycia Remix), albo na Vercel (w przypadku użycia Next.js). Głównie ze względu na wygodę, skonfigurowane CI/CD etc. W moim przypadku traffic nie jest duży, tak więc jeszcze nie wbiłem się w płatny plan i lecę na darmowym, ale słyszałem, że Vercel może drogo wyjść w przypadku sporego ruchu.
@renkeri - hostingi takie jak Vercel oraz Netlify to przede wszystkim wygoda - świetne jak trzeba coś zrobić na szybko lub w ogóle zacząć zabawę z robieniem stron internetowych.
Obojętnie z czego się korzysta to warto monitorować koszty bo po przekroczeniu pewnego pułapu taniej swoje aplikacje przenieść na swoje własne konto AWS i uruchamiać jako Serverless albo skonteneryzować i uruchamiać gdzieś na współdzielonym serwerze/instancji.
A jak już ma się naprawdę sporo aplikacji to warto zainwestować we własny porządnie skonfigurowany klaster Kubernetesa ale nie taki single-node - tylko taki który zapewnia Reliability (czyli minimum 3/5) - który w razie potrzeby można zawsze rozbudować. Do tego w chmurze można poczynić pewne oszczędności jeśli zdeklaruje się używać serwery na dłuższy czas (na przykład na rok czy nawet na 3 lata).
