Ambassador Logo

Eliminating Local Resource Constraints for Building Cloud Native Applications

A guide to setting up shared development environments for teams on Kubernetes.

Is Minikube melting your laptop? Are your local integration tests suffering because you can’t run dependencies on your development machine?

As organizations adopt Kubernetes and cloud native architectures, development teams will often run into resource constraints as their architectures get more complex. Additionally, Kubernetes presents new challenges for configuring local development environments in comparison with legacy monolithic applications.

With external dependencies and complex testing infrastructures, application developers are forced to either make sacrifices on realistic testing or wait long periods of time to get their local environments configured properly.

Setting up development environments for Kubernetes

The processes for developing traditional monolithic web applications has been improved and optimized and improved over many years. However, microservices and cloud native architectures still present challenges for developers looking to configure realistic development environments efficiently.

Some common challenges for developers working on Kubernetes applications include:

  • Frontend developers can't run Kubernetes on their typically resource-limited development machines. Oftentimes, they will have to buy a more powerful laptop or SSH to a remote server that can run the tools they need
  • Frontend developers can't run the entire backend stack on their laptops because it’s overly resource intensive. Instead they have to rely on accessing/consuming backend services that are running in a shared remote (staging) environment. This creates challenges with contention on the remote environment (sharing environments can increase latency on service calls etc), challenges with managing state (e.g. two or more developers mutating the same data store), and the environment being out of sync with production (or out of sync with assumptions/expectations)
  • Backend developers can't run all of the dependencies locally that are required for integration testing. Instead, they often create mocks/stubs/virtualised services that codify (potentially incorrect) assumptions about the real systems
  • Backend developers have to selectively spin up and spin down local dependencies that can't be run at the same time (due to resource issues) in order to integration test the system piece by piece. It’s impossible to test the entire system running locally, and the piece by piece tests may hide a bigger integration problem that will only be found once

Solutions to Address Local Resource Constraints

Buy More Powerful Hardware

When resources are the limitation, there’s always the option to buy more powerful hardware. This can get expensive, however, especially when considering upgrading the resources of an entire team. You’ll also have to account for the time lost as developers get used to new machines. As your organization grows your systems will continue to become more complex, and it’s easy to find yourself in need of more powerful hardware yet again.

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.