Productive Dev

From Local Dev to Remote Deployment: Avoiding Cloud Complexity

Before Kubernetes

Before cloud native architecture became the dominant approach to designing, deploying, and releasing software the local development story was much simpler.

Typically a developer would install the language runtime on their machine, download the application source code, and build and run the (often monolithic) application locally via their favourite IDE.

After Kubernetes

As applications and the underlying frameworks increased in complexity, the start time of an app in development increased. This often resulted in a slow coding feedback loop. This led to many web frameworks, IDEs, or custom tools enabling “hot reloading”. This capability allows code changes to be quickly visible (and testable) via the locally running application, without the need for a redeployment or restart.

With the rise in popularity of containers and Kubernetes has introduced more layers into a typical tech stack. There are clear advantages in relation to this, such as isolation and fault tolerance, but this has also meant that the local development setup has increased in complexity.

Traditional
Cloud Native
Number of Services1 (or a small number)Many
Local Infra RequiredPotentially a VM (controlled via Vagrant etc.)Docker, Kubernetes, VM
Rebuild and Deploy viaIDECompile, Docker build, kubectl apply etc.
Hot ReloadIncluded in app frameworkNot available out of the box
Integration TestingExternal services via mocks, sandboxes, etc.Internal and external services via mocks
Connecting to Remote Test EnvironmentSSHkubectl --context, kubectl -n
Traditional
Cloud Native
Number of Services
1 (or a small number)Many
Local Infra Required
Potentially a VM (controlled via Vagrant etc.)Docker, Kubernetes, VM
Rebuild and Deploy via
IDECompile, Docker build, kubectl apply etc.
Hot Reload
Included in app frameworkNot available out of the box
Integration Testing
External services via mocks, sandboxes, etc.Internal and external services via mocks
Connecting to Remote Test Environment
SSHkubectl --context, kubectl -n

Supercharging Your Local Kubernetes Development Environment

Being able to effectively configure a local development environment for services deployed in Kubernetes is not dependent on a single tool or technique. A combination of approaches is required:

  • Container Build Tools
  • Hot Reload
  • K8s-Aware Command Line
  • Kubernetes Dashboard
  • Collaborative Remote Testing
Wheel
More

Related Resources

Frequently Asked Questions

FAQ
  • Do I need to use a new IDE when developing applications for Kubernetes?
  • What’s the difference between developing applications for Docker and developing applications for Kubernetes?
  • What’s the best practice for testing Kubernetes-based applications locally?
  • How can I develop and test my application when I can’t run all of my applications in a local Kubernetes cluster (minikube, k3s, kind etc)?
FAQ