Container service delivery platforms -  to build or to buy? And why that’s not really a question

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:

• Allow end users to deploy (and update) applications unaided, in a manner that suits their experience and knowledge,
• Allow end users to monitor and troubleshoot their application,
• Allow admins to set the rules within which the end users can operate,
• Overlay a governance layer that protects the platform for rogue agents.

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.

1. The tooling to remotely manage the container hosts that underpin the platform
2. The tooling required to build, update, and triage the container orchestrator/cluster
3. The tooling to provide secure and govern the platform
4. The tooling that provides the self-service portal that the end users need
5. The tooling that provides the observability that the end users, and operations, both need
6. And finally, the integration APIs that allow the platform to inter-connect with external tooling/services

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:

• Terraform / Ansible scripts can be created to manage the deployment of container engine nodes and/or deploy a Kubernetes as a Service offering from Cloud providers
• KubeADM, KubeSpray (or other similar tools such as Kops, Sidero, Charmed Kubernetes, or even Rancher) can be used to create and manage the build of a self-built Kubernetes Cluster.
• Prometheus and Grafana (or Datadog, Dynatrace etc) can be used to help operations teams monitor, manage, and triage the platform,
• ELK or Loki (or Splunk, Graylog etc) can be used for log analytics,
• KeyCloak, StrongDM, Okta or Auth0 can be used to federate authentication,
• OpenPolicy Agent to control what actions can be performed,
• Kubernetes RBAC to ensure Devs can only complete allowed tasks,
• Integration with an internal service management tool (such as ServiceNow or even github PRs) to deliver developer self-service capability.
• Any DevOps/GitOps tooling, such as ArgoCD or Flux to provide code release automation.

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 3^rd 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.