Pricing
Contact Us
Back to blog
TELEPRESENCE

Configuring Production-Like Development Environments for Kubernetes

September 20, 2022 | 5 min read

Microservices and cloud native architectures.

When organizations move to microservices and cloud native architectures their infrastructure requirements become more complex, and also more important to individual application developers. With a monolithic application, infrastructure concerns were managed by the operations team and kept largely hidden away from development teams.

With Kubernetes and the large amount of external dependencies involved with microservices, application developers are exposed to many more parts of their application than they had been previously. As a result, it’s easy for application developers to end up spending more time fighting with configuration (think lots of Kubernetes YAML) in order to make sure their development environments and tests are realistic.

This means less time writing and shipping features, so how do you make sure your developers are truly productive in Kubernetes?

Kubernetes Infrastructure

Kubernetes changes many aspects of an organization. Suddenly, in order for developers to commit their code into version control they encounter many more external dependencies they never encountered with a monolith.

Consider the following scenarios:

  • A developer can't easily recreate (or continually update) the remote Kubernetes platform configuration that is run in the production/Q&A/staging environment.
  • A backend developer needs to deploy multiple data stores/message brokers/middleware in order to verify and run integration tests on the service they are building locally. It is not possible to install and configure all of these locally in a production-like manner.
  • A backend developer needs to connect to a data store that contains a large amount of data in order to run integration tests. They cannot run the data store with this amount of data locally.

The more time the developer spends trying to solve these problems independently or waiting for the operations teams to help them solve them, the less time they spend adding new features to their applications/services and suddenly the benefits of Kubernetes are lost altogether.

Solutions

Enable Developers to Add their Development Machine as a Full Node into the Remote Kubernetes Cluster

A potentially simple solution for developers looking to integrate local and remote resources is to add their development machine as a node in the cluster. Depending on the underlying networking configuration, this can be a quick way to easily develop a service locally with access to remote cluster dependencies.

The simplicity of this solution is greatly dependent on the remote cluster configuration. Many cloud vendors or mature on-premise infrastructure operators will view the ability to extend a cluster to a local machine as increasing the threat model inappropriately.

Migrate to Developing Code Remotely with a Cloud-Based IDE

There are an increasing number of open source and commercial cloud-based IDE products that can be used to effectively negate any local development machine resource constraints. The underlying hardware powering the cloud IDE can be scaled vertically, and the integrated cluster networking allows easy horizontal scaling.

This challenges with this approach often relate to customizability, with limited access to the underlying OS and hardware, and also to cost, which is recurring and correlated with the size of the development team.

Develop Like Your Laptop is in Your Kubernetes Cluster

Telepresence focuses on improving the developer workflow for single Kubernetes developers. Telepresence uses a smart proxy to create a copy of your service running in the cloud and intercepts it to your local machine. With this model, you can develop and test any service on your local machine against the dependencies running in the cloud.This demo shows a Java microservice running in Kubernetes. Thanks to the power of Telepresence, the developer can make changes to their local services and see the changes immediately!

Ambassador Cloud is powered by Telepresence, an OSS tool focused on improving the developer workflow for single Kubernetes developers. Telepresence uses a smart proxy to create a copy of your service running in the cloud and intercepts it to your local machine. With this model, you can develop and test any service on your local machine against the dependencies running in the cloud.

This demo shows a Java microservice running in Kubernetes. Thanks to the power of Telepresence, the developer can make changes to their local services and see the changes immediately!

Telepresence is available as part of Ambassador Cloud today.

Get Started

If this is a problem you’ve faced while adopting cloud native technologies, we’d love to hear about your story and how you’ve addressed it. Please drop us a line at @ambassadorlabs on Twitter

Learn More