Should every developer get a Kubernetes cluster, or should one Kubernetes cluster be shared among the developers?
Shared Kubernetes cluster
Many developers share one cluster and its resources in the shared cluster.
In theory, it would be possible to give everyone full, direct cluster access, but this would quickly end in chaos. Such access would make the cluster very vulnerable to small mistakes.
For example, someone could consume all available computing resources or change the cluster configuration, so it crashes. Especially in an Agile environment, it is hard to share one shared Kubernetes cluster among many developers using a lower development environment or an experimental prototype environment that requires frequent environment changes.
Using shared clusters to give developers access to Kubernetes makes it hard to isolate the individual developers to prevent chaos in the cluster. Even when using Kubernetes namespaces, the developers do not have the freedom they have with an individual Kubernetes cluster.
Individual clusters for every developer
Each developer will have an individual, dedicated Kubernetes cluster. They are allowed to create clusters themselves, or the cloud administrator can create the clusters and then gives the developers access to an individual one.
Excellent isolation: Developers can work independently without worrying about breaking the development environment for the entire team.
Full cluster access: Individual clusters for every developer make granting full cluster access easy, allowing developers to experiment with the Kubernetes cluster and the configuration settings without worrying about impacting other team members.
Easy start: Setup a cloud account for each team member with appropriate permissions or have the cloud manager create and distribute the clusters.
Kubernetes knowledge and tools: Requires some knowledge of Kubernetes and tools such as kubectl before a developer can create and configure a cluster.
Maintenance effort: Ongoing cluster maintenance is required
Limited oversight and central control: Individual clusters for each team member require more oversight to manage the entire cloud development system properly.
Computing cost: Individual clusters used for development can increase cloud costs since they create redundancy for basic Kubernetes elements such as API servers which is especially true in public cloud environments.
snapblocs allows developers to quickly launch a cloud infrastructure or entire test/dev environment realizing the advantages of an individual cluster for each developer as described above. Self-Service Infrastructure allows developers to quickly provision infrastructures without being blocked by IT teams typically required to build infrastructures.
snapblocs solves the disadvantages of individual clusters
snapblocs enables IT administrators to set role-based permissions for stack provisioners limiting authority for operating the data platform infrastructure. Also, IT administrators can monitor and manage the usage of infrastructures with the snapblocs UI role-based permissions. It enables visibility into administration through various log collection and monitoring/Observability features. snapblocs gives IT better control and predictability while empowering stack provisioners with capabilities to create stacks built with pre-built Architecture Blueprints resulting in a Self-Service Infrastructure.
During off-hours or weekends, to reduce computing costs, developers can pause the cluster using snapblocs when not actively using/testing it and resume the paused cluster to use it again. This level of control over the cluster results in accelerated testing and development efforts while reducing IT management and development costs.