Ramiro's comments

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

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

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.

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?

> Even npm watch takes several seconds, let alone docker builds almost always take minutes

That's where caching, container layers and build stages can help a lot. Specially for development, where you might be rebuilding the same container over and over.

> How do you build containers safely in a multi tenant setup?

We have a fork of buildkit where we are implementing multitenant protections, authentication, etc ...

Hey, I'm Ramiro, one of the maintainers. We do several things to speed the whole cycle up.

When you are using Okteto Cloud to run your apps, you get all this:

- Build is run in big servers in the Okteto Cloud infra. It's based on buildkit, and it's heavily cached and optimized towards development scenarios. The build context is sent from your local machine to the service and everything else happens there. - The registry in the same infrastructure as the build services. The image is pushed from the build service to the registry, instead of from your machine. - The deployment runs in the same cluster as well, to speed up the time it takes to pull the image.

You can also use "okteto push" with your own infra, by providing your own buildkit service, registry and k8s cluster. Depending on where they are located with respect to each other this might be slower or faster (e.g using dockerhub for registry will be slower than using a dedicated one in your own cluster, mainly due to network speed and proximity).

The biggest benefits of this approach are being able to move all this to the k8s cluster, where you can leverage more compute power and faster network transmission. That way you are not pulling and pushing images across the internet.

I'm one of the creators of Okteto, thanks for the shout out!

We recently wrote a post on how to integrate Okteto with NodeJS apps, in case anybody wants to try it out: https://okteto.com/blog/how-to-develop-node-apps-in-kubernet...

We started building Okteto last year because we found that the existing tools were focused on speeding up the kubernetes cycle, and not on the end to end flow. Our goal with Okteto and Okteto Cloud is for most developers to be able to work on Kubernetes-based applications without even realizing they are on Kubernetes.

Skaffold's focus in on automating the build, push, apply part of the development cycle. Okteto's focus is on moving development to a Kubernetes cluster, abstracting away Kubernetes and the container from your inner developing loop. (I'm one of the creators of Okteto).

Our goal with Okteto is create a experience focused 100% on the needs of developers building cloud native applications. Would love the feedback of the community on our new feature.

I don't think you should. But some organizations have legacy needs and might be using other orchestrators. Or K8s might not be a good fit for them for whatever reason.

Yeah, you can use other container orchestrators and still build cloud native apps. Although in practice, almost everyone uses Kubernetes.

We're conducting a survey with the community to learn more about how you build Cloud Native applications, what you enjoy about it and the challenges that you're facing. We'll be sharing the results publicly once the survey closes.

$25 million sounds pretty low. Guess they just bought the existing stock scooters and the SF permit? It would extremely funny if the city didn't allow for the permit to be transferred :P

This is great news! I do hope they had kept the Open Tracing name though, instead of introducing a 3rd name to the mix.

> The reviewer should download the branch to their local environment, follow the deploy instructions (if present) and make sure the code “does what it says on the tin”

This looks like a very onerous requirement for reviewers (although tools like gitlab or getdockup.com automate it), I wonder if a) is really useful in catching issues, b) the process they used to convince the team to spend this extra time when reviewing. In my experience is that devs don't really want to spend more than a few minutes skimming through a PR.

I tried it on my mac with the docker-compose from master and works pretty well.