4 ms·

No. No. No. No. Solve local development first and then maybe cloud dev. Reasons, just off the top of my head: - always-on internet connection is not always vi

No. No. No. No. Solve local development first and then maybe cloud dev. Reasons, just off the top of my head: - always-on internet connection is not always viable - intermittent and bad connections are a thing - which local environment do you support for accessing your cloud? An ever changing combination of "latest only" browsers, apps, and select IDE integrations? - how stable is your cloud environment? which features and versions of which tools will get deprecated tomorrow?

quickthrower2 4y ago
Plus latency. And cost. And slowness of a browser vs native console.
robertlagrant 4y ago
> Solve local development first and then maybe cloud dev I think this is it. Progressive enhancement beats graceful degradation.
KronisLV 4y ago
I've also seen "hybrid" setups in certain stacks, where the applications run locally but the database instance is shared amongst multiple developers for the same app version/branch. In my experience, that can be a way to deal with some resource requirement and licensing constraints, but can also be pretty horrible due to either bandwidth requirements or latency that adds up for many smaller queries that follow one another (e.g. when your app needs to shuffle around lots of data to load a page). Therefore, I'm tempted to agree that you should be able to relatively easily run as much as possible locally: especially a database with automated schema migrations and either data import or seeding (generating believable test data). Then again, one can see why something like that would be problematic in situations where you can have dozens of microservices, running all of which locally isn't entirely viable, yet re-architecting everything isn't either. It'd still be nice to be able to launch and test everything you need for a given scenario locally, even while using certain dependencies from a cloud dev environment.
- dmitriid 4y ago
  In the case when there's a staging environment, it would be nice to easily run the microservice you're working on locally. And/or mock some of the external stuff like BigQueries, Dataflows etc. You can't even test serverless functions properly because... you need the Amazon/Google server to run them on :)
  - KronisLV 4y ago
    > You can't even test serverless functions properly because... you need the Amazon/Google server to run them on :) This is unfortunate. I know that OpenFaaS and IronFunctions attempted to create a more vendor neutral offering that can run anywhere and still be usable, but neither really got the critical mass of attention/adoption for the large vendors to look in their direction. I'd say it's rather unfortunate, when you compare it with the success of S3, which has many self-hostable (and locally launchable) compatible solutions like MinIO and Zenko. Even managed databases are still often MySQL or PostgreSQL compatible, whereas FaaS doesn't seem to have quite gotten the sort of standardization.

quickthrower2 4y ago

Plus latency. And cost. And slowness of a browser vs native console.

robertlagrant 4y ago

> Solve local development first and then maybe cloud dev I think this is it. Progressive enhancement beats graceful degradation.

KronisLV 4y ago

I've also seen "hybrid" setups in certain stacks, where the applications run locally but the database instance is shared amongst multiple developers for the same app version/branch. In my experience, that can be a way to deal with some resource requirement and licensing constraints, but can also be pretty horrible due to either bandwidth requirements or latency that adds up for many smaller queries that follow one another (e.g. when your app needs to shuffle around lots of data to load a page). Therefore, I'm tempted to agree that you should be able to relatively easily run as much as possible locally: especially a database with automated schema migrations and either data import or seeding (generating believable test data). Then again, one can see why something like that would be problematic in situations where you can have dozens of microservices, running all of which locally isn't entirely viable, yet re-architecting everything isn't either. It'd still be nice to be able to launch and test everything you need for a given scenario locally, even while using certain dependencies from a cloud dev environment.

dmitriid 4y ago
In the case when there's a staging environment, it would be nice to easily run the microservice you're working on locally. And/or mock some of the external stuff like BigQueries, Dataflows etc. You can't even test serverless functions properly because... you need the Amazon/Google server to run them on :)
- KronisLV 4y ago
  > You can't even test serverless functions properly because... you need the Amazon/Google server to run them on :) This is unfortunate. I know that OpenFaaS and IronFunctions attempted to create a more vendor neutral offering that can run anywhere and still be usable, but neither really got the critical mass of attention/adoption for the large vendors to look in their direction. I'd say it's rather unfortunate, when you compare it with the success of S3, which has many self-hostable (and locally launchable) compatible solutions like MinIO and Zenko. Even managed databases are still often MySQL or PostgreSQL compatible, whereas FaaS doesn't seem to have quite gotten the sort of standardization.