Anyone that has been around a while knows IT typically flows in 7-10 year waves. Normally, these waves make perfect logical sense and everything gets better for everyone as a result, but sometimes there’s a glitch in the matrix and it all makes a bit less sense. There’s an argument Containers represent one such glitch.
As an industry, we’re out of the VM wave, in the later stages of the cloud wave and driving deeper into the container wave as every month passes. Whilst the cloud enabled freedom from managing on-premises platforms, and the inevitable never ending asset replacement cycle, it ended up causing “pay as you go” hell. It was (and still is) a very common occurrence to hear stories of organisations being unable to forecast their monthly bills, and worse, not even be able to afford them as their growth in adoption increased. Unfortunately, many were often stuck with their provider (and the costs) due to technology lock-in. Containers, and specifically Kubernetes, was seen as a layer of technology abstraction that commoditised the cloud providers, allowing organisations to deploy their application in a consistent and portable way, that was completely free of any lock-in.
As a technology, containers definitely delivered on the promise of commoditising IT platforms, being able to offer a singular consistent API/framework regardless of where the platform was deployed; cloud (any), on-premises, or even a combo; but at the same time they’re causing a world of pain for organizations who are just trying to keep up with digital innovations.
Like it or not, containers are creating a two-tier society, one tier that can afford the rockstar engineers who know how to build and manage complex containerized environments, and everyone else. In a wildly resource-constrained market, the ‘haves’ are getting richer and the ‘have-nots’ are getting left behind and out-competed. In a global ecommerce world, where competitors can come from anywhere, not just in your country (think “sheen” as a perfect example of a fashion industry disrupter that is a pure-play ecommerce engine ONLY), this is a problem for everyone, as unless everyone gets to ride the container wave, things start to go very wonky very quickly.
We know containers are awesome, but they are hard to manage (shock-horror), particularly when they are deployed at scale and where some level of orchestration is needed. To be valuable, developers who historically were focussed purely on writing code, now need to be “full stack” and understand a raft of new concepts. In fact, for the teams involved in delivering software inside an organization, containers represent a whole new organizational design, language, way of working, and set of principles and paradigms.
Container, unfortunately, change everything. And when everything changes there are always casualties.
So, how does Portainer fit in?
Portainer is designed for the ‘have-nots’ who know they have no choice but to ride the container wave (because the software applications they are either buying or building all run in containers) but don’t want to / can’t afford to invest in a team of rockstars to build and manage a container environment. They simply want a ‘turnkey solution’ to the container management problem.
Curiously, the ‘haves’ in this mash-up don’t want a turnkey solution at all as it represents an existential threat to the rockstars who are making lots of money creating long-term very expensive chaos for early adopter organizations. This is the glitch in the matrix at work….
It’s becoming increasingly clear that there is simply no competitive advantage to be had by organizations in becoming experts in containers. The real competitive advantage comes from being able to exploit the power of containers without incurring the insane costs associated with learning and managing them.
As a Container Management Platform, Portainer does something really important. It makes containers accessible to the have-nots. Without Portainer, the have-nots will find it really hard – if not impossible - to get on the container wave, which has potentially far reaching implications for them and the IT teams that support them. There’s an argument that in the case of the have-nots, Portainer is almost priceless, but that’s for them to tell us, not the other way around.
In the crazy dev resource constrained world that we now live in, any tooling that allows existing developers to spend more time developing and less time working on things that don’t add any value (like infrastructure) has huge value. Developer Hours Saved is the new currency of the IT vendor community and Portainer saves a LOT. Like really, a LOT.
With Portainer,
- Platform Managers without deep knowledge of containers or Kubernetes can set up and configure a container platform that developers can use to deploy their code themselves 24x7 without actually knowing how Kubernetes works. That in of itself represents a massive cost/time saving to organizations as it means existing ops teams can be re-purposed rather that turned-over.
- ‘Normal’ Developers (ie the sort that write .net, .js, .php applications) can deploy their own code into test, dev or prod environments on prem or in the cloud through a simple point and click interface (with guardrails in the background defined by the Platform team in place to ensure they don’t break anything along the way). They can just point and click, which makes triage and troubleshooting infinitely easier. There simply is no CLI.
- DevOps teams can set up CI/CD workflows deploying directly into Kubernetes without having to know the intricacies of the orchestrator.
We’ve spent years (literally) making the underlying technologies (Docker/Kube etc) nearly invisible to the end user so they can focus on delivering higher value functions. We firmly believe the goal of a software delivery team should be delivering more code, not to become experts in Kubernetes for the sake of it!
So, can you actually quantify the time savings associated with Portainer? Probably, but anyone that has ever lifted the hood on Kubernetes and had a look underneath will know instinctively that whatever the price point associated with Portainer, it’s a quantum less than the cost of trying to reskill an entire organization in the art of Kubernetes.
The other side of the Portainer value proposition relates more to security / compliance and represents another one of those matrix glitches. The container wave has essentially standardized on Kubernetes, which is a wildly complicated piece of software in its own right. However not only is it complicated it’s also relatively insecure in many ways which is a problem for have-nots who don’t have the expertise on staff to know how to secure it. There are now thousands of known exploits in the wild targeting poorly configured Kubernetes systems, and many masquerade as harmless pieces of software that then get deployed by devs without realising their ulterior motives.
With Portainer in place, users only have access to the tools, features, capabilities they need, and with the lowest level of privilege that they need to get their job done. Many/most compliance obligations are met as a result. This is super important as the use of Containers grow inside the organization, and organizations expand from a few nodes to a few clusters.
Time will show there’s nothing wrong with being a have-not. In fact, as far as containers are concerned, there’s actually a whole lot of benefits to come from being a have-not. As a have not (with Portainer) you won’t ever have to dig your way out of the Kubernetes hole the early adopters have dug for themselves and pay the Kubernetes tax that the matrix has imposed on us!
If you’re a have-not and you’re ready for a turnkey container solution then come and talk to Portainer. You’ll be glad you did.
COMMENTS