vCluster: How Is It Used and a Comparison to NKE

What Is vCluster?

A virtual cluster is a fully working Kubernetes cluster that runs on top of another Kubernetes cluster. It is focused solely on core components, comprising the API server, controller manager and a flexible storage backend. By default, vCluster utilises Embedded SQLite for storage, thereby ensuring simplicity and efficiency. However, users have the freedom to opt for alternative options such as PostgreSQL, MySQL, MariaDB or etcd, depending on their specific requirements. Additionally, vCluster offers the flexibility of including a Scheduler.

While it defaults to utilising k3s as the virtual Kubernetes cluster, it remains agnostic to specific distributions. This means that vCluster is compatible with other certified Kubernetes ‘flavours’ such as Vanilla k8s or k0s. This flexibility allows users to choose the distribution that best suits their needs, without sacrificing the simplicity and efficiency provided by the vCluster’s minimalist architecture.

By default, a vCluster operates as a single pod, housing two essential containers: the Control Plane and Syncer. The Control Plane orchestrates the core Kubernetes components. The Syncer synchronises data between the vCluster and the host cluster. Running on top of another Kubernetes cluster, known as the host cluster, the vCluster leverages the underlying infrastructure while providing a distinct and isolated environment for containerised workloads. It is simply deployed as a regular StatefulSet within a designated Namespace in the host cluster. Notably, everything created within a vCluster resides either within the vCluster itself or within the host Namespace, facilitating clear delineation of boundaries.

Minimalistic Architecture

Synced Resources

When Pods are initiated within the virtual cluster, they undergo a transformation before being launched within the virtual cluster’s designated Namespace in the host cluster. This process involves rewriting the Pod specifications to align with the host cluster’s Namespace conventions, resulting in longer Pod names. For example, the Pod nginx-76d6c9b8c-57xk5 created in the Namespace nginx within the vCluster my-vcluster, becomes nginx-76d6c9b8c-57xk5-x-nginx-x-my-vcluster in the host cluster. Similarly, Services and Endpoints associated with the virtual cluster are adapted and deployed within the corresponding Namespace in the host cluster.

Furthermore, the coordination between virtual and host clusters extends to sharing service cluster IPs. This shared infrastructure simplifies networking configurations and enhances interoperability.

As vCluster’s Syncer diligently synchronises Pods with the host cluster for scheduling, users can seamlessly utilise the host cluster’s storage classes to create PVCs and mount PersistentVolumes. By default, vCluster enables access to the host’s storage classes without the need for duplication within the vCluster environment, thus improving storage management and enhancing flexibility.

Certain resources undergo synchronisation, while others remain confined to the virtual cluster. ConfigMaps and Secrets, when mounted to Pods, seamlessly traverse to the host cluster. However, all other Configmaps or Secrets will purely stay in the virtual cluster to ensure isolation and encapsulation. Notably, Deployments, StatefulSets, Custom Resource Definitions (CRDs), ServiceAccounts and similar resources do not undergo synchronisation and maintain autonomy. This selective synchronisation strategy ensures efficient resource utilisation, while keeping the virtual and host clusters separate. The full list of resources that can be synced or mirrored by vCluster (currently) can be found in the documentation.

vCluster Design Principles

At the heart of vCluster’s architecture lies a set of carefully crafted design principles, each aimed at delivering an efficient Kubernetes experience. First and foremost, vCluster prides itself on being as lightweight as possible. This is achieved by encapsulating the entire vCluster within a single Pod and leveraging k3s as the control plane. This minimalist approach ensures that using vCluster imposes minimal overhead on the underlying infrastructure while maximizing resource utilisation.

Whether within a vCluster or nested vClusters, workloads operate with the same computing power, and offer the same access to persistent storage and network performance as those running directly on the host cluster.

Moreover, vCluster reduces the load on the host cluster’s Kubernetes API server by keeping high-level resources confined within the vCluster. By employing a separate API server and data store dedicated to the vCluster, and synchronising only essential low-level resources with the underlying cluster, a vCluster minimises API server requests, thus optimising performance and scalability.

Finally, vCluster prioritises flexible provisioning and cleanup processes, offering a variety of deployment options such as vCluster CLI, Helm or kubectl (see Deploy vCluster for more info). By adopting a simple StatefulSet + Service deployment model, vCluster integrates seamlessly with existing Kubernetes tools, simplifying all processes for users in a variety of environments.

Interesting Facts

vCluster presents some intriguing capabilities that set it apart from traditional cluster management solutions. One notable feature is the ability to run a vCluster inside another vCluster, a practice known as vCluster nesting. This allows for the creation of hierarchical Kubernetes environments, offering unprecedented flexibility and scalability. With vCluster nesting, users can deploy and manage multiple layers of Kubernetes clusters within a single infrastructure, facilitating complex deployment scenarios and enabling innovative use cases. I recommend starting your exploration of this topic by reading the article Running Nested clusters in Kubernetes using vCluster.

Another interesting detail is how vCluster lists resources: at the moment, it sorts them by age. Why? k3s uses Kine (etcdshim that translates etcd API to, e.g. SQLite). Kine [is] not sorting the keys in the same way as etcd, but I don’t think that’s guaranteed anywhere (see GitHub thread Results of kubectl commands not sorted). This is true for now, but some work on delivering The Implicit Kubernetes-ETCD Contract is ongoing (more info: On the Hunt for Etcd Data Inconsistencies – Marek Siarkowicz, Google) and perhaps in the future we will see some cool changes in this area. Nevertheless, for now, the proposal for displaying resources is as follows: objects listed in response must be in lexical order by their name. And in my opinion, it would be worth following this rule starting… now. 😉


When navigating a vCluster environment, a few tips can optimise performance. Firstly, there is the option of using a separate vCluster Scheduler. While this feature is available, it’s advisable to disable it, especially if you rely on autoscaling. Although there are trade-offs involved, maintaining autoscaling functionality typically outweighs the benefits of a separate Scheduler. For more insights, refer to the documentation on Virtual Schedulers.

Furthermore, certain vCluster resources may be shared with your ‘normal’ infrastructure, emphasising the need for strict access controls and security measures. It is crucial to ensure that sensitive data or resources are inaccessible from within the vCluster environment, mitigating the risk of unauthorised access or data breaches.


vCluster grants users full administrative access, empowering them to deploy Custom Resource Definitions (CRDs) or create Namespaces. This level of control facilitates custom configurations and tuning to accommodate a variety of deployment scenarios.

Moreover, due to lightweight virtual clusters, which share the resources of the underlying host cluster, vCluster can save considerable costs.

Comparing vCluster with alternatives such as KinD, K3d, and Minikube reveals its superiority in terms of speed and efficiency, particularly in local development environments. This is explored further in the article How Virtual Kubernetes Clusters Can Speed Up Your Local Development, highlighting vCluster’s potential to accelerate development cycles and streamline Kubernetes workflows. Overall, vCluster offers a comprehensive solution for Kubernetes orchestration, combining performance, efficiency and security to meet the diverse needs of modern deployment environments.

Use Cases

vCluster presents a versatile solution with a wide range of use cases.

One prominent use case is their application in development environments, both for local and remote scenarios. By providing lightweight and isolated clusters, vCluster facilitates rapid iteration and experimentation, empowering developers to build and test applications with ease.

Moreover, vCluster excels in end-to-end testing (E2E) scenarios, offering a good environment for validating application behaviour and functionality across various deployment configurations.

Additionally, vCluster prove invaluable in testing against multiple versions of Kubernetes, allowing users to assess compatibility and performance across different releases. This versatility enables businesses to future-proof their applications and infrastructure by ensuring compatibility with upcoming Kubernetes updates.

Furthermore, vClusters serve as an indispensable tool for training, workshops and demo clusters. Their lightweight nature and ease of provisioning make them an ideal platform for showcasing Kubernetes concepts and conducting hands-on training sessions.

vClusters address the challenges of multitenancy in Kubernetes environments, offering a great alternative to traditional namespace-based isolation. As highlighted in the article Why Namespaces aren’t Good Enough, vCluster provides robust isolation mechanisms that overcome the limitations of Namespaces, ensuring secure and efficient multitenant deployments.

Additionally, vClusters facilitate the isolation of certain resources that reside globally within the cluster, as discussed in Why use Virtual Kubernetes Clusters? This enables users to effectively manage and secure resources that cannot be isolated using traditional namespace-based approaches, thus enhancing the overall security of Kubernetes deployments.

vCluster vs NKE

vCluster offers an alternative to NKE-backed Kubernetes clusters, catering to different use cases, while also exhibiting some limitations. Utilising vCluster, Kubernetes clusters can be provided at a more affordable price point, though with some trade-offs regarding availability guarantees and managed add-ons. More details (and a detailed comparison) can be found in our documentation on Kubernetes Cluster backed by vcluster.

Where to start?

Feature image source:

What Does … an IT Service Desk Supporter Do at Nine?

No company can run efficiently without customer support. This is no different at Nine: every day, we receive numerous exciting inquiries that are answered by our Customer Service Desk, or prepared and handed on to our engineering team for clarification. Some of these inquiries are very time-critical and technically extremely demanding, but we always want to offer our customers the best possible service – and solution.

Read our interview with Sophie Kwass, one of our IT Service Desk Supporters, to find out how she masters her complex day-to-day work at Nine while expanding her technical skills on a daily basis.

Elena: Hello Sophie, thank you for taking a moment!
Sophie: I was forced to take part by HR. (smiles) 😆

Dear Sophie, how long have you been working for Nine, and why did you choose us as your employer?
I joined Nine in February 2023, so a bit more than a year ago. I had previously worked in a support role in a web hosting company, and therefore knew what motivated me: high-quality support for exciting technology products. It’s also important to me to be able to get involved and develop myself further – that’s practically in the team DNA in my current job. Nine was therefore a no-brainer and my employer of choice.

What do you prefer? Answering tickets in writing or helping customers over the phone?
The combination of the two is what makes it work for me, because I like variety. I usually handle any technological queries in the form of tickets. On the other hand, I often get an even more authentic impression of our customers on the phone – a call is much more personal and direct. ☎️

You are the «Tech Lead» in your team – can you briefly explain what that means?
Our team has completely reorganised itself in the past 12 months. We want to offer support that is competent, helps both our customers and our engineering teams, and is fun at the same time. To this end, I am developing new processes with my team and the engineers, organise knowledge sharing sessions and lead the sprints in which we organise our project work alongside our day-to-day business. 

What does a typical day in your team look like?
There’s no such thing as a typical day – but I’ll give it a try anyway: we start our work in a way that makes sure we are ready to answer the first calls by 9AM. We start with an initial triage of any tickets received and use all communication channels to gain first insights into the current situation. We then meet for a stand-up to plan the day, and also take part in the stand-ups of the engineering teams. We then join forces to tackle the tickets, and we occasionally receive calls.

And that was only the morning?
Yes, exactly. It’s usually quieter in the afternoon, so depending on the day, at least one person will look after the phone and the inbox. The other team members focus on projects to improve the quality of support, work on our documentation, or collaborate with the engineers to address more complex queries. We also meet several times a week for various training sessions on engineering topics. At 6PM, we go home or – thanks to flexible work-from-home options – turn off our laptops. 💻

What makes your team special?
We all like to learn from and with each other, prefer to help our customers as a team and puzzle over technical issues together, with a lot of curiosity. Then again, that’s what Nine as a company is all about for me – everyone shares their knowledge and their joy of learning. We want to progress together and achieve something. We don’t really have a ‘mission impossible’, because we always go the extra mile for our customers.

Thank you very much, Sophie, for the interesting interview.
You’re very welcome. 😉

Our Customer Service Desk currently consists of four staff members who are the first point of contact for any issues, questions or other queries. Our customers value this opportunity for personal contact, the fast response times and competent advice, as we are proud and grateful to see, hear and read in the consistently positive feedback.

Check back regularly to make sure you don’t miss the next behind-the-scenes insights about our team members!

The Choice Between Block, File and Object Storage

When talking to people about migrating their applications to Kubernetes, there are often questions about storage:

  • Will the data remain in Switzerland? (data locality)
  • Is the data encrypted at rest?
  • Is there any in-transit encryption?
  • Would it be possible to provide ‘insert big number here’ of storage space?

One thing that is often overlooked is how to access and store data in a multi-node Kubernetes cluster and which infrastructure will be needed for this. As we have several options, I’d like to shed some light on this topic and explain the differences.

Why Do We Have to Choose?

Often, applications are run directly on a single server (VM or bare metal), as the computing power of one machine is just enough for this use case. If there are other applications to run, they are also operated either on the same machine or on one other single instance. Storing data is easy as the application can just read and write to a local disk. This type of architecture most often emerges due to legacy and economic reasons, as there is no need for a load balancer or complicated cluster setup.
To consolidate all those applications in a Kubernetes cluster (to unify the deployment experience, provide more error tolerance, etc.), most of the applications should support one thing: running instances in a distributed manner with multiple replicas (on different nodes).

This is because in a Kubernetes cluster, nodes are very dynamic. A node can go down at any point in time (due to unexpected failure, maintenance, cluster-autoscaling, etc). For example, when we run cluster upgrades on our NKE clusters, we completely replace the nodes of every cluster instead of updating the software packages of the operating system on each instance. In case of a node failure, Kubernetes takes care of moving running applications to different servers in the cluster. However, this might take a few minutes, and having just one instance of the application running might result in short disruptions. These disruptions can add up in a maintenance window, as every node needs to be replaced. Running the application on more than one node in parallel solves this issue and is one of our recommended best practices.

There is one challenge though. If every application instance only stores data locally on the node where it runs, other instances won’t have access to that data as they are running on different machines. Often, web applications store user-uploaded data (PDFs, images, etc). This data then needs to be accessible by all application replicas. Besides our applications, which need to be ready to work in a distributed environment, we might therefore also need a storage system which can be accessed by distributed clients.

What Can We Choose from?

Based on the last paragraph, storage system access in Kubernetes can be divided into 2 types:

  • read-write-once (RWO)
  • read-write-many (RWX)

The difference is easy to explain. If a storage location can only be accessed by one ‘writer’ (an application which wants to write or delete data) on one node at one point in time, the access type is called read-write-once. It might be that other applications running on different nodes can have read-only access to the storage space, but this depends on the system in use.

If multiple writers (on different nodes) need to make changes to the data, we need a storage system which supports read-write-many access.

Image source: Canonical

Block Storage

Whenever a node accesses raw partitions or raw disks, we actually refer to block storage (as disk blocks are accessed directly). Usually we put a filesystem on top of the raw blocks and expose it to applications running on that one node (so block storage is a representative of the read-write-once access category).

You have a single replica application (for example a development Postgres database pod) which needs its own space for storage? Choose block storage.

There are 2 variants of this:

  • node local block storage (aka a disk attached to a specific node)
  • remote block storage which you can access via iSCSI, fibre channel, etc.

Remote block storage can often be attached to a different node in case of a failure or maintenance, so it provides machine fault tolerance. Persistent node local block storage however is bound to one specific node, but might make sense when having bare metal servers being part of the Kubernetes cluster and your application needs very fast access to the storage space. However, all applications using persistent node local storage are bound to that one server and in case of a failure, your application won’t be able to run. Maybe fault tolerance can be achieved in the application itself in such a case (the software itself communicates with other replicas and can self-heal in case of failures), but in general, we recommend using a fast remote block storage as it most often allows for more flexibility (also in terms of storage expansion). For example, all our NKE clusters are build up on virtual machines and support a fast remote block storage by default, but no persistent local node storage.

There are also ephemeral node local storage solutions like Kubernetes emptyDir or Googles local SSD feature for GKE clusters which can be used as scratch space or temporary storage.

Typically, you pay for the amount of block storage which you requested and not for how much you have already used of it.

File Storage

In contrast to block storage, file storage (as the name implies) allows you to share files with multiple distributed clients by exposing a shared file system. Applications running on Kubernetes can access those files as if they were local files. As almost every programming language allows access to files, using file storage is most often the first choice when needing read-write-many access. Solutions like NFS, CIFS, CephFS or GlusterFS implement file storage access.

Files are structured in a directory tree which can be quite deeply nested. Every file has a payload (the real data of the file), but additionally needs metadata to be stored (access permissions, file type, etc). As multiple distributed clients can access the filesystem in parallel, there need to be locking mechanisms additionally in place which guarantee a consistent view of every client. This is handled differently by the various implementations (and also changed over time in NFS implementations, for example). Without going too deeply into the technical details, file storage systems most often provide a lower performance compared to block storage, but they also provide the possibility of read-write-many access which may be a requirement when using Kubernetes. Additionally, not all file storage implementations provide full POSIX compatibility.

From the perspective of an infrastructure provider, it is not so easy to provide and operate dynamically provisioned file storage in a Kubernetes environment. We used to manage some in-cluster NFS instances ourselves, but we ran into issues during maintenance times, when all nodes are being replaced. Clients sometimes stalled and pods didn’t get started. Additionally, NFS and CIFS are long-standing solutions which might not fit into today’s dynamic environments.

For example, NFSv3 authenticates clients based on IP addresses which are mostly ephemeral in a Kubernetes cluster. NFSv4 can securely authenticate clients, but a Kerberos infrastructure is needed for this. CIFS supports some nice features, but also ships Windows-specific things like printer sharing which is not really needed in a Kubernetes environment. Additionally, there are currently 2 NFS related kubernetes-sigs projects, but none for CIFS. CephFS is really promising in terms of features and scalability, but it also is complex to operate (although rook improved the situation). We also used early versions of GlusterFS when still operating Openshift clusters some years ago, but we faced quite a few consistency and availability problems back then.

Providing automatic backups and restore possibilities for file storage solutions in a Kubernetes environment can be a further challenge.

Overall, file storage solutions come with a higher price tag, as operating them in an automated way might need a substantial engineering effort. We provide read-write-many storage space in our NKE clusters which is backed by a NFS solution from our compute infrastructure provider.

Object Storage

Besides the aforementioned file storage solutions, object storage has got more and more popular as it also allows read-write-many access. Instead of files, data is put into objects which have a unique ID in a flat namespace (bucket). Each object also has metadata attached (which allows for searching).

Accessing objects works via HTTP based protocols, with Amazon’s S3 being the most popular one (as they invented it). This kind of access makes it very different from file-storage-based solutions. There is no shared filesystem mounted and passed into the container anymore. The underlying operating system or the cluster orchestrator is not involved for data access. Instead, the application itself accesses the object storage system via libraries. This allows for great flexibility, but might also imply changes to the source code of the application. These code changes also what block some applications from using object storage. It would just be too much work to implement it.

However, once the application can make use of object storage solutions, there are some great features to benefit from. Here are some examples:

  • pay-what-you-use model: only the space which you use gets charged (plus fees for API calls and/or bandwidth)
  • virtually endless space to use (no pre-provisioning of space needed)
  • various policy settings allow control over access permissions for buckets and the objects within them on a per user (e.g. ‘access key’) basis
  • write-once-read-many buckets (WORM): data which was written once, can not be deleted/overwritten anymore. Policies can make sure that data gets deleted automatically after a certain amount of time.
  • access data from anywhere: buckets and objects can normally be accessed from all over the world, no matter where your application is running. A deployed file storage solution might not be accessible from outside your Kubernetes cluster.
  • usage of HTTPS provides encryption-in-transit
  • mostly provider independent: you can just switch to use a different provider, given the object storage protocol is the same (and you don’t make use of very provider specific features).

But there are also some drawbacks with object storage and its implementations. Objects can only be written as a whole. This means you can’t open an object to append to it (as you can do when using file storage). You would need to download the whole object, append your data in the application and upload all the data again. Accessing object storage is also often slower than file storage, so applications which need high-speed access to data might need to use some caching or fallback to a file storage solution. To speed up access to object storage systems, requests should be made in parallel where possible. There are also differences in the feature set (and quality) of object storage solutions which allow access via the same protocol.

For our customers we provide a S3 compatible object storage solution hosted in Swiss data centres.

So What Should I Use in The End?

If your application just consists of a single replica and only needs read-write-once access, fast remote block storage should be your choice. It allows for fail-over to a different node in case of a failure and provides good performance.

If you need read-write-many access, we favour the use of object storage over file storage (if your use case allows for it). Even if your application would need some changes to support object storage, it might be worth it in the long run. Using objects just allows for more flexibility and might also provide more features.

Featured image source: Intelligent CIO

vcluster: A virtual Kubernetes Cluster

As more developers get familiar with deploying to Kubernetes, the need for better isolation between tenants becomes more important. Is it enough to just have access to a namespace in a cluster? I would argue for most use-cases to deploy your production apps, yes.

As more developers get familiar with deploying to Kubernetes, the need for better isolation between tenants becomes more important. Is it enough to just have access to a namespace in a cluster? I would argue for most use-cases to deploy your production apps, yes. But if you want dynamic test environments or to schedule your GitLab builds on a certain set of nodes, it can quickly get quite complex to safely set this up on the same cluster as your production apps. Using a full seperate cluster for that is possible but it’s slow to setup and it’s usually quite expensive if you use a fully managed cluster.

The Kubernetes multi-tenancy SIG (Special Interest Group) has been prototyping a virtual cluster implementation for quite some time, but it has always stayed somewhat experimental and limited. The vcluster project attempts to address these shortcomings, implementing a similar architecture but with a rich set of features, even in the earliest implementation, and has really good documentation.

The basic concept of a vcluster is that it starts up a kube-apiserver inside a pod on the host cluster and then a syncer component will ensure that certain resources are synced between the vcluster and the host cluster so existing infrastructure and services on the host cluster can be reused. For example, if you request a storage volume (PVC) on the vcluster, it will be synced to the host cluster where the existing storage implementation will take care of creating the actual volume, without the need to install any complicated CSI drivers on your vcluster. You just get dynamic volume provisioning “for free”. This also applies to things like load balancers, ingresses etc. Your workloads (pods) created on the vcluster can also make use of existing nodes on the host cluster. But there is also the option to further isolate workloads by scheduling all workloads created inside the vcluster on dedicated nodes of the host cluster. This is also how vclusters are implemented at Nine, you don’t need to worry about sharing a node with other tenants

Source vcluster:

When to use a vcluster

That’s of course completely up to you but here are some use-cases we could think of:

  • CI/CD: Because of the fast creation and deletion times of a vcluster, as well as their low cost, they lend themselves to be used in CI/CD pipelines to test deployments of your apps end-to-end.
  • Testing new Kubernetes API versions: We try to always provide the latest Kubernetes releases within vcluster so you can test your apps against new API versions early.
  • Well isolated and cost effective environments: Staging and development environments can use their own vcluster to be better isolated from production instead of using multiple namespaces on a single NKE cluster.
  • Test new CRD versions and operators: Testing new CRDs and/or operators can easily be tested on a temporary vcluster. Want to try an upgrade of cert-manager and see if your certificates are still getting signed? A vcluster can help with that.

How we are making use of vclusters

At Nine we are constantly looking at new software to solve certain problems , which means we often need to deploy something on a Kubernetes cluster and tear it down again after we are done with testing. In the past we have been using local clusters with kind or Minikube but with a lot of software you have to resort to workarounds to get it running, e.g. find the usually hidden “allow insecure TLS” flag as it’s not really simple to get a trusted TLS certificate inside your temporary kind cluster. Or say you want to share your prototype with other team members, it gets quite tricky to expose your locally running applications to the internet. Here a vcluster offers the best of both worlds as you can get an (almost) full cluster within seconds.

Another use-case of ours is running the staging environment for our API and controllers. We make heavy use of CRDs, which makes it hard to use a shared cluster but as we are just running a few pods for the controllers a full cluster would also be wasteful.

Comparison to NKE

We see vclusters as a complimentary tool to our fully managed NKE clusters. The API server of a vcluster does not have the same reliability as a complete Kubernetes cluster such as NKE. However, a brief failure of the API server does not usually cause your application to fail. This comparison table should give an overview of most of the differences:

Service Type Load Balancer
Persistent Storage (RWO)
Argo CD Integration
NKE Maschinentypen
Dedizierte Worker Nodes
Dedizierte HA Control-Plane Nodes
Cluster Add-ons
Automatisches Backup
Verfügbarkeitsgarantie (SLA)
Schnelle Erstellungszeit (<~2 min)
Cluster Admin

Getting started

While vclusters can be created in Cockpit, we have also added it to our CLI utility to offer a kind-like experience and to support CI/CD workflows. You can create a new vcluster with just a single command.

$ nctl create vcluster
 ✓ created vcluster "grown-velocity"
 ✓ waiting for vcluster to be ready ⏳
 ✓ vcluster ready 🐧
 ✓ added grown-velocity/nine to kubeconfig 📋
 ✓ logged into cluster grown-velocity/nine 🚀
$ nctl get clusters
NAME                       NAMESPACE       PROVIDER    NUM_NODES
grown-velocity             nine            vcluster    1


By default this will choose a random name for your vcluster and spawn a single node that is dedicated to this vcluster. All of this can be configured using flags, use nctl create vcluster -h to get an overview over all available flags.

Now you can start to use the vcluster just like any Kubernetes cluster.

$ kubectl get ns
NAME              STATUS   AGE
kube-system       Active   47s
kube-public       Active   47s
kube-node-lease   Active   47s
default           Active   47s

$ nctl delete vcluster grown-velocity
do you really want to delete the vcluster "grown-velocity/nine"? [y|n]: y
 ✓ vcluster deletion started
 ✓ vcluster deleted 🗑

Do you have any questions?

Growing pains: how can digital agencies scale more effectively and efficiently?

Three growth challenges digital agencies face as they scale, and how to overcome them

Digital agencies have built their business on repeatable, replicable products and services for multiple customers with very similar projects and workflows. Many reach a point where they need to look at how to scale their product, or service, if they want to maintain business growth.

From building websites to providing SaaS products – as the business becomes more successful, developers will find themselves having to replicate essential tasks at scale to simultaneously handle a larger number of projects. One issue they need to address is how they deliver what customers want without creating inefficiencies for themselves. For example:

  • How do they rightsize technical resources (such as RAM, storage or network traffic) for specific projects? 
  • How do they deal with fluctuating resource demands for those projects? 
  • How do they ensure the team spends its time creating value, rather than engaging in unnecessary repetitive tasks? 
  • How can they make changes or provide fixes effectively and efficiently, while ensuring consistency and quality?

If a digital agency wants to scale its products and services efficiently and cost-effectively, it must solve three key challenges.

1. Cost control

When operating on a small scale, an agency has a good view of how technical resources are being allocated to projects. It is easy to keep track of a small number of projects on a regular basis, but, in order to achieve sustained and manageable growth, the agency needs to retain control over how it assigns resources to each job. How does an agency ensure it has the ability to scale resources up (and down again) for specific projects according to demand? 

For example, if a customer plans a marketing campaign on its website for a specific time period, the agency will need to allocate more resources for the duration. If an agency does not assign resources correctly, a project may not be able to meet end-user demand, leading to a disaffected customer. 

However, if it assigns too many technical resources to a project, it costs more to service and therefore makes it less cost-effective. The real risk arises when that inefficiency is replicated across multiple projects, then an agency could end up using a lot of money and resources.

What the agency requires is a platform that enables it to scale technical resources easily between defined boundaries and share resources between projects. This will equip the agency with the ability to effectively and efficiently control costs – being able to both vertically and horizontally scale when required.

2. Workflow efficiency

An agency that has built its business on a repeatable service will have developed workflows to match. Those workflows will be standardised for much of the project, possibly with some room for minor customisation at the front end, to meet the client’s specific needs. 

While many new digital agencies will have automated workflows, many more established businesses will still rely on workflows that feature a number of manual processes. As the number of projects rises, it becomes increasingly difficult for those agencies to maintain the effectiveness of their repeatable service without making workflows more efficient. 

One key task agencies must contend with is how they maintain control and prevent diversion if two different teams are working on separate projects which share an underlying codebase – often requiring modifications to code in order to fix issues, or add features for each project as they go along.

How does an agency structure its processes to ensure there is consistency and integrity across all projects? It achieves it by automating more of the workflow, for example by using Continuous Integration/Continuous Delivery (CI/CD) tools and stripping out manual processes, helping to make the service deliverable to the same high standard across multiple projects. For this purpose, digital agencies should select a platform which encourages the use of automation, whilst providing support for their technical teams in adopting essential DevOps principles.

3. Quality control and security

Dealing with an increasing number of projects creates headaches for lead developers to ensure all projects have, for example, the latest security updates. Traditionally companies have implemented processes such as Change Advisory Boards to ensure that updates or additional features meet the security and quality needs of their company. However manual processes such as these greatly increase the time to deployment of changes. 

Research carried out by Nicole Forsgren PhD, for her book Accelerate, suggests that one of the true indicators of quality is how quickly code is deployed to production. By allowing developers to deploy quickly, and implementing automated processes to ensure quality, new features can be delivered faster and issues can be fixed immediately. This is particularly important when critical security issues are detected.

Scaling to focus on business growth 

As digital agencies grow, they are in danger of spending time and money on operative and repetitive activities, at the expense of the productive business. It is important to remember that it’s not always purely about growth and expansion and in uncertain economic times, agencies may look to scale their product or service to do more with less. One proven way for businesses to achieve that goal is through automation.

Automating workflows and improving scalability may be the preferred outcome for those agencies, but they need to try and achieve it with the least impact on the business – and avoid complexity while they do it.

If digital agencies want to serve customers better and more effectively, they need to address the challenges that come with scalability. For some, scalability might be better enabled with the aid of an external provider. Much of the complexity attached to making the service or product scalable – and the associated requirements for cost control, more efficient workflows and greater quality control – can be addressed by an external specialist, leaving the agency’s team to focus on the core business. 

Technology, such as Kubernetes, can play a powerful role in enabling agencies to simplify the deployment of new projects, continuously distribute changes and automate the scaling of projects. When considering how to scale a service or product, savvy agencies understand that they need to focus on both technology and business processes.

For any other information please contact us.

Why build an in-house Kubernetes platform?

Having the reliability and mature APIs of global-scale cloud providers offers the possibility of a massive productivity increase over managing low-level infrastructure yourself. We have directly benefited from this at Nine with our first Kubernetes product, managed Google Kubernetes Engine, and we have no plans to stop working in the cloud or offering our Kubernetes stack there. So in an age of GKE (Google Kubernetes Engine), AKS (Azure Kubernetes service) and EKS (Amazon Elastic Kubernetes Service) it might seem strange that a managed service provider, well accustomed to working in the cloud, would invest significant time and effort into making their own in-house Kubernetes offering, especially considering the technical complexity of such an undertaking. But since the Platform Team at Nine has spent the last two years doing just that we thought it would be interesting to discuss why and where we go from here.

Swiss Location

There is no getting around the fact that some of our customers, be it due to risk management, data protection or reasons of tradition, require their managed services to be located in fully Swiss owned and operated data centres. Due to the multinational nature of cloud providers and the complex international laws that exist around data privacy (for example the CLOUD Act), it is just not possible to make the same privacy guarantees found in Swiss law when working in the cloud. Although the industry has begun to see more previously hesitant industries such as banking and insurance move to the cloud, there is still a clear hesitancy. 

This, therefore, became a primary driver in the development of our in-house solution, Nine Kubernetes Engine, to offer our customers the same robust privacy and security protections of Swiss law when using Kubernetes that our other managed products enjoy.


Although it is possible to cost optimise usage of the cloud this often comes with requirements such as significant time or spend based resource commitments, this may not be suitable for every customer or use case. By building a Kubernetes offering in our own data centre we have been able to leverage our high-density Nutanix infrastructure to bring down the per-minute cost of resource consumption for customer node pools without requiring any committed use agreements. In addition, we have been able to offer, for the first time at Nine, CPU and RAM costs calculated with a per-minute granularity instead of fixed monthly prices. This not only means a cheaper resource price overall compared to our cloud locations but will allow customers to leverage features such as cluster auto-scaling with Keda* to further cost optimise their setups.

We have also invested significantly in re-engineering the architecture of our Kubernetes service stack. Firstly, we have made additional components of our service stack opt-in. This allows customers to only deploy the services they are using and thus consume (and pay for) fewer compute resources. Secondly, we have moved a number of these services outside of customer clusters. This allows us to optimise not only the way that we deploy, configure, and maintain applications but also their cost-efficiency. Moving Nine services away from customer clusters also helps to minimise the potential for security or stability issues near customer application environments.

The result of these changes is that we have moved to a new costing model for Nine Kubernetes Engine, which involves a small fixed price cluster fees and additional optional service fees in addition to dynamic resource usage costs.


One additional goal that we had in building an on-premises Kubernetes offering is that it would be our first product to offer a fully-featured self-service interface. Our goal in implementing this was to allow customers to easily action common tasks which previously would have required interaction with a Nine engineer and thus wait time. Self-servicing a Kubernetes cluster means that customers will be able to control their clusters and node pools, storage, additional service configurations, and user accounts. 

This forms part of a larger goal at Nine to bring self-service to our product line. Our goal is to offer self-service through both a browser-based GUI, Nine’s cockpit, and an API. This will not only make managing your services faster and easier but allows Nine’s service catalogue to be leveraged for automated and DevOps workflows. As this is a major change to how customers interact with our services we will be rolling these features out in an incremental manner, with the GUI for Nine Kubernetes Engine in general availability now. We expect the API to be generally available in Q4 of 2022, and that additional products and services from across Nine’s portfolio will be added in an ongoing manner.

Future Products

Having a fully in-house, automatable and self-serviceable Kubernetes platform forms the basis for future product development at Nine, allowing us to explore concepts like Function as a Service or Namespace as a Service. It also allows us to choose where to run managed services so that we can, where appropriate, take advantage of Kubernetes features such as auto-scaling to provide a better customer experience. In addition, by having built a scalable and flexible self-service system on top of Kubernetes we are able to bring our existing products and services into a self-service environment without significant engineering or customer disruption, to make working with Nine faster, more convenient and more efficient for everyone.

If you would like to learn more about our Kubernetes offering, please contact us.

*Available for Nine Kubernetes Engine in Q3 2022

If you would like further information regarding self-service, contact Nine.

What is self-service in cloud management?

Self-service has become ubiquitous beyond the IT sector. Nevertheless, self-service cannot solve every problem. What do customers really want? This post outlines the advantages and disadvantages of self-service in cloud management.

What is self-service in cloud management?

Self-service is more than a simple do-it-yourself approach: the word denotes that something has been automated. The idea behind this is to make processes more efficient and to enable easier access to low-level services. In IT, this is no longer surprising – whether in IaaS (Infrastructure as a Service) or SaaS (Software as a Service), self-service has become the standard. With cloud self-services, customers can book servers and storage space themselves, or start applications through a web-based portal.

Through the wide-spread use of self-service, its strengths as well as its weaknesses are increasingly brought to light.

When is self-service beneficial?

Self-service provides clear advantages. Here are the three core benefits:

1. Self-service means flexibility.

When experienced IT specialists want to manage cloud applications quickly and independently, self-service is hard to beat. A specialist can configure databases and activate additional storage without any outside involvement.

2. Financial optimization is simplified.

Several self-service portals provide usage-based pricing models, meaning that customers only pay for what they really use. Thus, depending on fixed monthly or quarterly packages has become history. In particular, this can be crucial for small and medium-sized companies and agencies who plan from one month to the next.

3. In cloud computing, automation is king.

Customers who develop and sell software themselves benefit from the automation of the entire supply chain. Modern self-service portals are based on an API which is also accessible without the portal itself. Thus, application management in the cloud is an automated process; as well as activation and deactivation of VMs, load-based configuration of databases and much more.

Not a solution for every problem

One thing is clear: self-service is no panacea, even though it is sometimes claimed to be – whether in CRM systems, customer support or as an employee self-service solution (ESS).

There are three key reasons for this:

1. No self-service portal is all-encompassing.

Every sector, and every client, has different needs. In every case, human involvement is needed at some point. In cloud management, this is clearly evident:

Since technologies like Kubernetes can be used for such a broad range of applications, and since every customer uses it differently and therefore has distinct requirements when it comes to the end product, service providers have to be aware that no self-service frontend can provide a solution for each and every one of their clients.

2. Security requires quality control.

Self-service alone cannot create security. And this is not due to the fact that individual users should not be trusted, but simply because it is always useful to have a second pair of eyes to check.

It is easy for users to make a mistake when configuring their own server. They are only human, after all. Clicking on a new, unfamiliar feature requires current knowledge of possible security vulnerabilities which a user might not be aware of yet. 

Having someone double-check can help to avoid unwanted consequences early on.

3. External expertise can uncover unexplored potential.

While the online portal allows for functionalities to be activated or deactivated, a dashboard cannot indicate whether a feature would be useful in specific scenarios. A competent advisor, on the other hand, can immerse themselves in the use-case, point out possible fallacies and find optimisation potential.

Customer Support Requires Expertise

Here’s the truth: no automated solution can replace a human consultant. This is not only substantiated by our many years of experience in working closely with customers – a current IFZ Retail Banking Research Paper also shows:

  • Large parts of customer interaction are now digital.
  • Nevertheless, one-to-one conversations remain the most popular communication channel.
  • The key to success is consulting across both digital and analogue channels.

The banking research paper corroborates what we know from our own business: customer service is about more than self-service. It is about consolidating automation and consulting.

At Nine, this is what we have found, and we see it every day in practice; our customers want our expertise. They like to pick up the phone and reach out, because this allows them to have an in-person chat with an engineer.

However, consulting only works if the consultant is seen as an expert who gives neutral advice rather than acting as a salesperson, someone who is competent and knows the customer’s individual circumstances.

Direct access is key

In conclusion, there is good reason for self-service as a standard in IT. At the core of this is direct access — to one’s account, to configurations, booking and billing. But also direct access to technical expertise, to the engineer. Many self-service providers are unable to supply the latter, as their offering is fully automated.

In the end, self-service replaces many cumbersome processes. However, there is one thing it cannot be a substitute for: personal consulting and the service provider’s expertise.

If you would like further information regarding self-service, contact Nine.

DevOps: What you should know about DevOps and the use of the DevOps concept

When development and operations are in tension, separate teams, each with their own self-image and different principles, concepts and tools, become a major challenge, and not just in the IT sector. Inevitably, conflicts or problems arise that stand in the way of rapid, agile development and deployment of new applications or software. With DevOps, companies can solve this dilemma and bring development and operations closer together. Processes are accelerated without the quality of work suffering.

We will show you what is behind DevOps, demonstrate concrete technologies and tools, and provide real-world examples. 

What is DevOps?

The word DevOps is made up of the first letters of the two English terms “Development” and “Operations”. It is a conceptual approach that improves and accelerates the processes in software development and system administration through closer integration. It is a response to the weaknesses of traditional software development, such as the classic waterfall model. Development, testing and operation are much more closely networked and coordinated with each other through continuous feedback. The goals of DevOps are the fast and agile implementation of new requirements, short release cycles and the provision of stable, high-quality software.

Often, the design of the DevOps concept is interpreted differently: Some focus more on the technologies, tools and ways of working, others more on culture, management, leadership and working philosophy. What unites both is that DevOps is a comprehensive concept and concerns the interlocking of different areas. If DevOps is to be introduced in the company, not only technologies, tools and working methods have to be adapted, but the corporate culture, management style and working philosophy will also change.

One more note at the end of this definition: IT security is increasingly being integrated into the DevOps concept. The so-called DevSecOps extends the DevOps concept to include the security aspects. DevSecOps is a logical continuation of the DevOps idea.

How did the DevOps concept come about?

In the past, traditional software development was guided by models such as the waterfall model.

The waterfall model is a linear model with the precisely defined, sequential development steps of requirements analysis, application design, programming and testing. After testing, delivery is made to the operations team, which moves the application into production and makes it available for use. For each new requirement, the entire development process has to be gone through again. Between development and operations, there is only the delivery interface and hardly any feedback. For these reasons, the processes are slow and error-prone.

For the modern application environment with rapidly changing requirements, these compromises are no longer acceptable. To speed up processes and improve product quality, closer collaboration between software developers and IT operations is required. The DevOps idea has emerged from the desire for more agile software development.

DevOps principles and methods

In some ways, DevOps is similar to the Kaizen principle. If you are not familiar with Kaizen, Kaizen is a Japanese word and means “improvement” in English. The Kaizen principle stands for a concept that involves all functional units and acting persons involved in order to continuously optimize a process. Kaizen is used in a wide variety of industries. For example, if a problem arises in a production process, the employees involved in the process report it immediately and interrupt their work. The problem is analyzed on the spot and corrected together with development, control and management. If you would like to take a closer look at Kaizen, you can find more detailed information on Wikipedia, for example.

Transferred to the DevOps idea, Kaizen means that the development and operational processes are in a continuous cycle consisting of the activities Plan, Do, Check and Act. The teams and management involved must internalize the Kaizen principle. Linear models such as the waterfall model described above are replaced by a cyclical process with constant feedback. This cycle involves the planning, development, deployment and operational phases. None of these phases is assigned to a specific role. Each role (development, test, operations) is involved in all phases to some degree.

There are three DevOps principles – better known as “The Three Ways” – consisting of

  1. Flow Principle
  2. Feedback principle
  3. Principle of continuous learning and experimentation

Methods such as Continuous Integration and Continuous Delivery (CI/CD) are derived from these principles. They play an important role for DevOps. The CI/CD process combined from both methods automates all steps of integration and deployment of new program code.

What is Continuous Integration (CI)?

Continuous Integration is a method of continuously integrating the new or changed program code into the main code of an application in small steps. Automated tests take place during each integration and ensure that the main code base always remains stable. Time-consuming feedback and correction processes of the complete code, which would be necessary in the case of a non-steady (continuous) integration of a faulty code, can be avoided. Errors are discovered much earlier than in classical software development processes.

What is Continuous Delivery (CD)?

Continuous Delivery provides new versions of an application or software automatically in regular short intervals in the production environment. The current software can be delivered at virtually any time. The user receives a current version of his software executable at any time. Automated tests ensure that the applications are checked, regardless of their development status. The continuous updates reduce the risk of deployment errors compared to large software jumps.

What are the benefits of DevOps?

Most of the benefits come from the close integration of development and operations, which allows for better communication, faster feedback loops, and agile actions in the first place. All aspects in the lifecycle of an application are mapped in a comprehensive overall concept. Software can be delivered faster, more flexibly, and more agile without compromising the quality of the application and the stability of operations. The requirements of modern applications, which change in shorter and shorter cycles, can be better mapped from both a development and an operational perspective. High quality and rapid deployment of new or adapted software no longer represent contradictions. The advantages of DevOps are briefly summarized as follows:

  • fast, agile implementation of new requirements
  • accelerated delivery of high-quality software
  • accelerated innovation cycles
  • shorter time-to-market
  • early detection and elimination of faulty code
  • reliable operation of applications
  • Closer collaboration and better coordination of previously isolated teams
  • More efficient management of complex systems
  • Optimization of workflows and more efficient use of employee resources
  • Improve the customer experience

What is the relevance of DevOps in today’s enterprise environment?

In today’s business environment, software plays a critical role in all areas of the enterprise. Applications support or control almost all business processes. Increasing digitalization and Industry 4.0 further increase the importance of software. Hardly any part of the value chain can be done without software support. In order to keep pace with the rapidly changing business world and the competition, it is crucial that applications can be adapted quickly and made available in high quality and reliability. IT problems or software errors discovered too late can lead to production downtime and enormous financial losses. Classic development and operational processes are overwhelmed by the speed of today’s business world. DevOps provides appropriate solutions and is highly relevant for companies regardless of size and industry.

With DevOps, the required application functions can be provided quickly and in high quality, IT architectures can be improved and work resources can be used more efficiently. In this way, companies deliver excellent service to their customers.

What technologies and tools are typical for DevOps?

In addition to working principles, methods, corporate culture and working philosophy, DevOps has a lot to do with technologies and tools. In the implementation of the DevOps concept, the use of the following technologies is typical:

  • Cloud computing
  • Container virtualization
  • Container orchestration
  • Micro service architectures
  • Serverless computing
  • Code repositories

Cloud computing with its service models Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS) paves the way to abstracted IT environments. For example, the infrastructure required for application operation can be mapped as code, versioned like software and provided on-demand. Providers such as Google, Amazon or Microsoft, and many other companies provide corresponding cloud platforms.

Container technology ensures the virtualization of applications or services and separates them from the underlying resources. Container runtimes such as Docker or containerd have established themselves as the de facto standards in the field of containerization. Micro-service-based architectures for cloud-native applications can be built from many individual containers.

The management and proper interaction of the many different containers is handled by container orchestration. The most popular and widely used tool for container orchestration is Kubernetes. Kubernetes automates the creation and deployment of containers and enables the elegant mapping of complete CI/CD pipelines.

Code repositories such as GitHub serve as a central code version management in the DevOps environment. A variety of different developers can work simultaneously on a code base while others review and evolve the code. The consistency of the code is ensured at all times.

The concrete use of the DevOps concept: Two concrete examples of DevOps

Case 1: New application of a startup that needs to adapt quickly to changing market requirements

Speed and efficiency are critical to the success of a startup. Suppose a startup provides a new innovative application. Adaptations to the application must be made available in short intervals, often only a few days, in order to respond to the demands of the market or the emergence of possible competition. The classic linear development process is not suitable for such an application, because there is simply no time to go through the development process completely for each new feature and only then roll out the software. In addition, money and labor resources are scarce in a startup company. If the software adjustments are made according to the DevOps concept in a CI/CD pipeline, new functions can be implemented in short regular cycles and released directly for production. The entire process is automated, extremely efficient and requires little manpower. Costly, time-consuming and conflict-related coordination and handover processes between development and operations teams, which are typical of classic development processes, are avoided. Continuous, automated testing ensures the quality of the software.

Case 2: Business-critical applications in the balancing act between reliability and new features

Software used in the enterprise resource planning (ERP) environment, for example, places high demands on availability and reliability. The applications control critical business processes. A company simply cannot afford application failures. At the same time, the latest functions must always be available in order to efficiently map all relevant processes in the company. For an IT service provider that specializes in such software and provides it to its customers on the basis of cloud computing, the use of the DevOps concept is recommended.

DevOps resolves the conflict between reliability and functional scope. New features can be integrated into the software step by step at short intervals in a continuous process. There is no need for a “big bang” in which the software is upgraded to the new version in a semi-annual or annual cycle. It is not uncommon for such a large update to cause significant disruption to the operational processes controlled by the ERP software.

The continuous updates have the advantage for the users of the software that always only small areas are affected by the changes, the rest of the code base has hardly changed. Automated feature tests carried out in advance ensure high quality standards for newly introduced functions.

Conclusion and what the nine cloud navigators offer you in terms of DevOps

The nine cloud navigators offer extensive support in the area of DevOps. In particular, we take care of the Ops part and provide you with our managed services more time to focus on your core business of software development.

Our products like Nine Managed GKE (Google Kubernetes Engine) provide the optimal technical base to manage development and operation of your applications in a holistic way. We offer direct support from Switzerland and deep expertise in container orchestration with Kubernetes. In addition, we operate two redundant Swiss data centers with our own servers, on which customer applications can be run reliably, with high availability, securely and with high performance.

Can’t I just go to the cloud?

The biggest cloud migration challenges in 2021

One thing that we often hear at nine, being a Managed Service Provider is “Why are you needed? Why don’t we go directly to the cloud ourselves?” Although it’s not in doubt that with the easy to use GUI’s and extensive service offerings of cloud providers doing everything yourself appears to be a tempting proposal, but unfortunately there are a number of pitfalls to avoid and this is where working with an Managed Service Provider could help you. My colleague Peter has already written about this from a more general perspective and I would urge you to begin with his excellent overview. The aim of this article is to talk a little more in detail about technical challenges that you may face and how an Managed Service Provider can support you.

Range of choice

Probably the first, and most obvious, issue is simply the sheer range of choice available in the cloud. To make the move from a “classic” VM based setup to a dynamic cloud infrastructure can be overwhelming without guidance, not only do you need to select the right services, but you will need to be sure that you configure them correctly, understand the quality guarantees that are given, and design your architecture with this in mind.

Unfortunately, unless you are a very big company (with correspondingly deep pockets) you are probably not going to get the assistance you need directly from a cloud provider, indeed this is exactly why cloud providers partner with companies such as nine.

We are able to stay close to you, work in concert with you, and accompany you along your journey to the cloud. At nine because we offer both classic hosting in our datacenter and in the public cloud we are able to join you at whatever stage of the cloud adoption journey you are in, and our highly trained engineers and solution architects are able to meet all of your needs, working with you to design your architecture for evolution based best practices and industry standard open-source software.

Increased complexity

The second issue is hidden complexity, and this is a theme that will run through the rest of this article, for example, did you know that when using GCP it is possible to make configuration changes that would invalidate your SLA with Google Cloud? For example, setting specific flags on your cloud SQL database.

It’s fair to point out that to avoid these you just need to RTFM, but GCP has a pretty big manual and it’s always easy to overlook something that might have an impact later, especially if you are focused on your product and getting the next release out of the door.

Allowing someone else to perform this infrastructure setup, using Infrastructure as Code (IaC) principles with strict review and update practices (such as the four eyes principle) goes a long way towards mitigating these issues, and although it might feel like a loss of control to allow someone else to maintain this configuration, it’s a level of control that you don’t actually want, or indeed need, when your company or product value is derived from elsewhere.


Cost optimisation

Cost optimisation is often an issue that people want to tackle when they decide to move into the cloud, but a pure life-and-shift approach can actually end up costing you more since there is hidden complexity in ingress and egress traffic, failing to optimise the size of machines or services that you use and so on. Flexera’s “State of the cloud 2021” report states that “Organizations are over budget for cloud spend by an average of 24 percent and expect cloud spend to increase by 39 percent next year.” this might be quite a startling read if your plans for cloud adoption revolve around this lift and shift approach.

However the same report states that “organizations waste 30 percent of cloud spend” which suggests that with the right guidance and architectural design it would be possible to realise the saving that people expect from moving into the cloud.

An Managed Service Provider, if they have trained solution architects and cloud engineers, will certainly be able to help you in making these savings and moving into the cloud in a cost effective way through support, training, workshops and working together.


If you choose to run everything yourself in the cloud one of the first hurdles that you will encounter is how to robustly monitor your application. As anyone who has run an application in production knows accurate and robust monitoring is the key to understanding what is happening at runtime, and what the quality of your service is like for your customers. Even with an Managed Service Provider there is no way around this, as only you have the knowledge to pick the metrics that really matter to your customers and which you will use to measure service quality, but if you have to run your own monitoring system as well, you will face critical additional problems.

Monitoring is in fact so important that if you run everything yourself you will quickly realise that keeping your monitoring system up and running becomes more important than looking after your application, since without it you are flying blind. This means that significant resources would have to be devoted to implementing, running (and eve7n monitoring!) your own monitoring system.

This is certainly one place where an Managed Service Provider can provide great value by provisioning and ensuring the quality of these auxiliary monitoring services. Nine operates a strict SLA/SLO principle for services that it offers, to ensure that they are available when you need them, and we have SLA’s to ensure that we are bound to provide a level of service that meets, and ideally exceeds, your requirements.

Know How + Training

You may hope to overcome this monitoring reliability issue yourself by choosing to use the specific monitoring system implemented by your cloud provider of choice, since these will in theory, produce the most detailed metrics and be the most stable. However this creates a pressure on your business, it not only creates a vendor lock in to that cloud monitoring system and thus that cloud provider because the software and configuration is not portable to other setups, but it will require extensive training and education to extract the most value as you must adapt to its specific paradigms.

This time investment in a closed system obviously does not create value for you and again this is where an Managed Service Provider can help, by deploying portable, open-source, industry standards for monitoring (which in the container world is usually Prometheus/Alert Manager/Grafana) an Managed Service Provider can help to ensure that you focus your efforts on the part of monitoring that matters for your product’s success, defining your own SLO/SLI’s based on the issues that your customers really feel.

If you need help with understanding and defining those, most Managed Service Providers can help there too with consulting and enablement services that put their engineers together with yours to determine your golden signals.

Beyond monitoring if you wish to adopt cloud best practices and DevOps workflows you will need a robust toolchain and experience that allows you to build and deploy your application easily. The same problem as with monitoring arises again; these systems quickly gain as much, if not more, importance that your app since delivery of new features, critical bug fixes and so on become reliant on these systems working. This is particularly true in the world of containers and orchestration platforms where there are no such (dangerous and not recommended) workarounds such as FTP’ing files to a server in the case of last resort.

Again this is where an Managed Service Provider can help you by providing these services, and again they should be industry standard, portable, open-source tools, with ensured service reliability and quality so you can keep focused on your application.

Nine is particularly specialised in this area, having many years of experience of running both our own and customers containers in production, and this is why our platform offering is not simply a managed vanilla GKE instance but comes with all of the tools that you would need for an end to end cloud native workflow for image building, packaging, deployment, backup, monitoring and so on.

Indeed the system that we have developed allows you to go even further than this, by building on cloud standards you can easily deploy pre-made services into your cluster via helm charts, you can configure complex red/green deployments with traffic balancing to test new features, see the status of all the components of your application at a glance and roll back to a previous version easily.

We not only preach these practices, we live by them, we are using exactly the same systems as we provide to you to stage our components in both our clusters and those of our customers.

Since “Lack of resources/expertise is cited by 41 percent of respondents as a top container challenge” according to Flexera, nine has introduced all these features as standard with our Kubernetes offering to give you an experience that no other managed service provider can match (and I say this without hyperbole, if you can find a managed kubernetes offering as holistic as nine’s please get in touch with me!) along with regular workshops, our kubernetes academy and the option for individual consulting and even project work and support.

The Nine Difference

The engineers that build and maintain our managed Kubernetes platform and clusters have many years of experience of running containers in production and have administered both Openshift and Kubernetes clusters. They all hold CKA and Google Professional Cloud Architect certifications and they work with the same tools and technologies as we offer to our customers every day.

All of these reasons are why we call ourselves “cloud navigators”, at nine we pride ourselves on our ability to work closely with our customers to guide, assist, teach and support at every step of the way. To ensure that you are able to deliver the maximum value to your customers with the most robust and flexible architectures possible is our passion and we hope to join you on your journey to the cloud.

Looking Back on our TechTalkThursday #14

Our TechTalkThursday #14 took place on the 26th of November 2020 at 18:00. Due to local restrictions, we were not able to host a lot of guests, we therefore had only one personal guest of the first speaker, Joseph Pelrine, onsite. We had 130 registrations for the event and the YouTube stream peaked to 45 concurrent users. That’s more than 2x the viewers we had at the last TechTalkThursday! Thanks to everyone for your time! 

Subscribe to our YouTube Channel to get notifications for new videos and live streams of our events!

Thomas Hug, the founder of nine introduces the speakers Joseph Pelrine, Agile Psychologist, and Remy Blättler, CTO of SuperText AG. He then gave an outlook of the topics of the next Google Cloud Meetup on January 12, 2021 and the next TechTalkThursday on February 25, 2021.

The Psychology of Estimating

Estimating is difficult. So difficult, in fact, that many consider it a waste of time. Which it wouldn’t be if estimates were done efficiently and were accurate.

How can you and your team make your estimates better? Software developers learn to optimise their systems using performance profiling. We can find scientifically validated and useful tools for profiling the estimation process if we take the novel and radical approach of viewing estimation from the perspective of psychometrics.

In this short talk, we approach the concept of an estimate as a latent construct, and explore the application of tools and techniques from psychology and psychological statistics to the analysis and improvement of the estimation process.

If you’re wondering why your team’s estimates are off, and what you can do to improve them, this talk is for you.

Azure, Kubernetes and DevOps Zonk

Supertext is all in on Microsoft and the reason why they work now with Azure is more of a coincidence. In 2004 Reto Lämmler (from TestingTime fame) and Remy Blättler tried to build a business based on an automatically synchronised Excel spreadsheet. At the time Microsoft Visual Studio was installed on his Laptop because of a client project. There was no debate or evaluation. They continued the Windows track with ASP.NET until now. Today, they are using Azure, Azure SQL, Office 365 and Active Directory, where Azure Active Directory is at the core of the security infrastructure.

First challenge he was talking about was the fact that Azure Active Directory is not the same as Active Directory. They only got it working with external help.

The next idea was to get rid of all virtualized Windows servers and use Azure App Services and scripting the whole setup process. At that time, some applications were running with .NET and some with .NET Core. This worked side by side on a virtual machine. Within Azure App Services though, it turned out that .NET and .NET Core can’t run side by side. That’s the reason why they finally decided to try Containerized App Services. But the Containerized App Service was not available in Switzerland! Next step was therefore to go with Kubernetes and they got a prototype up and running.

Another challenge was Azure’s solution for secrets, called KeyVault, that wasn’t supported out of the box with the standard version of Kubernetes. Also Ingress, used for SSL termination, wasn’t available.

Built in backups work with a click, but restoring with a click changes the IP address of the server! If you want to stick with the same IP address, it only works with a complex manual process. For Blob Storage, there isn’t a built in backup solution and also the commercial solutions looked weird which finally made them build their own backup solution.

Azure is developing at a breakneck speed, but a lot of documentation is always out of date, upgrades are often not possible, lots of things are only in preview and not everything is available in all zones. Pain nr. 1 is “Ahh, no that’s not supported in your version of this or that”.

The complexity of the cloud shows in an example where 48 options were available for a virtual machine and 84 more non-available options.

All in all, Remy summarizes Azure as pretty cool as long as you are in the Microsoft world from Office 365, Active Directory, Visual Studio, C#, Windows Server, SQL Server – it all works together and is pretty powerful and nice. But it is a constant fight with versions, documentation and missing features!

Want to stay up to date?

Subscribe to our YouTube Channel!

Talk to one of our experts

Do you have any questions about our products? Either contact Sales or go directly to your cockpit to see all the possibilities at Nine.