2. Provide developers access to Kubernetes in the cloud

The alternative solution to develop with Kubernetes is to provide all developers in the team some kind of access to a cloud-based Kubernetes environment.

Again, there are two general approaches to do that: Providing an individual cluster for every developer or sharing a single cluster among a developer team.

2.1 Give every developer an own Kubernetes cluster

The obvious solution to give developers access to Kubernetes in the cloud is to simply give every developer an own Kubernetes cluster.

Advantages

The main advantage of this approach is that the developers are as well isolated from each other as they are with local development. They cannot interfere with each other and if something breaks, it is easy to find the cause.

Usually, the same cloud environment is used for development and production, e.g. the same private cloud or the same public cloud provider. For this, the development with this environment is very realistic compared to the production environment because cloud-specific configurations or features can also be used during development. As a result, tests executed in this environment are very reliable and software that runs in the development environment is very likely to also run in production. Another advantage of this approach is that the application may be very complex and may require a lot or specific computing resources, such as GPUs, because these resources can be provided in the cloud.

Disadvantages

However, this approach also has some disadvantages: At first, it is usually not possible to give every developer an own Kubernetes cluster in a private cloud, which makes this approach rather suitable for public clouds, where very different machine types and sizes are available. A bigger problem, however, is that many individual k8s clusters require a lot of maintenance. Similar to the problem with local Kubernetes solutions, the individual clusters can either be managed by the developers themselves, but then they need to have the necessary knowledge and cannot focus on their actual work of developing new software, or by admins who then will have a lot of work maintaining many clusters in parallel. This problem is also related to the question of how to provide access to the cluster to every developer. Here, every developer, for example, needs to install kubectl and needs an account for the public cloud provider.

Moreover, running many Kubernetes clusters and having many users with access to the cloud makes it very complicated to keep control and oversight over the whole system. Especially regarding the cost for computing resources, this can be a problem as there may easily emerge the tendency to allocate too many resources. For example, if developers have the choice to get more resources to run their applications or tests marginally faster, they may tend to take the extra resources even though this may be not financially reasonable. Additionally, sometimes a lot of resources are just needed for a short time. Then, it would be best to scale down afterward, but this downscaling is a task that can be easily forgotten. In general, running many separate Kubernetes clusters is not efficient from a resource perspective as the basic k8s functionality needs to run several times although this is actually not necessary.

Result

For this, giving every developer in a team an own Kubernetes cluster is an approach that is rather suited for small teams in which every developer has some Kubernetes experience already. However, as this solution is certainly not computing resource efficient and hardly feasible for larger teams, it is generally inferior to the alternative approach for developing in the cloud: Sharing a cluster.

Overview of Advantages, Disadvantages and Use Cases of One-Cluster-Per-Developer Approach

2.2 Share one cluster among your developers

It is also possible to just use one or very few Kubernetes clusters and share them with several developers in a team by giving each developer an own namespace in the cluster. (For simplicity, I will only write about “one cluster” in the following. However, it does not necessarily have to be exactly one cluster, but could also be a small, limited number of clusters.)

Advantages

Since the development is also cloud-based, this approach has the same advantages of realism and almost unlimited resources as the previously described one-cluster-per-developer approach. Additionally, it is also possible to use a private cloud as only one k8s cluster is needed for the whole development team.

Unlike the approach with multiple clusters, it is very resource efficient to run Kubernetes just once and share its basic functionality with the whole team. This is also the typical approach for production systems, i.e. you would not run individual Kubernetes clusters for each part of a larger application but rather have everything running in one or a few clusters. Since there is just one cluster, it is also much easier to keep oversight and to control the resource cost by simply setting limits in Kubernetes.

Disadvantages

However, this approach also has some limitations: The individual users of the cluster need to be isolated from each other to prevent complete anarchy. Without the proper setting for multi-tenancy, one user could use up all computing resources so that no other developer can use the cluster anymore. It would also be possible to break something in a way that affects other users, which makes it much harder to trace the source of an error.

With the shared cluster approach, every developer needs to get a namespace. This namespace has to be created by a cluster admin before it can be used by the developer (if not every developer is a cluster admin, which is not recommended). However, this can slow down the development process as the admin has to be contacted every time a new namespace is needed. In the worst case, when the admin is not available, the developers are not able to work at all.

Result

Overall, the approach of sharing one Kubernetes cluster for development with the whole team is a computing resource efficient and scalable way of developing with Kubernetes in the cloud. The problem of user isolation, however, needs to be properly solved for this approach. Fortunately, there is a solution that addresses exactly this challenge: With DevSpace Cloud, it is possible to transform any Kubernetes cluster into a cluster that supports multi-tenancy with automatic user isolation, resource limitations and on-demand provisioning of namespaces for developers. (For technical details and a comprehensive list of features, read this article)

Overview of Advantages, Disadvantages and Use Cases of Shared-Cluster Approach