With so much to figure out with AI, it makes sense to simplify with familiar development techniques, especially infrastructure as code and Python.
Most developers don’t use infrastructure as code (IaC), argues AWS tech lead Chris Munns. But to those top 10% to 15% of developers who do use modern development technologies such as IaC go the spoils. Even if the audience for IaC remains relatively small, interest in Python and artificial intelligence is accelerating adoption, as Pulumi CEO Joe Duffy notes in an interview. In enterprises that see tech as a competitive advantage, developers are digging deep into infrastructure. IaC is their tool of choice to do this successfully.
The new IT normal
In the days when developers had to request resources from IT, they were largely insulated from the worlds of databases, key-value stores, message queues, networking, and other hard-core “infrastructure” concerns. Developers owned application code, enterprise architects owned application infrastructure, and IT owned servers, configuration, and scale.
Then distributed computing–a wave that began with virtual machines, swelled with containers, then tidal-waved with Kubernetes–pushed developers into the deep end of cloud infrastructure. As trite as the phrases “shift left” and “you build it, you own it” have become, they reflect the much deeper responsibilities that the average developer carries today. Not only are developers writing applications, but they’re also doing everything else that was once in the land of infrastructure specialists.
Standing up compute resources and frameworks takes time and know-how, and it’s been a constant state of thrashing for both developers and the platform teams enabling them to find the right abstraction for exactly what that developer interface should be to cloud resources. JavaScript made the web browser programmable and set off a renaissance of web applications and mobile experiences that’s still underway. We’re on the cusp of a similar breakthrough in making cloud infrastructure truly programmable to developers.
The first waves of infrastructure as code
Infrastructure as code (IaC) is all the rage today, but it’s actually not new. The concept dates back more than 50 years and describes basic principles of automating infrastructure. Just as software-oriented architecture (SOA) evolved application architecture from monolithic applications into microservices patterns, IaC has been the slow-burn movement that is challenging what the base building blocks should be for how we think of cloud infrastructure.
IaC really got on the map in the 2010s, when Puppet, Chef, and Ansible introduced IaC methods for the configuration of virtual machines. Chef was well-loved for allowing developers to use programming languages like Ruby and for the reuse and sharing that came with being able to use the conventions of a familiar language.
During the next decade, the IaC movement entered a new era as the public cloud provider platforms matured, and Kubernetes became the de facto cloud operating model. HashiCorp’s Terraform became the IaC poster child, introducing new abstractions for the configuration of cloud resources and bringing a domain-specific language (DSL) called HashiCorp Configuration Language (HCL) designed to spare developers from lower-level cloud infrastructure plumbing. AWS CloudFormation and Azure Resource Management were two other top contenders in this wave of IaC.
Were domain-specific languages a wrong turn?
In that evolution to DSLs, Pulumi CEO Joe Duffy believes the IaC movement took a wrong turn. “I spent years in the programming language community,” he says, “and we had a saying that ‘every domain-specific language is destined to grow up to be an accidentally and poorly designed general-purpose programming language.’ ” The complexity of the cloud breaks DSLs, YAML, and markup languages.
Duffy says the general problem with DSLs is how they take developers and platform engineering teams away from managing cloud infrastructure with familiar programming language conventions. “Certainly if you look at IaC, it has been slowly recreating the wheel,” argues Duffy, “from language richness, abstraction and reuse, package managers, testing tools, static analysis, editors and their facilities like statement completion, interactive error checking and documentation, refactoring, and so much more. The trappings are a walled garden which actively prohibits developers from tapping into the capabilities of the cloud while simultaneously hobbling infrastructure team productivity.”
Using familiar languages with cloud infrastructure
“Treating developers with kid gloves when it comes to the cloud is a mistake I see all the time,” offers Duffy. “IaC is exciting because it turns the entire cloud into a programmable, composable set of building blocks that can be used to build richer and more powerful applications.” As an industry, we’ve moved beyond single machine application servers and single machine operating systems to distributed computing in the cloud, orchestrated by Kubernetes. But where DSL approaches to IaC are trying to mask that infrastructure complexity from developers, Pulumi is letting developers use the built-in conventions in the programming languages they already use as the primary interface to cloud.
“I feel strongly about standing on the shoulders of giants wherever we can,” stresses Duffy. “There are enough hard problems to solve out there. We don’t need to create artificial ones just for fun.”
Pulumi’s approach to IaC is multilanguage infrastructure, with support for Node.js (JavaScript, TypesScript), Python, Go, .Net (C#, F#, VB), and Java. The catalog of supported Pulumi providers spans more than 150 different infrastructure providers–and not just the big clouds, but companies like Cloudflare, Snowflake, MongoDB, Confluent, and many more.
“Using languages [developers] already know removes a huge mental hurdle from doing IaC,” says Duffy. “It turns the cloud resources into programmable building blocks that can be stitched together just like any other objects in their favorite language.” What’s the catch? As he continues, “The hard part then becomes learning about those specific building blocks, which arguably is the inherent ‘real complexity’ of the problem domain. Essentially, using a familiar language removes all of the accidental complexity, eliminates the fog, and lets folks just focus on solving real problems.”
A language-first approach to infrastructure
When we think about application infrastructure domains in mature languages, like Java with J2EE and the vast Java capabilities for handling concurrency and multithreaded code, developers have decades of hard-fought experience leveraging the primitives of their favored languages. This basic desire from developers and platform teams to use the language conventions they are already familiar with is especially strong with Python and AI, according to Duffy. Where DSLs have to bend and twist to deal with complexity, mature languages like Python solve these scale issues out of the box.
“The cloud is a giant supercomputer and AI is the biggest consumer of that supercomputer we have ever seen,” declares Duffy. “In this world, being able to program the supercomputer flexibly and deal with complexity that emerges at that scale is exactly why we created amazing programming languages to begin with.” Developers don’t really want to futz with infrastructure. “Although infrastructure powers all of these new AI experiences, it’s not what most AI engineers get out of bed in the morning thinking about,” Duffy argues. “Using Python turns it from a messy, grungy afterthought into a beautiful and elegantly programmable thing, just like any other software.”
This battle between DSLs versus general programming languages in the IaC space is not new. In 2020, I wrote about new models of declarative programming languages and how they contrasted to imperative languages in this IaC domain. What’s new in this IaC declarative versus general-purpose language battle is the AI gold rush. Python is the shovel that tens of millions of developers are using, and there’s a special incentive in this moment to be able to reason with infrastructure through the lens of your primary language.
