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 code is pushed to production

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.Ambassador Cloud + Your Local Tools for Kubernetes

Get Infinite-Scale Development Environments with Ambassador Cloud & Telepresence

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 run and develop any service—no matter its size—on your local machine.

This demo shows a Java microservice running in Kubernetes. Thanks to the power of Telepresence, the developer can make changes to their services without having to run all of the dependencies on their local machines. Even better, they can 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 or join our Slack channel to share your story.

Learn More