ArticCon 2022 (continued)

There are additional benefits

On top of making it easier to write your terraform code, having a clearly defined interface where you transform your configuration allows for an abstraction layer.

Say for example using the same configuration to deploy networks in multiple cloud providers. You have a generic config that you transform and hand of to different implementations.

We can just leverage the interface we had before

// we have subnet data with no requirements
export interface SubnetData {}

// that is used to compose a SubnetDefinition
export type SubnetDefinition<T extends SubnetData> = PartialRecord<

// that is used to composed Network Data
export interface NetworkData<T> {
  subnets: SubnetDefinition<T>;

// that is used to compose Network Config
export type NetworkConfig<T, N extends NetworkData<T>> = Record<

Which seems pretty abstract; But we can use these as building blocks

Previous Next
Back to talks
1. Front Page
2. intro: before we begin
3. intro: my background
4. cloud config
5. cloud config: WebUI
6. cloud config: CLI
7. cloud config: IaC
8. cloud config: cognitive load
9. terraform: at a glance
10. terraform: HCL and usage
11. terraform: modules
12. So why not just use modules?
13. cdktf: enter language bindings
14. cdktf: compatible with terraform
15. schema: configuration
16. schema: networks
17. schema: firewalls
18. schema: peers
19. schema: enforcement
20. etl: for many reasons
21. etl: current and desired state
22. arguments: sidebar
23. etl: implementation
24. etl: additional types
25. etl: facilitating abstractions
26. abstraction: implementation details
27. abstraction: example
28. abstraction: but still concrete
29. types: but why
30. demo: full