3 ms·

As a starting point I'd go all-in on serverless because even though it's not necessarily the fastest response times or cheapest, it does let you completely igno

by benoau 2y ago

As a starting point I'd go all-in on serverless because even though it's not necessarily the fastest response times or cheapest, it does let you completely ignore several sets of scaling challenges till the price matters. So I'd go serverless for spidering, indexing and user-facing APIs. UIs I'd go static HTML on a CDN. For database, first I'd lean on plain file s3-like storage as much as possible for spidering and indexing data and try to keep the user-facing database under a couple hundred terabytes, I'd probably favor some bare metal at this point but that will fit on some "db as a service" providers.

conradklnspl 2y ago
While I agree that for user-facing APIs, serverless can both help handling load spikes and keep costs low, how would serverless help with spidering and indexing? Spidering and indexing are processes that would most likely run continuously for any search engine like Google or Kagi. There is always data to update and new web pages being created. Thus, they would benefit from dedicated servers from the get go for costs. Ahrefs posted an interesting article on this topic: https://tech.ahrefs.com/how-ahrefs-saved-us-400m-in-3-years-by-not-going-to-the-cloud-8939dd930af8 https://tech.ahrefs.com/how-ahrefs-saved-us-400m-in-3-years-... Then again, you could use serverless on your own dedicated servers to benefit from the advantages of both.
- benoau 2y ago
  > how would serverless help with spidering and indexing? Because these are tasks that lend themselves to massive concurrency and serverless makes that instantly possible. If you were going to put this on your own hardware that will be a pretty big project of its own. How many months of dev time can you budget for rolling your own indexing/spidering infrastructure and getting that just right? How does that affect your launch date?
  - deleted 2y ago
    [deleted]

by benoau 2y ago

conradklnspl 2y ago

While I agree that for user-facing APIs, serverless can both help handling load spikes and keep costs low, how would serverless help with spidering and indexing? Spidering and indexing are processes that would most likely run continuously for any search engine like Google or Kagi. There is always data to update and new web pages being created. Thus, they would benefit from dedicated servers from the get go for costs. Ahrefs posted an interesting article on this topic: https://tech.ahrefs.com/how-ahrefs-saved-us-400m-in-3-years-by-not-going-to-the-cloud-8939dd930af8 https://tech.ahrefs.com/how-ahrefs-saved-us-400m-in-3-years-... Then again, you could use serverless on your own dedicated servers to benefit from the advantages of both.

benoau 2y ago
> how would serverless help with spidering and indexing? Because these are tasks that lend themselves to massive concurrency and serverless makes that instantly possible. If you were going to put this on your own hardware that will be a pretty big project of its own. How many months of dev time can you budget for rolling your own indexing/spidering infrastructure and getting that just right? How does that affect your launch date?
- deleted 2y ago
  [deleted]