Automation and ‘The Software Defined Delivery Manifesto’
Pulumi sponsored this podcast.
Software developers have been doing it all wrong — or maybe not, depending on whom you talk to. But at the very least, DevOps and CI/CD represent relatively new practices in computing that will continue to help organizations reap huge benefits as they mature during the coming year.
Meanwhile, one way to offer immediate and direct improvements to production pipelines is applying more of an engineering mindset to software development. More specifically, developers need to “engineer our delivery,” to develop and deliver better code, according to “The Software Defined Delivery Manifesto.”
This was the theme of a podcast Alex Williams, founder and editor-in-chief of The New Stack, recently hosted. On hand to discuss with Williams how software development and delivery can and should be transformed were Marc Holmes, chief sales and marketing officer of Pulumi, which offers tools to help streamline software development, and Rod Johnson, founder and CEO of Atomist and one of the authors of “The Software Defined Delivery Manifesto.”
The underlying theme of “The Software Defined Delivery Manifesto” is about “trying to capture this idea that we should really engineer our software delivery,” Johnson said. “We should do it just like any other engineering problem.”
Indeed, the idea to write the “Manifesto” originated from Johnson’s work at Atomist, while working with users and customers, and in a broader sense, a need to describe a “movement in the industry towards defining more things in code,” Johnson said. “So, that was one of the reasons that we reached out to our friends at Pulumi,” Johnson said.
Pulumi, Johnson said, has been developing tools that help developers move in the right direction of the cultural shift that needs to take place. Atomist, for example, has been applying the “Manifesto’s” concept to software delivery and embodying that into code, while Pulumi is more geared for infrastructure.
“So, really, the manifesto is trying to capture this idea that we should engineer our software delivery. Bring out engineering again and bring out these tools,” Johnson said. “And there was a feeling that, in a way, Pulumi and a bunch of other folks have been moving in that direction.”
In many ways, “developers are eating software and software is eating the world,” Johnson said. “So, when you’re stating something like that, and you’ve recognized that code is the best way to specify precise action,” the issue is ensuring that software is delivered in a manner where it’s only useful, Johnson said.
However, much work remains to be done. Organizations, despite having made improvements in CI/CD and DevOps, often “still lack some level of collaboration and that holds folks back,” Holmes said. “I think that we lack a common language for true collaboration and we can model a lot of it,” Holmes said. “Software-defined delivery is about the engineering of those solutions and that’s what takes DevOps and development and collaboration to the next level.”
Indeed, “there hasn’t been a lot of innovation in this space,” Johnson said. While there have been “tremendous innovations” in areas such as virtualization, containerization and Kubernetes, “it’s kind of that crucial ‘being in the middle’ of how software gets onto those platforms and is continuously delivered,” Johnson said.
“So, you know, partially, the software-defined delivery manifesto is kind of a call to action there,” Johnson said. “As an industry, we really need to lift our game and think about these problems of automating delivery. Think about it as bringing out the coolest skills.”
One way to do that is through automation and using tools that have existed that developers do not necessarily take advantage of. “We are the people who automate business requirements, but we tolerate doing a lot of things manually and in ad hoc error-prone way because we don’t necessarily bring that automation superpower [to the table],” Johnson said.
“We’ve got wonderful ways of describing behaviors, and instead, we use a mixture of YAML and Bash,” Johnson said, “It’s like we’re trying to do much of our daily work with one hand tied behind tour backs.”
In this Edition:
1:41: A general overview of Atomist and the Software Defined Delivery Manifesto.
11:49: Tell us about what is in this manifesto and why you decided to organize it this way?
19:01: How did YAML’s roots speak to previous time, and how did we evolve out of it?
22:37: “Delivery is a fundamental and strategic capability for every software team and organization.” Can you take us through a bit more of what you mean by that?
25:45: Why did you add “and organization” to that?
34:32: Where do you want to take this?