Event Driven Infrastructure as Software With Lee Briggs | Current 2022
0 likes432 views
The document discusses the concept of infrastructure as code, comparing declarative and imperative approaches, and analyzing various authoring experiences. It highlights the challenges of integrating infrastructure management with event-driven architecture and showcases different scenarios for infrastructure creation and automation. The presentation emphasizes the importance of abstractions, testing, and control flow in effective infrastructure management.
Event Driven Infrastructure as Software With Lee Briggs | Current 2022
- 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.
- 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
- 12. 12 DAG (Directed Acyclic Graph)
- 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
- 33. 33 Infrastructure as Software ● Abstractions ● Tests ● Control Flow ● Expression Flexibility!