
Instant dev environments for cloud-native apps - pchico83
https://okteto.com/blog/step-out-from-the-dark-ages-develop-the-cloud-native-way/
======
zomglings
"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.

~~~
zndr
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.

~~~
pchico83
We would love to talk more about the issues you have. If you want to schedule
a call just drop us an email.

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

------
nhoughto
“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
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?

~~~
nhoughto
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?

~~~
Ramiro
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).

~~~
nhoughto
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.

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

And Okteto Cloud ([https://okteto.com](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...)

------
pchico83
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

~~~
sytse
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.

~~~
pchico83
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.

~~~
sytse
Awesome. Please let me know if there is anything else we can do.

------
pezo1919
It reminds me a bit of the monolith -> microservice -> monolith dance. Now
monolith -> cloud-monolith -> monolith. :D Just kidding, but not just kidding.

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

~~~
pchico83
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...](https://www.openfaas.com/blog/painless-serverless-development/)

The idea is to have replicable and production-like dev environments, no matter
your deployment tool

~~~
astuyvenberg
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/](https://github.com/serverless-components/)

~~~
pchico83
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.

~~~
pchico83
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

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

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

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

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

~~~
Ramiro
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.

~~~
davedx
> 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?

~~~
Ramiro
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?)

------
NikolaeVarius
Step out of the dark ages by burning piles of cash to generate light.

~~~
pchico83
One of the advantages of using Kubernetes vs a remote VM, which is an approach
followed by companies like Stripe, Slack, Eriksson and much more... is that
Kubernetes is very efficient allocating resources. Idle dev environments don't
consume resources, they can be scaled to zero and restarted in a few seconds,
and the same infra is shared by your entire team

------
maxmcd
Are kubernetes namespaces this well isolated? I wasn't aware it was at the
point where you could put untrusted tenants next to each other in the same
cluster.

~~~
pchico83
You can achieve good isolation with a combination of RBAC, network policies,
OPA rules and runtimes like gvisor. We also monitor suspicious activity with
Falco. For deeper security, we offer Okteto Teams, which runs on a dedicated
cluster, and Okteto Enterprise, which runs on your own cluster.

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

~~~
pchico83
Would something like Okteto Enterprise fit your needs?
[https://okteto.com/docs/enterprise](https://okteto.com/docs/enterprise)

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

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

~~~
Ramiro
For debuggers, we wrote a few guides like this one:
[https://okteto.com/blog/how-to-develop-node-apps-in-
kubernet...](https://okteto.com/blog/how-to-develop-node-apps-in-kubernetes/).

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

~~~
xmodem
I didn't get around to checking out your product yet, but from your comment
and the guide you linked it doesn't sound like you've actually solved any of
these pain points in a meaningful way.

It would be REALLY COOL to have a one- (or even few-) click IDE integration to
attach-debugger-to-instance-deployed-in-Okteto. If you had that, I would
already be pitching your product to our head of engineering and asking our
head of security to expedite due diligence.

edit: put another way, the pain points you DO currently solve for are ones I
don't currently have, because I'm already mostly avoiding them by not running
my dev instances in Kubernetes unless I really need to.

