@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:

• Infrastructure as Code
  

• Pipeline/Build as Code
  

• Conatiners as Code (Containerfile oraz Compose)

@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.

@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 dwa adresy IP, dwa routery. Koszt niewiele większy. Wcześniej używałem dyndns, ale to stare dzieje.

@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).