We design and build tool chains which build on traditional CI/CD tools to improve the developer experience

The way I view it is: 1. You want to keep development teams focused on development tasks (features / fixes) for apps and not operational tasks 2. You want give those development teams flexibility to use whatever development tools and languages they feel is warranted or is productive (e.g a nice promise of microservices I've taken these two requirements and created a scalable docker swarm infrastructure that runs our applications- the developers don't need to concern themselves with this. Whats the intersection then between development teams and this swarm infrastructure? Well.. there is an internal docs site that explains - once your app is ready, how to package it up and publish it as a stack (docker swarm terminology) i.e by publishing any docker images and providing a docker-compose.yml. The docs explains other "platform" features you can leverage - like how to add labels to this compose file so that your app receives ingress traffic. Or receive messages from a message / topic queue (i.e async messaging between apps provided by the platform) and a bunch of other "platform" level features that you may want your app to opt in to. Essentially it's going beyond just providing tooling or a tool chain. It's also providing the runtime infrastructure (platform level.supporting services) and documentation to allow developers to deploy workloads into an environment and have a whole bunch of concerns handled for them by the platform that would otherwise need operational effort. For example opting into receiving traffic via a label in the docker compose file, compared to a team having to manually configure dns, or routing rules, SSL certificates, reverse proxies etc. P.s I could be wrong in my understanding, this is just what I am essentially doing at my company right now and thought it aligned with what the article was saying.

Good point. Big thanks.