Hey @Chris Vermeulen, great talk on Composable platforms 👍 - A few weeks ago I finished my Master Thesis which deals with a CD platform for the cloud-to-things computing continuum. A part of my work shows similarities towards your idea of composable platforms. The deployment targets are Kubernetes Clusters and developers are able to select and deploy "platform features" and their own applications via a simple catalog of Helm charts that is maintained by a platform operator team. You chose Terraform as an implementing technology (reasons are given in the talk). Howevery you only mention the actual interface for platform users only very briefly (e.g. here ). Do you have any demo repos or could you generally explain a little more around the interface that users are offered with in order to consume the composable platform building blocks? Is the idea just that they import the different Terraform "platform modules" they need? Are Terraform variables the main interface for configuration of the different components? In my master thesis the main interface for developers are the Helm value.yaml files, I would like to get know how this component interface would look like with our idea/concept.

Hey Daniel ! I’d love to hear more about your thesis ! Helm charts, especially for internally adapted services work really well in a Kubernetes based environment. What I have found is there is a bit of confusion when it comes to developers seeking to dig deeper into Cloud offerings such as Lambda, SQS or anything of that nature. Distributing through Terraform allows me to distribute everything from Kubernetes, it’s appliances, and all the way through to VPC and subnet configurations, and anything in between. What I like to do is see Kubernetes as just another *thing that needs to be deployed, the same as I see an EC2 instance. It becomes easier for me to reason about infrastructure that way. I can also protect the things that need protecting, and still allow developers the flexibility to experiment with whatever they need from the cloud or things they run on Kubernetes, and then abstract and augment once adoption becomes a bit higher. The primary interface is represented through distributed Terraform modules, configurable through variables or overrides. Each module is configurable on it’s own so developers can build “sub” environments, and also clone the module if the want to make bigger changes to the underlying module. I have got some examples here https://gitlab.com/kubernetes-catalog which you can have a look at. They are very much for demo, but they contain the primary idea behind the modules. Another benefit I’ve found when using Terraform as the primary interface, is the templating language behind the modules becomes a non-issue. Helm, Kustomize, or whichever else.

Thank you for the detailed answer Chris! The shared repos and resources help a lot to get deeper insights on how your concept works. It is nice to see that you basically are using the same fundamental concept: having an CM/IaC/Templating (call it whatevery you want) tool to abstract details and offer a interface that is usable by platform consumers.

I would absolutely be interested if it’s possible, otherwise I can wait for the final version to come out as well 🙂