My main use case for Porter is to simplify Kubernetes deployment on simpler applications, and for developers, I use it to work alongside Kubernetes and leverage the automation and templates to deploy applications.

A quick, specific example of how I used Porter for one of my applications is when a customer wanted to have an app on the web with containers behind it. The client wanted their hands in the scaling of those containers, and since they did not know much about Kubernetes, I used Porter to provide a UI on top of Kubernetes so that they could automate the operation.

My main use case with Porter is to simplify Kubernetes operations and provide a UI to customers.

Porter has positively impacted my organization because I cannot give clients access to the back-end and let them use kubectl and everything. For example, when a client demanded it, this helped me retain the client; without Porter and its UI, they would have left me and quit the business.

The specific outcomes that show how Porter helped me retain the client and improved my business include the client being very satisfied when I provided them control over the containers through a UI, which built trust. They believed in me to provide solutions like this, allowing them to have some hands-on back-end tasks by themselves; they just needed a UI to do that.

The best features Porter offers are very useful for situations where there are only one or two DevOps members in a team. For example, my client had limited view information on Kubernetes and only one IT engineer, so it has very fast application deployment, and they can use it through the UI without having to run kubectl and other commands through the terminal.

The fast application deployment through the UI helped my team and my client because whenever they needed to scale up the containers, they did not go in and use kubectl or kube-admin commands; instead, they used the UI to scale up the application resources, allowing their applications to handle more traffic.

Regarding Porter's governance and security, I think they are good; it all depends on the users and roles, and once they are configured correctly, there are no loopholes in the user permissions.

Regarding Porter's accuracy and reliability of output, I think they are pretty reliable, including self-healing pods; with Porter, I can set automatic restarts, and for high availability, I can set up replicas. Porter is a reliable platform.

I would say Porter could be a little lightweight; I felt that it is a little heavy, perhaps because it is on top of Kubernetes.

I think it does not have many options for advanced Kubernetes operations, so they could add more features for these advanced operations.

I have been working in my current field for five or more years.

Porter is stable, and in my experience, it has remained stable.

Porter's scalability is pretty impressive; it can scale and deploy high availability replicas, and it helps me scale because it uses Kubernetes.

I have not interacted with customer support, but I observed that the documentation was good.

I did not previously use a different solution; this was the first client requirement, and I used Porter as an organizational decision.

Before choosing Porter, I do not think the team evaluated other options; they pretty much went with it.

I have seen a return on investment because time was saved as I did not have to build a custom application to let the client control the Kubernetes pods; I set it up in about two days, which also retained the client and saved a lot of time.

My experience with pricing, setup cost, and licensing is that the setup cost is good; it is not highly priced software, and for one client, I think it was a very minimal charge, making it pretty good.

My advice to others looking into using Porter is that it is for minimal operations on Kubernetes; it is not for advanced operations, so if they look into advanced operations, they should hire a DevOps professional instead of using Porter. I would rate this product nine out of ten.