Live data from Hacker News

Instant dev environments for cloud-native apps

okteto.com

31–40 of 51 posts

Re: Instant dev environments for cloud-native apps

#31

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.

Right, that works. I think that setup does not scale well for large teams or if you are not able to run all your services locally due to resource constraints

Re: Instant dev environments for cloud-native apps

#32

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

Don't take me wrong, I am a big fun of serverless. We use it in production too. But I also think it does not cover a large percentage of the deployment spectrum, at least for a few years. And serverless can also benefit from tools like Okteto

Re: Instant dev environments for cloud-native apps

#33
"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 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…

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

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

Those are really good questions, we have similar requests from our users. We don't have general answers yet, but let me explain a few solutions we have in place. Data: data is hard. There are teams that workout the problem with fixtures and a database per developer. We also have a PoC for cloning namespaces and its data using Velero (this way, you can clone staging on your own developer namespace). We also have teams that have a dev database for all the frontend developers... Service dependencies: we push to define your dependencies using one or more Helm charts. This way, developers have a one-click experience to deploy the full stack on their namespaces. Once the app is running, developers use the Okteto CLI to put on dev mode any service and start synching their local code changes. Some parts of the stack might be shared by all the developers in a common namespace. Third-party APIs: this is also a wide spectrum, but our experience says it is easier to integrate them at the cluster level that in every developer workstation.

Re: Instant dev environments for cloud-native apps

#36
post #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…

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

#37
“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.

Re: Instant dev environments for cloud-native apps

#38
post #26

I 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

Unless I'm reading something wrong that has nothing to do with what I'm talking about.

Re: Instant dev environments for cloud-native apps

#39
post #34

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

Well first off, we don't touch Kubernetes, so probably not a product we're looking at either way.

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.

Ramiro here (co-founder of Okteto)

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?

Post reply on HN