We rely on context a lot as software engineers, passing state around so one function knows what the last did, and how it was impacted by the one before that, and on and on. Without passing around context, a lot of things would be much more difficult to build, or at least much more wordy. People need context too. Sure, we’re smarter than a function that only knows how to do one thing, and we can figure it out eventually, but it’s easier to learn a new tool or concept if someone gives us the historical context.
This is especially true as the cloud native space grows further into the mainstream. Abstractions are great, but they can create a hostile learning environment for anyone touching these tools for the first time, new and experienced engineers alike. You need to be given the historical context for these tools, to understand the technical hurdles and pain points that led to doing things the way we do now. In this talk, I’ll give you the historical context of infrastructure as code – what that means, how we got here, and why we need it.