3 ms·

As a systems guy, I appreciate stories about developers learning that systems are complicated, and the latest and greatest technology is often not as stable or

As a systems guy, I appreciate stories about developers learning that systems are complicated, and the latest and greatest technology is often not as stable or optimized as hoped. Although, I do have high hopes for Key:Value store data repositories. TANSTAAFL.

rdtsc 14y ago
However as a developer guy I am glad they picked a technology that let them make quick prototyping progress and started shipping a product. Remember only successful companies have to worry about scaling. Un(/not yet)-successful company have to worry about shipping first, then scaling. So perhaps Saucelabs reached that milestone, and they simply have outgrown the original technology that helped them ship. Who knows, maybe if they had spent time re-implementing a REST interface on top of MySQL or re-implementing Futon for doing debugging, we might not even have heard about Saucelabs these days.
- MattRogish 14y ago
  +1 for op and gp. At a previous gig, we had the opportunity of using SQLite or a raw JSON store for a mobile application we were building. Although SQL would've been the "right" way to do it, JSON implementation was basically a no-op given our JS-based framework. It did make a few things harder later on but we were better equipped to make a change around the time we actually needed to. If we had spent a lot of time up front developing for SQLite, we'd have paid an overhead tax for years for no good reason. And possibly wouldn't have made it to the point in which we needed to make a change. That said - our use case was incredibly narrow (read only data store, server outputs JSON anyway, etc.) and so we made a reasoned choice. If we needed complex queries/joins, updates/deletes, incremental loading, etc. - then a JSON store would've been terrible.
empthought 14y ago
Key-value stores like dbm since the 1980s? You're not exactly going out on a limb with those high hopes. :)

rdtsc 14y ago

However as a developer guy I am glad they picked a technology that let them make quick prototyping progress and started shipping a product. Remember only successful companies have to worry about scaling. Un(/not yet)-successful company have to worry about shipping first, then scaling. So perhaps Saucelabs reached that milestone, and they simply have outgrown the original technology that helped them ship. Who knows, maybe if they had spent time re-implementing a REST interface on top of MySQL or re-implementing Futon for doing debugging, we might not even have heard about Saucelabs these days.

MattRogish 14y ago
+1 for op and gp. At a previous gig, we had the opportunity of using SQLite or a raw JSON store for a mobile application we were building. Although SQL would've been the "right" way to do it, JSON implementation was basically a no-op given our JS-based framework. It did make a few things harder later on but we were better equipped to make a change around the time we actually needed to. If we had spent a lot of time up front developing for SQLite, we'd have paid an overhead tax for years for no good reason. And possibly wouldn't have made it to the point in which we needed to make a change. That said - our use case was incredibly narrow (read only data store, server outputs JSON anyway, etc.) and so we made a reasoned choice. If we needed complex queries/joins, updates/deletes, incremental loading, etc. - then a JSON store would've been terrible.

empthought 14y ago

Key-value stores like dbm since the 1980s? You're not exactly going out on a limb with those high hopes. :)