Local vs Remote Clusters for Kubernetes Development

Kubernetes has revolutionized the world of software development, providing a scalable and efficient platform for deploying and managing containerized applications. As teams define their development environment, they have many choices to [make.](http://make.Th) The first is whether to develop their micro-services directly on top of a Kubernetes cluster, or find an alternative method for dev service deployment. This is a topic we covered in [a previous blog post](https://www.raftt.io/post/develop-right-on-top-of-your-kubernetes-cluster). If going in that direction, the next choice is what kind of clusters to use - and the biggest decision here is whether they should be local or remote. In this blog post, we'll explore the pros and cons of each approach and provide guidance on selecting the most suitable option for your Kubernetes development needs.

## Local Clusters for Development

Local clusters run on the developers machine, usually as single-node cluster. Tools such as [minikube](https://github.com/kubernetes/minikube), docker-desktop with built-in Kubernetes or [kind](https://kind.sigs.k8s.io/), make these clusters easy to bring up and manage. Using local clusters can be very convenient and even reliable but there are some major drawbacks as well. The next paragraphs list the advantages and limitations of local cluster development

### Advantages of Local Clusters

- Development network: Running everything on the same machine (even when on a local Kubernetes cluster), means working with the running services is both highly stable and very fast.

- Accessibility: Local clusters can be configured however the developer likes, and the developer can be `cluster-admin` without potentially causing any harm.

- No image upload: Depending on whether local image building is an integral part of the dev cycle, using local clusters means there is no need to upload the resulting image.

- Cost Efficiency: By utilizing local clusters, developers can avoid the need for additional cloud resources, reducing costs associated with hosting and maintenance.

### Limitations of Local Clusters

- Scalability: Local clusters may have resource limitations that make it challenging to handle large-scale deployments. As a result, large environments are slow to spawn, cumbersome to interact with, and may also slow down other processes running on the dev machine (IDEs, browsers, etc.)

- Laptop battery usage: Running a complex environment takes significant resources,  translating to faster battery drain. Kubernetes itself was not designed for optimal battery efficiency, so even when nothing is running - some CPU is wasted.

- Similarity with real-world : While local clusters can work for development, accurately simulating production behavior can be challenging. Factors like network topology, security policies, auxiliary cluster services and integration with cloud or external services may not or cannot be accurately replicated in a local setup.

- Latency accessing cloud resources: Since local clusters are local, they are susceptible to network issues between the local machine and any external resources - databases, S3 buckets, or out-of-env services. This can be even more significant if on a suboptimal network connection, such as when using tethering or personal hotspot, or while on public transport.

## Remote Clusters for Development

In contrast to local clusters, remote clusters are Kubernetes environments hosted in the cloud or on dedicated infrastructure. Remote clusters offer significant scalability, production-replication and collaboration advantages, but can create challenges around cluster access, cloud resource costs and latency during development. The following section covers these advantages and limitations in detail.

### Advantages of Remote Clusters

- Production-like environments: Remote clusters can closely mimic the actual production environment, allowing developers to test and validate their applications with high fidelity. This setup reduces the risk of unforeseen issues when applications are deployed to production.

- Scalability: Remote clusters are designed to handle larger workloads and can scale seamlessly based on demand. So even the largest environments can be deployed there without issue.

- Collaboration: Remote clusters enable teams to work together effortlessly. By accessing and working on the same cluster remotely, developers can collaborate effectively and maintain consistency across the development lifecycle.

- Access to external resources: Remote clusters (and the workloads running on them) can be integrated seamlessly into the cloud or on-prem infrastructure. This is notable at the network and permissions layers, but is relevant across the board.

### Limitations of Remote Clusters

- Accessibility: Accessing remote clusters presents challenges, particularly related to network connectivity and security policies. The cluster must be made accessible to wherever the developer is working from, and the developer must have the required permissions (RBAC policies) so they can use the cluster. Both of these are maintenance headaches and potential security issues, and so require constant attention.

- Cost: Using remote clusters, especially when relying on cloud-based services, entails additional costs, primarily due to the underlying compute resources. Steps can be taken to minimize this impact, but it could still be significant.

- Latency with development tools: As the remote cluster is, well, remote, there can be some latency when working with it. Depending on the type of work being done, this might be more or less significant.

## Choosing the Right Approach:

Selecting between local and remote clusters depends on several factors that impact the development process. Consider the following when making your decision:

- Project Scale: The size and complexity of your project play a significant role. For smaller projects or individual development, a local cluster might suffice. However, larger projects with complex architectures from the resources and scalability offered by remote clusters.

- External dependencies: If your project depends on external resources (databases, cloud services or auxiliary cluster resources), the development environment must be able to access them. If there is significant usage of these resources, or if the latency between the environment and these resources matters, it can be difficult to make a local cluster work.

- Cost: Remote clusters have an inherent usage cost that must be factored in to the decision making process. On the other hand, local clusters may require stronger dev machines. Both factors should be taken into account to make sure the eventual solution works well for developers and fits in the organization’s budget.

## Where Does Raftt Fit In?

Raftt allows developers to achieve their optimal efficiency, no matter whether you’ve chosen to use a remote or local Kubernetes cluster. Regardless of the type of cluster, working with Kubernetes means constantly building images, deploying them, and updating deployments - all just to see feedback from a simple code change. Effective feedback during the dev cycle is difficult, since debugging is nigh-on impossible, and introspection is limited (since containers are transient and die when things break).

Raftt eliminates these problems and adapts Kubernetes to make it truly suitable for development. Code syncing and hot reloading, and OOTB debugging mean developers get iterations that take only seconds, and rich feedback on the changes they make. Raftt can be deployed on any Kubernetes cluster, and is entirely agnostic to the environment definition framework (helm, Kustomize, simple YAMLs, or anything else), and to the orchestration mechanism (Argo, Flux, helm, something in-house, etc.). Try it out yourself [on our demo project](https://docs.raftt.io/basics/tutorials/connect_mode), or [on your own code](https://docs.raftt.io/basics/onboard_project). Drop us a line if you’ve got any feedback - [directly](https://www.raftt.io/contact) or via our [Slack community](https://join.slack.com/t/rafttcommunity/shared_invite/zt-196nlb5ra-rYPWEqQF~ETdgx9aqWANnw).