Portainer, a Kubernetes Management Platform for newbies and experts alike.

Portainer is a tool primarily designed to empower non-experts to deploy and manage container-based applications within enterprise Kubernetes (and Docker/Nomad) environments.

We achieve this design goal by removing as much mental burden as possible, allowing for browser-based, no-code, or low-code deployment and management/monitoring of applications across any Kubernetes cluster managed by Portainer (on-prem, cloud, KaaS).

Our forms-based "click-ops" UI is often seen as counter to modern Infrastructure as Code principles, and this is absolutely correct. If you want to have 100% consistency, and 100% repeatability each and every time, then having humans manually defining deployment specifications for each deployment may ultimately result in discrepancies.

So, why does Portainer persist in offering and enhancing our forms-based UI, if we know it's counter to IaC?

Simple, because there are millions of developers and IT Ops people from organizations across the globe that are only just beginning to get exposure to containers. These people often have no choice to adopt Kubernetes and we want to help make their Kubernetes adoption as efficient, and fast as possible. Like it or not, a web UI is the most familiar way to achieve this (think cPanel, Plesk, vCenter).

Remember, not every company develops their software stack themselves. Many buy "off the shelf" software that needs to run in containers, and these organizations likely don't have a Development/DevOps team that is up to speed with Kubernetes.

The same is true with organizations that create web apps or business apps, that sit on top of turn-key stacks. These companies likely have developers that are not deeply familiar with infrastructure, so need help getting their app running in Kubernetes, again these are not likely to have a DevOps team either. How can companies that fit into this criteria be expected to leverage Kubernetes if they are forced to use Kube native tooling? They likely cannot. Portainer bridges the gap here.

What we aim to do, is enable a safe and secure, self-service "click to deploy" UI for these non-experts, while at the same time, allowing EXPERTS to set the rules of the game.

Every company deploying applications in containers needs access to an expert - this is a fact. The expert can be an in-house person, or an external consultant, but regardless, at least one person must be responsible for the initial configuration of the environment. This expert can then configure what their users can see and do across the managed clusters using Portainer's RBAC functionality.

From security rules (don't allow containers to run as PID1, don't allow bind mounts etc), to quotas (max CPU, RAM, Disk, load balancers, etc), to enforcing the use of namespaces (disabling the use of the default namespace), and many more. The goal is to allo

w the EXPERT to enable non-experts to self-serve in a safe and governed way. 

But why does this matter? Because experts are like diamonds; in demand, hard to find, expensive, and often stolen :).  When you have one, you need to make sure they

ar

e not bogged down with mind-numbing questions from non-experts. The more "101" ques

tions you can take off an expert, the happier that expert is. Experts want to focus on making the platform better, they want to focus on automation, they want to focus on the really challenging issues... they don't want to answer "help me deploy this app again" for the 50th time this week. Experts need a "force multiplier" to help them do more, without having to work every hour of the day.

So, Portainer is not a  tool that experts would likely use themselves on a day-to-day basis. Portainer is a tool that experts deploy to make their life just that little bit easier. And trust me, you want happy experts as they are the drivers of innovation!

Surely though, if users interface with Portainer, what happens when they do actually need help? Does an expert have to use Portainer to assist? Not at all... Portainer is a fully-fledged API proxy for Kubernetes, and the expert can use whatever tooling they prefer to triage the resources deployed through Portainer. Of course, if preferred, the experts can use our UI to inspect and make changes too, and as admins, none of the restrictions apply, so nothing gets in their way.

I hope this helps explain why Portainer is a tool that both experts and those who are new to Kubernetes, find helpful.

If you are an expert, give Portainer a try, it might save you from going crazy supporting your users :)

Neil