Earlier quoted context omitted.
How do you develop your functions? Using Kubernetes as a development platform also applies to serverless, we have articles with Cloud Run and OpenFaaS: https://www.openfaas.com/blog/painless-serverless-developmen... The idea is to have replicable and production-like dev environments, no matter your deployment tool
Docker setup that allows me to test my functions locally - I have a wrapper that simulates the handoff between AWS ALB and AWS Lambda. When ready, I merge into master, push, and they deploy to AWS through CI - I have simple Python scripts that manage Lambda Layer creation, environment variable configuration, etc. Don't really need much more than this.
Instant dev environments for cloud-native apps
31–40 of 51 posts
Re: Instant dev environments for cloud-native apps
#32Earlier quoted context omitted.
I develop in the cloud! Serverless Framework deploys are now less than three seconds. It's almost exactly like `run watch` now! I deploy to a dev AWS account, then a staging AWS account, and then promote to prod out of github. Check it out: https://github.com/serverless-components/
That really depends on the size of your app. You also lose the ability to run debuggers. Not to mention how hard is to run serverless java applications, which is the dominant enterprise programming language.
Re: Instant dev environments for cloud-native apps
#33Sorry, this rubbed me the wrong way. This is almost a non-statement. It sounded condescending, but that may just be me misunderstanding your tone.
The trick is in how you define that value and how you deliver it quickly. You will probably get a lot more mileage out of building an understanding of what your users need than out of having a "blazing fast inner-loop".
Your users are developers and I'm not convinced you understand what we need. You don't talk about how we can handle service dependencies - How to keep a development database up-to-date and useful for each developer? Should there be one dev database per namespace or a single dev database that the whole team uses? How should third-party APIs be integrated into the development environment? And on and on.
Just running `kubectl create namespace` and rsyncing my code directory into a dev container in that namespace (?) doesn't even get me even close to a proper dev environment. It doesn't solve any REAL problems I have setting up a Cloud Native dev environment.
Re: Instant dev environments for cloud-native apps
#34"When I am coding I’m focused on just one thing: delivering value to my users as fast as possible." Sorry, this rubbed me the wrong way. This is almost a non-statement. It sounded condescending, but that may just be me misunderstanding your tone. The trick is in how you define that value and how you deliver it quickly. You will probably get a lot more mileage out of building an understanding of what your users need t…
Re: Instant dev environments for cloud-native apps
#35"When I am coding I’m focused on just one thing: delivering value to my users as fast as possible." Sorry, this rubbed me the wrong way. This is almost a non-statement. It sounded condescending, but that may just be me misunderstanding your tone. The trick is in how you define that value and how you deliver it quickly. You will probably get a lot more mileage out of building an understanding of what your users need t…
Re: Instant dev environments for cloud-native apps
#36"When I am coding I’m focused on just one thing: delivering value to my users as fast as possible." Sorry, this rubbed me the wrong way. This is almost a non-statement. It sounded condescending, but that may just be me misunderstanding your tone. The trick is in how you define that value and how you deliver it quickly. You will probably get a lot more mileage out of building an understanding of what your users need t…
Agreed, this is a topic on my mind, we have a need for better cloud based dev environments so this article's titled appealed to me, but it wasn't answering any questions or aligning with common issues.
Re: Instant dev environments for cloud-native apps
#37Totally disagree with that, developers should be sympathetic to the environment there code runs in, definitely spend the 5 mins to install kube through docker desktop and be done.. shorter feedback loop then too having it run properly local.
Re: Instant dev environments for cloud-native apps
#38I deal with a lot of "works on my machine" bugs, but the reason is we can't go cloud native. Or cloud. I'm really interesting in a cross platform, rootless and low overhead containerization solution for native desktop apps. I haven't seen one that fits my use cases yet.
Would something like Okteto Enterprise fit your needs? https://okteto.com/docs/enterprise
Re: Instant dev environments for cloud-native apps
#39Earlier quoted context omitted.
Agreed, this is a topic on my mind, we have a need for better cloud based dev environments so this article's titled appealed to me, but it wasn't answering any questions or aligning with common issues.
We would love to talk more about the issues you have. If you want to schedule a call just drop us an email.
Re: Instant dev environments for cloud-native apps
#40“developers shouldn’t install Kubernetes locally as this requires hardware resources and deeper knowledge about this technology” Totally disagree with that, developers should be sympathetic to the environment there code runs in, definitely spend the 5 mins to install kube through docker desktop and be done.. shorter feedback loop then too having it run properly local.
I agree that "developers should be sympathetic to the environment there code runs in". But that's about where the code runs in production, not where the developer runs it while coding. That's why we are pushing towards using remote clusters, so that you are developing on an environment that's as close to prod as possible.
In my opinion, Minikube, Docker for Desktop, Kind and others present two big challenges: First, it's not trivial to run them locally. They require extra memory, cpu and battery, they have issues starting/stopping (I don't use my local cluster that often, and I've spent way more than 5 minutes just starting/stopping/troubleshooting it). And, at the end, they have different components (load balancers, disk, network) and configuration from a remote kubernetes clusters, creating more dev-prod skew.
Second, the feedback loop is not that fast. You still need to either mount volumes (which is slow if you handle multiple files, like node's node_modules folder) or end up building containers to validate your changes. Sure, you don't have to push and pull them, but what if you didn't have to even build them?