Ambassador Logo

Configuring Production-Like Development Environments for Kubernetes

Don’t waste time configuring infrastructure when you should be writing business logic.

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?

Infrastructure is a Development Concern with Kubernetes

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.

Adopt New Technologies

Improving developer experience has been an often-discussed topic in the cloud native space. There are several popular tools that have gained traction for reducing friction in a developer’s code, test, deploy loop:.

  • Skaffold is a workflow tool that helps developers automatically build, push, and deploy their application to a Kubernetes environment.
  • Telepresence is an OSS tool that enables developers to “intercept” their cloud service and run it locally on their laptop to code in a more traditional local development environment.
  • Tilt gives you smart rebuilds, continuous feedback, live updates, snapshots, and more for local development in Kubernetes.
  • Garden is an automation platform for cloud native applications that enables developers to use the same workflows and production-like Kubernetes environments at every step of the process.

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 or join our Slack channel to share your story.