Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Instant dev environments for cloud-native apps

okteto.com

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Instant dev environments for cloud-native apps

#41

Post by Ramiro »

davedx wrote: post #23
graphememes wrote: post #17

Earlier quoted context omitted.

I believe they mean their application relies on third-party integrations that would be burdened by such a fast loop

I mean its harder to route webhooks to twenty random dev machines than to a couple of DTAP servers.

There are challenges on this model for sure. A big advantage is that, by routing to the dev environments, you can have the dev interact directly with the webhook when they code, instead of having to wait for a shared environment to test integrations. This is pretty useful, specially if your application depends a lot on webhooks for it's main functioning.

This is an area where I'm particularly interested in. We are constantly experimenting in ways to better integrated it into our idea of remote development environments.

Re: Instant dev environments for cloud-native apps

#42

Post by nhoughto »

Ramiro wrote: post #40
nhoughto wrote: post #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.

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…

Yeah I guess that might work for some workflows, we try and keep local as close to prod as possible, and how we build local artifacts that we test as close to how we build prod artifacts. Giving us a fighting chance of being able to repro prod bugs for example, if a team was making a different set of trade offs that would work.

Thinking about it more, we have had the problem of docker desktop using a bunch of memory and slowing productivity, so shipping that giant vm elsewhere would solve for that, can I spin up 16gb+ namespace/env in okteto?

Re: Instant dev environments for cloud-native apps

#43

Post by Ramiro »

nhoughto wrote: post #42
Ramiro wrote: post #40

Earlier quoted context omitted.

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…

Yeah I guess that might work for some workflows, we try and keep local as close to prod as possible, and how we build local artifacts that we test as close to how we build prod artifacts. Giving us a fighting chance of being able to repro prod bugs for example, if a team was making a different set of trade offs that would work. Thinking about it more, we have had the problem of docker desktop using a bunch of memory…

If your kubernetes cluster can support a 16GB pod, it will work with okteto.

That said, the pattern we recommend to follow is to split it into smaller dev envs. That makes it easier to manage, and allows you to have dedicated dev envs for different parts of your app (e.g. your API dev env and your frontend dev env).

Re: Instant dev environments for cloud-native apps

#44

Post by nhoughto »

Ramiro wrote: post #43
nhoughto wrote: post #42

Earlier quoted context omitted.

Yeah I guess that might work for some workflows, we try and keep local as close to prod as possible, and how we build local artifacts that we test as close to how we build prod artifacts. Giving us a fighting chance of being able to repro prod bugs for example, if a team was making a different set of trade offs that would work. Thinking about it more, we have had the problem of docker desktop using a bunch of memory…

If your kubernetes cluster can support a 16GB pod, it will work with okteto. That said, the pattern we recommend to follow is to split it into smaller dev envs. That makes it easier to manage, and allows you to have dedicated dev envs for different parts of your app (e.g. your API dev env and your frontend dev env).

Ah I see, I assumed it was a okteto managed cluster. I should rtfm more =)

Splitting parts of an env is against our principles tho, put everything together and test against real endpoints where possible, there is no api dev env or web or app, there is just a dev env.

Re: Instant dev environments for cloud-native apps

#45

Post by Ramiro »

nhoughto wrote: post #44
Ramiro wrote: post #43

Earlier quoted context omitted.

If your kubernetes cluster can support a 16GB pod, it will work with okteto. That said, the pattern we recommend to follow is to split it into smaller dev envs. That makes it easier to manage, and allows you to have dedicated dev envs for different parts of your app (e.g. your API dev env and your frontend dev env).

Ah I see, I assumed it was a okteto managed cluster. I should rtfm more =) Splitting parts of an env is against our principles tho, put everything together and test against real endpoints where possible, there is no api dev env or web or app, there is just a dev env.

There's two parts to Okteto. The open source project (https://github.com/okteto/okteto), which launches development environments and works with any kubernetes distribution.

And Okteto Cloud (https://okteto.com) our development platform for Kubernetes Applications, that integrates everything you need to build cloud native apps (development environments, a build service, a private registry, SSL endpoints, etc...)

Re: Instant dev environments for cloud-native apps

#46

Post by freepor »

zomglings wrote: post #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 t…

Iteration speed is sometimes an effective substitute for deep product insight. If you are a Steve Jobs you can go off and spend a few years building something in secret because you know people are going to love it when you show it to them. For everyone else, being able to ship stuff quickly offers a chance to maximize the number of spaghetti strands they can throw at the wall until they find one that sticks.

Re: Instant dev environments for cloud-native apps

#47

Post by xmodem »

I'm going to check out your product on the weekend. It looks pretty neat. But it would be cool to hear a bit more about how you achieve some of your stated claims. Particularly working with debuggers. The kubernetes/minikube setup at my current role seems downright hostile to debugging -

* We need to maintain separate profiles for running apps in debug mode, to expose the java debug port to the host and supply the right JVM options

* Latency - even to a VM running on the same computer when compared to running a local process - means a significantly worse debugging experience

* Don't leave your debugger paused for too long, or your healthchecks will fail and your app will get rebooted from under you

* And forget about trying to debug something that happens on application boot

Re: Instant dev environments for cloud-native apps

#48

Post by davedx »

Ramiro wrote: post #41
davedx wrote: post #23

Earlier quoted context omitted.

I mean its harder to route webhooks to twenty random dev machines than to a couple of DTAP servers.

There are challenges on this model for sure. A big advantage is that, by routing to the dev environments, you can have the dev interact directly with the webhook when they code, instead of having to wait for a shared environment to test integrations. This is pretty useful, specially if your application depends a lot on webhooks for it's main functioning. This is an area where I'm particularly interested in. We are co…

> you can have the dev interact directly with the webhook when they code

But how? A webhook needs to call a single endpoint (with a dns/ip pair). How can you route incoming webhooks from a 3rd party vendor to every dev machine running the service locally?

Weird people downvoted my previous comment on this, it's a genuine problem with this "DTAP on your machine" setup, isn't it?

Re: Instant dev environments for cloud-native apps

#49

Post by Ramiro »

xmodem wrote: post #47

I'm going to check out your product on the weekend. It looks pretty neat. But it would be cool to hear a bit more about how you achieve some of your stated claims. Particularly working with debuggers. The kubernetes/minikube setup at my current role seems downright hostile to debugging - * We need to maintain separate profiles for running apps in debug mode, to expose the java debug port to the host and supply the ri…

For debuggers, we wrote a few guides like this one: https://okteto.com/blog/how-to-develop-node-apps-in-kubernet....

> We need to maintain separate profiles for running apps in debug mode, to expose the java debug port to the host and supply the right JVM options

Yes, you should. This is something you can do in the 'okteto.yml' file. You can specify different environment variables, different commands and even a different image (e.g. an image with your dev tools and debugger, which you don't need in prod).

> Latency

This can be a challenge, for sure, specially if you have a bad network connection. In our experience, debuggers and incremental file sync don't require too much bandwidth.

> Don't leave your debugger paused for too long

This has happened a lot to me. In the latest version we introduced a switch to disable healthchecks during dev time so avoid this.

> And forget about trying to debug something that happens on application boot

This is the trickiest definitely. I've had luck by pausing the debugger on attach (on go and node you can do this), but it's not the most optimal.

Re: Instant dev environments for cloud-native apps

#50

Post by Ramiro »

davedx wrote: post #48
Ramiro wrote: post #41

Earlier quoted context omitted.

There are challenges on this model for sure. A big advantage is that, by routing to the dev environments, you can have the dev interact directly with the webhook when they code, instead of having to wait for a shared environment to test integrations. This is pretty useful, specially if your application depends a lot on webhooks for it's main functioning. This is an area where I'm particularly interested in. We are co…

> you can have the dev interact directly with the webhook when they code But how? A webhook needs to call a single endpoint (with a dns/ip pair). How can you route incoming webhooks from a 3rd party vendor to every dev machine running the service locally? Weird people downvoted my previous comment on this, it's a genuine problem with this "DTAP on your machine" setup, isn't it?

There's a couple of approaches we've tried:

1. Register each dev env with the provider. Dev Envs can have predictable URLs (e.g in okteto cloud it's the name + namespace + domain), so you can directly register it. This works well with self-service webhooks like Github.

2. Have a proxy that routes to the right dev env. This works if there's a key you can use for the routing, like a user ID or the subscription.

3. Have a proxy that duplicates traffic and send it to all the dev envs.

I'm curious wow do you solve this on the DTAP env. Are you registering a single endpoint with the webhook? Then how does it reach the separate dev envs? (or do you have a single, shared dev env?)

Post reply on HN