The developer experience is the workflow a developer uses to develop, test, deploy, and release software.
Typically this experience consists of both an inner dev loop and an outer dev loop. The inner dev loop is where the individual developer codes and tests, and pushing code to version control triggers the outer dev loop.
The outer dev loop consists of everything else that happens leading up to release. This includes code merge, automated code review, test execution, deployment, controlled (canary) release, and observation of results. The modern outer dev loop might include, for example, an automated CI/CD pipeline as part of a GitOps workflow and a progressive delivery strategy relying on automated canaries, i.e., to make the outer loop as fast, efficient and automated as possible.
Developers have lived comfortably in the inner dev loop for most of the history of app development, but now with the "shift left", in which developers assume more responsibility for how services behave "in the wild", the outer dev loop becomes a part of the new, cloud-native developer experience. The changing workflow accompanying this shift is one of the main challenges for developers adopting Kubernetes. Software development itself isn’t the challenge. Developers can continue to code using the languages and tools with which they are most productive and comfortable.
Engineers now must design and build distributed service-based applications and take on responsibility for the full development life cycle. This means understanding and managing external dependencies, building containers, and implementing orchestration configuration (e.g. Kubernetes YAML). This may appear trivial at first glance, but this adds development time to the equation.
Bridging the gap between remote Kubernetes clusters and local development helps to recover much of the speed that gets lost in cloud-native development and reduces time to feedback in the dev loop. A fast and continuous feedback loop is essential for productivity and speed.
A good way to meet the goals of faster feedback, possibilities for collaboration, and scale in a realistic production environment is the "single service local, all other remote" environment. Developing in a fully remote environment offers some benefits, but for developers, it offers the slowest possible feedback loop.
With local development in a remote environment, the developer retains considerable control while using tools like Telepresence, an open-source tool that lets developers code and test microservices locally against a remote Kubernetes cluster. Telepresence facilitates more efficient development workflows while relieving the need to worry about other service dependencies.
Telepresence is designed to let Kubernetes developers code as though their laptop is in their Kubernetes cluster, enabling the service to run locally and be proxied into the remote cluster. Telepresence runs code locally and forwards requests to and from the remote Kubernetes cluster, bypassing the much slower process of waiting for a container to build, pushing it to registry, and deploying to production.