Early in Docker’s history there was an partial uproar when Docker (the company) decided to patent, copyright, or otherwise encumber their APIs. I do not know if this is true or not but the chatter quickly subsided after the discussion lost momentum and for all intents Docker management never entered into the discussion.Yesterday evening, with the day’s events still fresh in my head, it finally occurred to me. The Docker APIs are going to be the thing! And a really big thing.Docker offers a number of tools and source. But let’s just consider Docker, Docker Machine and Docker Swarm; for the moment.Docker (proper) the daemon manages specific containersDocker (proper) the command line is an interface to the daemon through the APIs.Docker Machine provides access to a Docker Server through various providers like AWS, VMware, GCE, etc… through plug-in drivers.Docker Swarm provides cluster services and APIs by acting as a proxy to Docker Machine and Docker proper.And finally there is the user, user interface and the backend service provider.Phew!!!At this point all things are just a homogeneous Docker stack. What makes this powerful is that the APIs are generally consistent, well understood and popular.But now what would happen if you have a homegrown orchestration platform built on your own unikernel implementation like MirageOS or Ling? What would happen if you have your own PaaS with your own APIs that perform the same basic functionality of Docker?In the current model: user -> user interface -> docker swarm -> docker machine(s) -> docker server.But then there is my proposal: user -> user interface -> docker swarm -> docker machine(s) -> my docker shim -> my PaaS. And then if I’m running Docker Servers in my PaaS then I can proxy the commands: my PaaS -> Docker server.The benefit of this architecture, albeit early stage, Docker now becomes more about the APIs than the code. And so anyone can achieve true system composition from end to end.