In the first part of this blog series, I argued organizations looking to deploy containers at scale need to remove IT Ops from the developer experience and put a self-service environment in place that allows developers to deploy apps into containers whenever they want, however they want. I likened the idea to that of a vending machine, which is the purest expression of ‘self-service’ I can think of.
In this blog I explore the different elements that make up a self-service container management platform, which we, at Portainer, now call a ‘Container Service Delivery Platform’ and look at the classic ‘build v’s buy’ paradox.
At the most basic level, a Service Delivery Platform needs to do 4 things:
And of course, ideally it should be able to do this across any hosting environment and across any orchestrator – otherwise it’s lock-in central.
Now, with enough developer time, you can build all of this yourself with scripts, various open-source tools, and a whole heap of labor. But unless building infrastructure platforms is your thing, why would you? Wouldn’t you be better off focusing your team’s efforts on building software that helps drive your business forward?
A few years back, there was no “out of the box” tooling that made Kubernetes self-service capable, however in a CNCF year, a lot has changed. Now there are any number of tools, like Portainer, that can be deployed in minutes which negate the need for you to spend months building your own.
To help make my point, look at the diagram below. To deliver a container management platform, you need at least 6 different components.
Again, this can all be built in-house using an array of “best-of-breed” tools, most of which likely possess capability far in excess of anything you actually need.
Here’s as an example of a “self-rolled” architecture:
Alternatively, there is Portainer.
Portainer is designed as a “T-shaped” platform tool (to align with T-shaped engineers), which means it is capable across a range of functionality, but expert in a few. In our case, we are expert at environment management, and highly capable across everything else.
By deploying Portainer you negate the need to deploy a lot of additional 3rd party complicated tooling just to get started. Portainer lets you get started today.
Obviously, there will be times when you need the capability only an expert specialist tool provides, and with Portainer’s integration API, this is easy to do. You can either transparently deploy tools directly into the clusters already managed by Portainer, or you can connect Kubernetes native tools TO Portainer, and we will manage the communications to the underlying environment for you. We call this “growing with you”.
So, if you want to get started with Containers in general or delve into the world of Kubernetes, Portainer is the only place to start.