Developer Experience Matters:

Fast Feedback when Coding for K8s

Create a great developer experience with Telepresence, Local-to-Remote Development Environments for Kubernetes Teams

Resource Libraryright arrowDeveloper Experience Matters

A product's User Experience (UX) can make or break its adoption. If users have a hard time understanding and using your product, chances are they’ll find something that provides the same value but is easier to use. Many companies know this and have intentionally created and maintained a great user experience for their users. But what about developers building applications; what about the products and tools they use to get their jobs done?

As essential as it is to create a great experience for end users, companies need to equally create a great experience for the developers building these products - this is called Developer Experience (DX)!

Developer Experience covers the interactions, experiences, and workflow a developer utilizes from the moment they start writing code till the code changes get shipped as features or bug fixes to end-users. Typically, this experience consists of the “inner dev loop” and the “outer dev loop”. The inner dev loop is where the developer writes code and tests the impact of their code changes before pushing it to the version control system, while the outer dev loop is where everything else happens (i.e, code reviews, merge, automated testing, security verification, etc.) leading up to release.

Why does Developer Experience matter?

The goal of every development team is to build and ship features to their end users faster. To make this goal a reality, a fast, efficient, and sustainable developer experience must be implemented. Keep reading to find out why!

When a development team adopts cloud native technologies, their developer experience is significantly altered as they’ll now be expected to carry out extra steps in the inner dev loop. So, instead of coding and seeing the impact of their code changes immediately as they used to when working with monolithic environments, they’ll now have to manage external dependencies, build containers, and implement orchestration configuration (e.g., Kubernetes YAML) before they can see the impact of their code changes.

This may appear trivial at first glance, but each new step within the Container Inner Dev Loop adds to overall development time and reduces the number of iterations a developer can perform daily, thereby decreasing potential new features being released. And this isn’t beneficial to the developer, end-user, or company!

Kubernetes development teams should have a developer experience that lets them focus on the things that matter (coding, testing, iterating) instead of the things that don’t (waiting for the build/push/test cycle to be completed). This will make them more productive and increase the number of features, updates, and bug fixes shipped to production. It’s a win-win situation for the developers, end-users, and the company.

Local-to-Remote Development Environments for Kubernetes Teams

Creating and maintaining a Kubernetes development environment often relies on several external dependencies, such as additional internal services, databases, and authentication systems. Over the years, various approaches have been implemented to create a Kubernetes development environment that provides developers with everything they need to entirely focus on doing their work the best way possible, thereby giving them a great developer experience. Two of the most common approaches are “running everything locally” and “running everything remotely”, both of which have pros and cons.

Running everything locally allows you to still use your favorite IDE with features such as local debugging and breakpointing, hot-reloading, easy access to logs, etc. However, it can be challenging to manage since you’ll always need to keep your mocks and deployment config scripts up-to-date. It does have a fast feedback loop since everything runs locally, but you’ll always be limited to the capabilities of your development machine and will have to find another solution when your cloud native application becomes too big to run on your local development machine.

On the other hand, running everything remotely means you lose the capability to work with your favorite IDE and local tools, but it's easier to manage since all the external dependencies are readily available in the remote Kubernetes cluster. The feedback loop is super slow, as you’d have to wait for your app to be containerized, pushed to a registry, and deployed to the Kubernetes cluster before seeing the impact of your code changes or performing a code-deploy-test iteration.

What you really need is a local-to-remote development environment. This development environment bridges the gap between remote Kubernetes clusters and local development, thereby offering you the best of both worlds; the ability to use your local tools for debugging and the ability to access all the dependencies in the remote Kubernetes cluster. It supports speed, efficiency, productivity, and collaboration, which creates a great developer experience.

Telepresence is one of those tools that enables Kubernetes teams to adopt the local-to-remote development environment in their workflow.

What is Telepresence?

Telepresence is an open source CNCF tool that allows developers to code and test microservices locally against a remote Kubernetes cluster. It allows you to run code locally and forward requests to and from the remote Kubernetes cluster, bypassing the slower process of waiting for a container to be built, pushed to the registry, and deployed.

Telepresence works by deploying a two-way network proxy in a Pod running in a Kubernetes cluster. This Pod proxies connection and data from the Kubernetes environment (e.g., TCP connections, environment variables, volumes) to the local process. This proxy can intercept traffic meant for the remote service and reroute it to a local copy, which is ready for further (local) development.

Why Telepresence?

Accelerate the inner development loop

  • Make code changes to your service and see the results instantly without waiting for a container build, push to the registry, and deployment.
  • Use secure preview URLs to share your development environment with teammates and collaborate on fixes without wasting time reproducing bugs across everyone’s machine.
  • Query cluster resources and experiment rapidly with additional services in real time.

Extend your existing local development toolkit

Reduce development compute costs

  • Running an instance of the app for each developer is expensive. With Telepresence, you can consolidate multiple personal dev clusters into a single shared cluster.
  • You can run an isolated local dev environment, container just the services that are being coded on, not all of their dependencies.
  • Quick and easy local environment setup and maintenance.

Reduce change failure rate

  • High-fidelity development environment (“just like prod”)
  • Simplify integration testing in CI

Ambassador makes it very easy for us to manage endpoints across all our regions worldwide and is able to seamlessly adapt and work with every region’s 80 different endpoints, each with varying configuration requirements.

Nashon Steffen

Staff Infrastructure Development Engineer