ArticCon 2022 (continued)

defining a configuration, aka schema

Rather than think about how the tools available to you expect their format defined, I prefer to think in terms of how it would be preferable to modify and manage. Less “how do I make this work” and more “how do I want this to work

When designing systems the day to day management is a crucial component that is often overlooked. Personally, I like to avoid vendor specific terms for general things, such as most networking constructs. 1

For example, when dealing with topographies all I care about are networks, subnets, and how to represent those. A lot of vendor specific nomenclature can be omitted.

So in typescript

   // name of our networks
   type Vpcs = 'infra' | 'management' | 'sales';
   // name of our subnets
   type Subnets = 'db' | 'app';

   // things that every subnet (in our networks) will have
   type Cidr = string;
   type Gateway = string;

   // a way to look up subnets
   type VpcAllocation = {
     subNets: Record<Subnets, { cidr: Cidr; gateway: Gateway }>;

   // and a way to look up vpcs
   type Topo = Record<Vpcs, VpcAllocation>;

  1. And there are certainly exceptions to this. ↩︎

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