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.
The idea is to have replicable and production-like dev environments, no matter your deployment tool
11–20 of 51 posts
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.
The idea is to have replicable and production-like dev environments, no matter your deployment tool
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.
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.
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
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/
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/
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
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!
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…
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.
Are there issues running java using serverless? I've worked with a number of enterprises using lambda and java. Seems to be fine ¯\_(ツ)_/¯ YMMV
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
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.