We use it for storage. In terms of data locality, Portworx is pretty good compared to other technologies in the long run. We also have other SBS layers, but those are not enterprise, and there are not many offerings from those technologies, so I understand.
The best thing about Portworx is the Stork, they have called the VPS (Volume Replacement Strategy) and they also have topology awareness, and these are the three features I like. Additionally, the engine is thoroughly tested, and the load-balancing engine can handle the load very well.
One area where Portworx can be improved is with data locality. This is not always achieved, especially when we don't use VPS or when we don't have a sufficient number of worker nodes. Portworx generally guarantees data locality, but we have found that with a replica factor of two, we need six worker nodes to ensure data locality. Data locality is important because it allows data pods to find the data locally instead of going over the network. If the data is not locally present, it has to go over the network to get it. So data locality is an area that could be improved. Additionally, the documentation could be better. We have found quite a few bugs, and they need to improve the documentation to address this.
It is a scalable solution. It can easily scale up and down. Around 20 people in my organization might be using Portworx Enterprise at the time.
We've had a constant engagement with Portworx support and have raised quite a few bugs with their toolbox.
For the initial setup, the company provides Portworx's Spectrum, which generates URLs after passing a few details, making it seem straightforward. But it's not that easy. Sometimes issues arise during deployment because understanding the Portworx architecture is crucial. It has several components, such as KBDB, a Stork scheduler, and Portworx cluster, so understanding the architecture helps troubleshoot any issues.
The initial setup usually takes five minutes. It's pretty fast.
It has two offerings. One is free, which is limited to only five nodes. The other is enterprise, which is a bit pricier.
Let me give you an example of a customer. They provided storage but not for use with Kubernetes. The storage was network-attached and not integrated with Kubernetes. In order to integrate the storage with Kubernetes closely, you need to install drivers. Requests for PPE or PBC creation and volume creation should go through these drivers. The drivers are deployed as ports or deployments in Kubernetes. For example, Dell provides its own Kubernetes plugins when we use Dell storage, which makes it easy to provision the requested storage. Currently, it can interact with the storage.
In one of our customer's cases, the storage was connected to all of the nodes, but the integration was not done because that storage did not support Kubernetes integration.
We had a database application that needed dynamic volume provisioning, which was not the case. We tried initially with Longhorn, but we ran into many issues. So we had to drop the idea of Longhorn and go with Portworx. When compared with Longhorn, Portworx was better in terms of performance and handling of the load. So we deployed the solution and tested it thoroughly. We went through the Portworx documentation and features. Basically, Portworx uses Stork, which is one of their native technologies that you can leverage as Kubernetes. Whenever a port request comes in, it goes to the Kubernetes scheduler and that information is passed to Stork. Stork then assigns scores to the worker nodes based on the volume where it is present. This ensures data locality, and Portworx does it better than other technologies in the long run. So based on that, Portworx will be deployed on a node where the volume is already present.
I would recommend the solution depending on the use case. If a use case demands support, and the high-performance, then you should go for Portworx. Also, consider the type of application you want to use it for and take certain factors into consideration before going into the storage, VPS layer, or CSI.
Overall, I would rate the solution an eight out of ten because of the data locality, documentation, and possibly a cheaper price, which could increase the score. It works quite well under intensive load, and support is available. It does what it has to do at the end of the day.
