Event Driven Infrastructure as Software With Lee Briggs | Current 2022 Managing an event-driven architecture usually means Operations (the people managing the infrastructure) and Developers (those consuming it) need to be on the same page. DevOps as a discipline is designed to solve that, but there are big gaps in the tooling that developers and operations use, keeping those pesky silos in place. What if we started treating the streaming infrastructure that forms the core of our applications as software too? How would that change and affect the culture, velocity and architecture we build? In this talk, we'll take a high-level look at how infrastructure management has evolved, examine some insights from both sides of the DevOps divide and look at how your organisation could look if you want to create an event-driven infrastructure that was also managed like software.

2. 2
$(whoami)
Solutions Engineer
@briggsl
jaxxstorm
www.leebriggs.co.uk

3. 3
www.leebriggs.co.uk

4. 4
DISCLAIMER

5. 5
Today’s Agenda
● Define Infrastructure as Code through a different lens
● Share a theory for why we’ve all accepted misery
● Show you a world where everything is a little different.

7. 7
Infrastructure

8. 8
Cloud

9. 9

10. 10
Declarative vs Imperative
Imperative Declarative
Control flow No control flow
You build the graph The graph is built for you
You make the decisions The system makes the decisions

11. 11
Shameless plug
https://leebriggs.co.uk/blog/2022/07/20/nobody-knows-what-declarative-is

12. 12
DAG (Directed Acyclic Graph)

13. 13
Configuration Languages

14. 14

15. 15
DSLs

17. 17
Comparisons

18. 18
Experiences
Authoring Experience
How it feels to describe the end
state of your infrastructure
● Language support
○ Configuration
○ DSL
○ Programming
Languages
● Abstractions
● Cloud provider support
● Language Server / IDE
support
Execution Experience
How it feels to get the
infrastructure you’ve defined
into your cloud provider
● Opinionated
○ Command line drive
○ Server side
execution
● Unopinionated

20. 20
DSL Based Authoring
● Single use
○ It can usually only be used for that one purpose
● Limited scope
○ Generally limited in its expressiveness
● Simple
○ Lower learning curve
● Custom abstractions
○ Abstractions are built specifically for the language
● Custom language server & IDE implementations
○ Support relies on owning organisation

21. 21
Configuration Language Based Authoring
● Very limited scope
○ Often requires a templating language on top
● Simple
○ Lower learning curve
● Rarely has language server implementations
● Limited syntax highlighting
○ Slower feedback loop
● Limited IDE support
○ Slower feedback loop

22. 22
Programming Language Based Authoring
● Expressive
○ Have the full language support at your disposal
● Language based abstractions
○ Abstractions based on how that language does them
● Full IDE support
○ Uses the language server implementation
● More complex
○ Steeper learning curve - but reusable!
● Type Systems
○ Faster feedback loop

24. 24
Command Line Driven Experience
● Control
○ You provide the credentials to the tool
● Grouped with CI/CD or workflow tool
○ You get to choose how it’s executed
● Opinionated
○ The tool generally guides you through a workflow
● Fast
○ You talk directly to the API
○ You get to run in parallel if you like

25. 25
Server Side Execution Experience
● Simplicity
○ The tool is executed in the context of your cloud provider
○ It handles credentials management for you
● Slow
○ You don’t get to add more resources to make it faster!
○ You’re competing with everyone else using the platform

27. 27
Scenario 1:
● I want to create some infrastructure without actually writing a
whole bunch of code
○ I want someone who knows a whole bunch about
infrastructure to write it for me, I just want to consume it

28. 28
Scenario 2:
● I want declarative infrastructure management with API
integrations
○ I want something to programmatically kick off my
infrastructure provisioning. Like maybe a message from a
Kafka queue!

30. 30
Integrating Infrastructure
● Many of the experiences we’ve described do not integrate well
with event driven architecture
○ DSLs/Configuration languages require wrappers to
consume messages
● CLI/Server side integrations restrict flexibility

31. 31
Infrastructure as Software

33. 33
Infrastructure as Software
● Abstractions
● Tests
● Control Flow
● Expression
Flexibility!

34. 34
https://www.pulumi.com/
@PulumiCorp
https://www.leebriggs.co.uk/
@briggsl