Over the last 5 years enterprise IT has undergone a major transformation. As a general rule, transformations are good things, but on this occasion, things aren’t quite so clear cut.
The ‘old’ world - and indeed the current world for a significant proportion of the world - consists of developers who write application code for applications that add business value, and infrastructure people who figure out what hardware and environments are needed to run these applications reliably. Both groups have traditionally kept themselves to themselves and have equally strong views on just about everything….
Within each of those teams, there have been seismic shifts – dev teams have become agile and begun to embrace DevOps; while infrastructure teams have become platform teams, and engineers renamed to SREs. Along the way, technology has changed from servers, to VMs to Containers on Docker to Containers on Kubernetes, and even Containers on Serverless.
The problem of course is that developers and infrastructure teams generally talk very different languages and have very different skills, which might also explain why Portainer has experienced such rapid uptake. By acting as the ‘bridge’ between dev teams and infrastructure teams, Portainer has provided a common language and framework for the teams to share information, make decisions and manage applications.
Interestingly, many infrastructure teams exist in a ‘clickops’ world, one which means their day to day activities revolve around the functions of a management UI. This ClickOps construct has been enabled in part by Microsoft's domination of the Server OS world, and VMware's domination of the server virtualization world, both of which are almost exclusively controlled/managed from very well thought out, and extremely comprehensive management UIs that genuinely negate the need to ever use a CLI.
For those engineers used to a rich management UI, but being driven to embrace Docker/Kubernetes and all of its CLI glory, Portainer has turned out to be the perfect companion as it gives them full control of these environments in a very rich management UI, and without the need to learn new platform-specific syntax. As an added benefit it also puts a safety net in place that stops them making any demands of the infrastructure layer that can’t be fulfilled technically which significantly reduces the risk of failure.
Contrary to what DevOps evangelists tell you, there’s actually nothing wrong with ClickOps, it’s deeply embedded in the middle of the adoption bell curve and is with us for the long-haul and it explains why ClickOps tools will represent a massive opportunity for vendors for a long time to come.
A little further along the adoption curve, organizations have started to realize the benefits of merged application and infrastructure teams, in the form of DevOps (Development + Operations). In a DevOps world, teams run highly automated CI/CD toolsets where development engineers are responsible for not only their application development, but also the platform it runs upon. Some say that this requirement to manage the platform is a distraction, and robs the developer of valuable time; time that could be better spent creating a new feature or function in their application. This is one reason why DevOps relies so much on automation, so as to lessen the intrusion.
The main challenge in a DevOps world is complexity. Software developers are a bright bunch, but even the brightest can’t know everything, which is a problem Portainer has been hugely successful in solving. It turns out the poor relative in DevOps world is the ‘Ops’ part (who would have guessed?) which has allowed Portainer to again bridge the complexity gap. DevOps engineers have adopted Portainer to control and manage the environments into which they are deploying their applications.
But the story doesn’t stop there and DevOps is already morphing into something new. Engineers are always looking for the next piece of the automation puzzle, which has led to the creation of GitOps, where the management of the infrastructure is entirely code based, and managed out of a Git environment, again, trying to reduce the burdeon on the Developer.
Whether it’s ClickOps, DevOps, GitOps or whatevevercomesnextops, fundamentally, what all organizations need is a way to deploy apps in an enterprise secure, consistent highly scalable manner with the least amount of complexity and risk possible which is, quite simply, Portainer’s raison d’etre.
Regardless of where your organization, or your people, are in their journey, Portainer speaks their language. Whether that is a human interaction with Portainer, clicking and completing forms to deploy app in a no-code manner; or by leveraging Portainer's rich API and/or Git integration to manage the deployment of applications through Portainer, but in an automated code-based manner.
Portainer, your ClickOps, DevOps, GitOps tool.
COMMENTS