Live data from Hacker News

Instant dev environments for cloud-native apps

okteto.com

11–20 of 51 posts

Re: Instant dev environments for cloud-native apps

#11
post #5

Don't you tell me I'm living in "the dark ages" mister, I'm fully serverless. It's you who's grasping for a world soon to be gone.

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

Re: Instant dev environments for cloud-native apps

#12
post #5

Don't you tell me I'm living in "the dark ages" mister, I'm fully serverless. It's you who's grasping for a world soon to be gone.

I just find it to be patronizing, and it made me not want to read further. We have developers using Emacs and Lisp, we have Python devs, we have people using browser IDEs all under the same roof. There are any number of capabilities in the former that are missing in the latter, not least of which is "more complete control", something none of these products offer me in a convincing way.

Sorry if you find it patronizing, I tried to describe the problem in a general way to make it interesting for the general reader, independently of how we solve the problem.

Okteto, in particular, does not impose any IDE. It works with online IDEs, vscode, vscode remote, IntelliJ, IntelliJ remote... it is one of our core values. What we move to the remote cluster is the development environment runtime.

Re: Instant dev environments for cloud-native apps

#13
post #5

Don't you tell me I'm living in "the dark ages" mister, I'm fully serverless. It's you who's grasping for a world soon to be gone.

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

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/

Re: Instant dev environments for cloud-native apps

#14

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

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

#15
post #2

Github codespaces is a step forward to eliminate local setup and have replicable dev environments running in containers. But for true cloud-native applications, you would need a kubernetes namespace to run other services, databases or access the kubernetes API. This blog post explains our vision of cloud-native development at www.okteto.com

For whatever it's worth, I think your service (A) looks great! and (B) looks a lot like Heroku in a lot of ways.

One thing Heroku learned was that people kind of abused their free service. It used to work like this: You could create a free web service, and with no activity, it would "go to sleep" after (I think) 18 minutes of inactivity. Then it would take about 30 seconds to start up... fine for personal projects.

The abuse cut in when people set up (say) a raspberry pi to sit on their home network, and ping the service every five minutes, so it never went idle.

So they initially set up some punishment-like thing where your app had to be idle for some percentage of the day.

Finally, they made a MUCH better fix in that they changed the way the free tier works. You get (roughly) 730 hours of uptime a month, use as you see fit -- you can have one app running constantly, two running half time, lots if you only hit them occasionally.

So I can see someone setting up a Fred Developer account, and then setting up their raspi to do some simple deploy step every five minutes, to change something inconsequential about the app.

Also, what would 100G of disk cost? 1T? Thanks!

Re: Instant dev environments for cloud-native apps

#16
post #2

Github codespaces is a step forward to eliminate local setup and have replicable dev environments running in containers. But for true cloud-native applications, you would need a kubernetes namespace to run other services, databases or access the kubernetes API. This blog post explains our vision of cloud-native development at www.okteto.com

For whatever it's worth, I think your service (A) looks great! and (B) looks a lot like Heroku in a lot of ways. One thing Heroku learned was that people kind of abused their free service. It used to work like this: You could create a free web service, and with no activity, it would "go to sleep" after (I think) 18 minutes of inactivity. Then it would take about 30 seconds to start up... fine for personal projects. T…

Thanks for your feedback. We changed our free tier a few weeks ago to avoid abuse, but we will probably improve over it in the following months. Our focus is on development, not on hosting production apps, so I hope we can do more drastically things than heroku.

Re: Instant dev environments for cloud-native apps

#17
post #7

...and then you remember that your app depends on half a dozen vendor webhooks...

why? we offer vanilla kubernetes namespaces. There are no hidden dependencies

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

Re: Instant dev environments for cloud-native apps

#18

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.

That's not entirely true anymore. Several third party services offer debugging experiences.

Are there issues running java using serverless? I've worked with a number of enterprises using lambda and java. Seems to be fine ¯\_(ツ)_/¯ YMMV

Re: Instant dev environments for cloud-native apps

#19
post #2

Github codespaces is a step forward to eliminate local setup and have replicable dev environments running in containers. But for true cloud-native applications, you would need a kubernetes namespace to run other services, databases or access the kubernetes API. This blog post explains our vision of cloud-native development at www.okteto.com

Great work! I agree that developing in a Kubernetes namespace makes a ton of sense. This is also the direction we want to take the GitLab Web IDE. Kubernetes is the interface to the cloud, both for development, testing, and production.

Re: Instant dev environments for cloud-native apps

#20
post #19
post #2

Github codespaces is a step forward to eliminate local setup and have replicable dev environments running in containers. But for true cloud-native applications, you would need a kubernetes namespace to run other services, databases or access the kubernetes API. This blog post explains our vision of cloud-native development at www.okteto.com

Great work! I agree that developing in a Kubernetes namespace makes a ton of sense. This is also the direction we want to take the GitLab Web IDE. Kubernetes is the interface to the cloud, both for development, testing, and production.

Yes, the possibilities with this are very exciting. We have already integrated Gitlab runners in our Application Catalog, and we are working on a UX to deploy a branch and put it on dev mode on a single command.
Post reply on HN