The mention of Kubernetes is with regard to the write-up and the issues they were trying to resolve. I agree that 99% of ERPNext users don’t need Kubernetes. But fortunately, Frappe / ERPNext on Kubernetes is available for those whose loads would require it. This makes Frappe / ERPNext future-proof in a way. For those who are knowledgeable enough, deploying via containers is simple and powerful.
A benefit Kubernetes brings to Frappe / ERPNext is High Availability - meaning, you don’t care if your server breaks down. You have the option of three or more (as long as it is odd numbered) “master” replicating servers - if one goes down, the other two is there to take up the slack. You can place there servers in different locations so that fire and other natural disasters would not affect the server operations.
If you are using cloud, you can even place your servers in different zones and different providers. This way you are assured of total stability. With the cloud, adding servers is a click of a button away.
Another benefit Kubernetes brings to Frappe / ERPNext is scalability. Suppose the load on the servers is growing - because probably, more users are using the system. No problem. You just add more “slave” servers. On the cloud, Kubernetes can automatically do this for you - spin up additional compute engines when load gets high and spin down compute engines to save money when load gets down.
Other containerized applications may run alongside Frappe / ERPNext, and you can monitor how each application is doing. Which server is experiencing trouble, which server is down, which server is doing well. All in the comfort of your terminal.
This is what Kubernetes can do for Frappe / ERPNext. And this is available to the community. Thanks to Revant.
If components of Frappe / ERPNext can be separated so that the separate functionalities is contained in individual containers, Frappe / ERPNext will even become more powerful because when the user load requires an increase in power, only those containers will be auto-scaled.
This is just the surface. Storage can be kept in multiple computers which contain duplicate copies of data. If one computer goes down, you just replace it, and the team of computers will welcome the new addition and place duplicated data on it. This is how you achieve massive scale. Fortunately this technology is available in ERPNext / Frappe, and would become even more powerful if the community understands the full potential of Revant’s work.
To illustrate, we have one company whose CTO has never heard of Kubernetes and containerization and microservices. So, he makes the company buy a very expensive and powerful server whose components are expensive or perhaps internally replicated. Then, he stays up late at night worrying when the expensive server may go down. His disaster prep is doing backups. For DevOps, he has to take down the server, install the new app, bring up the server, and hope the new app has no bugs.
Then, we have another company whose CTO knows about kubernetes, containerization, and microservices. He makes the company buy six ordinary, cheap, easily replaceable servers (three master and three slave). He also subscribes to virtual compute engines on the cloud. He connects these using Kubernetes. He installs apps using Helm. Then, He designs the DevOps in a continuous delivery mode where, when the developer team brings out a new release, the deployment serves only a portion of the users, and gradually increases the users until all the users use the new version. In case of any problem, Kubernetes quietly rolls back and serves the old version. The users don’t notice anything, nor experience any downtime. This is the technology that is now available with Kubernetes.
This shows the value of Open Source. While other ERP systems, may still be trying to know how to containerize their apps into Kubernetes, here, we have a member who did the hard stuff for all.
Note: of course you can start with one server and experience the ease of installing containerized application. Then you can elevate to High availability or add more slave servers when required.