Live data from Hacker News

Cloud development environments tame complexity by reducing state

medium.com

41–42 of 42 posts

Re: Cloud development environments tame complexity by reducing state

#41

Earlier quoted context omitted.

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 an…

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

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

Re: Cloud development environments tame complexity by reducing state

#42
At (former employer) were did a good a pretty good job at solving this. We were deployed to AWS, using EKS, SQS, Aurora, S3 and a small amount of lambda. When a new developer got onboarded, they were given their own slice of the dev environment: ingress, EKS namespace, S3 buckets, database and SQS queues. But it was still running within the same VPC and k8s cluster, with the same IAM (all those roles and policies that matched production and we're an important piece of testing). There was little additional infrastructure complexity, and no extra cost since the partitioning of usage-priced services and EKS namespaces is free. Developers also had access to shared infrastructure and the latest changes made by their colleagues. But everyone also had their own local microk8s + minio + mysql, so as long as they were happy to deploy the latest full testing release of everybody else's stuff, they could use that. When using their local cluster, they still had access to some cloud stuff like SQS and S3 (but not Aurora, they had to reply on a k8s deployed mysql).

We saw the cloud environment as an essential tool to provide the developers with, but not a tool that it was essential for developers to use. In fact, we had a preference for keeping dev working, so initial work on large changes should be done locally and deployed to dev once they're working. Dev was there to protect the testing environment and make sure that developers had a "real" cloud environment.

In other words, you don't have to deploy to dev, but if you break the testing environment because you didn't deploy to dev, there would be raised eyebrows.

Post reply on HN