Difference between cloud IDEs and Okteto

What differentiates Okteto with other cloud IDE based solutions like GitPod, GitHub codespaces, Coder …

PS: There was some light thrown by Ramiro in the recent AMA on Development Environments on Devops toolkit AMA, but would request a detailed answer

1 Like

Cloud IDEs and Okteto are focused on giving teams a fantastic developer experience. However, they are focused on two very different problems.

Cloud IDEs (in this category I’m bundling together Gitpod, Coder, GitHub Code Spaces, JFrog Spaces, etc) are focused on giving teams a “developer environment” that includes your source code, a runtime (e.g. the JDK), dev-time tooling (e.g. a compiler, or your test runner) and a pre-configured IDE. You can think of this as the same things that you’d be running on your local machine, but on an ephemeral VM in the cloud, that you typically access via a browser.

Cloud IDEs are a fantastic solution for projects with a small number of services and a small footprint, or for those companies that want to prevent developers from having access to the source code on their local machine. However, a cloud IDE doesn’t “look like production”, since you will still be running all your infra in the development VM by hand (and running kubernetes on a Cloud IDE is no fun, trust me).

Okteto, on the other hand, is focused on helping you deploy cloud development environments that mirror production. Okteto helps you define, build and deploy production-like cloud development environments, and it gives you the tools so that you can interact with them the way you are used to: with your favorite IDE, and a really fast inner loop.

The main benefit of Okteto is that your cloud development environment looks like production, but you can still sync your code , hot reload processes, and debug at will. With this, you know that your code will work in production because you are developing using the same manifests, the same infra, and even the same configuration. And because they run in the cloud, they are fast!

The best part of this is that you don’t have to choose. Okteto works with any IDE, whether it is local or in the cloud. If this is something you are interested in, Arsh and Pauline (Head of Community at Gitpod) recently recorded a live stream on how to use Gitpod and Okteto together to create a very powerful and portable development experience. Check it out!

Thanks @ramiro for the insights; what are the implications when:

  • workspaces grow larger (sync slowing down)
  • generated files causing redundant sync (is there a way to control - say I dont want to sync a sub-dir)
  • ingress/networking related implications for the service that gets exposed

workspaces grow larger

The file synchronization is incremental, so the workspace size will not impact the sync most of the time. The only time where this might be a problem is with the first ever okteto up for that service, since it will have to populate the volumes.

If you have a very large workspace, we recommend that you add as many of the artifacts as possible during the build phase of your container, so that you minimize the files that need to be synchronized.

generated files causing redundant sync

Yes, you can tell okteto which files to sync or not to sync by creating a file called .stignore at the root of your repository. This file has information on the format, and some examples to help you get started.

@ashoka007 not sure what you mean by this. Would you mind expanding on the question?

I meant the predefined url that we get at the end of okteto up (especially for okteto-cloud)