Good Developer Experience Starts with Good User Experience

A product’s user experience (UX) can make or break its adoption. If users have a hard time understanding and using your product, they will likely find something that provides the same value but is easier to use. But what is one key element contributing to good user experience? Often overlooked or underestimated, developer experience (DX) matters in creating good user experience and product adoption.

The developers who build and maintain applications are asked to put users first, but in some cases, developers are the first users. And to develop products for end users, the developer experience depends on the development environment and the processes, products, and tools that make up that experience.

What is Developer Experience?

Developer experience covers the interactions, experiences, and workflow a developer uses from the moment they start writing code until 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 version control, while the outer dev loop is where everything else happens (i.e., code reviews, merges, 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.

When a development team adopts cloud native technologies, their developer experience is significantly changed, 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’s inner dev loop adds to overall development time and reduces the number of iterations a developer can perform daily, 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 those 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.

Bridge the Gap Between Local and 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, offering you the best of both worlds. Devs get the ability to use 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 the 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

• Keep your existing local development, build, and debugging workflows
• Maximize your productivity with your favorite tools: work with any IDE, debugger, or other tools that run locally.
• Hot reload works again.
• No need to maintain remote environment configurations

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