Join Andrew Greene at Prodacity as he delves into the complexities and challenges of software delivery in the defense sector. In this insightful session, Greene emphasizes the paramount importance of providing practical, efficient, and secure software solutions to warfighters. He shares his journey from being a founding member of Space Camp and Platform One to his current role in Defense Unicorns, exploring innovative approaches to overcome obstacles in software deployment, especially in air-gapped and legacy environments. Discover the power of tools like Zarf and Big Bang, and learn how they simplify the software delivery process, ensuring quick, secure, and scalable solutions that meet the critical needs of defense operations.

Andrew Green (0:14)

Thanks for having me. I'm Andrew Greene, software developer for many years before I transitioned to being platform, being a founding member of Space Camp, Platform One, and now Defense Unicorns. 

‍

(00:24)

Before I begin, I want to take a minute and give a huge shout out to this guy. Like, can you imagine having mumbo jumbo tech stuff and turning into artwork? Like, round of applause. I love it. 

‍

(00:38)

Why are you here? Not today, not necessarily this week, but in defense. Why are we here? What are we trying to accomplish? What's our core why? What's our drive? What's our reason? I think it's to get capabilities in the hands of the warfighter. Nothing else matters. If it's not in production, it doesn't matter. No amount of agile ceremonies, good practices, software development principles - can solve the problem that the warfighter needs. If we spend 90% of the time on those problems, we failed. We have to get capabilities into the hands of the warfighters. 

‍

(1:10)

This is hard and this is the moment. I assume most of you're familiar with the challenges around software delivery and defense. Part of the reason we're here, this is a big coalition of people that are trying to solve these problems. So this is also the slide where if you guys need a 15-second power nap, like, now's your time to do this. But, like, what is this? This cycle of software delivery is covered with a bunch of different stages that we have to perform. The government finds a problem. They know they need to solve this mission, capability, need, and they have to do market research for it. They do that, then they have to buy the thing. There's all kinds of different licensing models, support models. How do we get these capabilities? How do these licenses scale? Where do they go? That's a challenge. We had a lot of conversations yesterday regarding acquisitions. We have to harden those capabilities, make sure that what I'm running in production is secure with a low footprint. I don't have an extra binary in there that has an extra vulnerability that can, like, compromise my system. We have to integrate it with my systems. I have data feeds. I have schemas that some engineering working group put together at some point. I have APIs. I get to that point, I still have to deploy it. Maybe I'm deploying into cloud. Maybe I'm on prem. Maybe I'm on my local machine. Maybe it's a sub. Maybe it's edge. I don't know. There's lots of different environments that we need to deploy to. 

‍

(02:23)

Then I'm ready, right? Nope, we have to accredit. Thousands of NIST 853 controls, for the most part, that we have to answer and satisfy, control mapping and responses. Then I can finally operate, but I have some bad news. I'm in operations and I ran into an issue, a vulnerability. I may have to go back to square one. I may have to pay for a new license for that new piece of software that has a vulnerability fixed that I didn't pay for that version. Jumbled way of saying that, but I think you guys get what I'm saying. But, so I may have to go through all these things. Hopefully not. But anything that we're delivering in defense is not fast. It's anything but fast. It takes often 18 months to deliver this stuff, right? Maybe that's just the accreditation cycle. It's too slow, it's not fast enough. Cost prohibits us from being scalable. What if I solve this problem over here and then I have to run over in this other environment? But oh no, like, my licensing fee is like, oh, I think I'm just going to run on a trial license for nine months. Yes, it has, I've been a part of things that that has happened. 

‍

(03:23)

Problem that Defense Unicorns is not working on, but is usability. One of my early jobs as a software developer was building a user-interface written in X/Motif, which is old rip wrap around C/Fortran stuff. The human-centered design for that was the 30 year expert said, "Oh, I need a button here that does this for me," and it produced completely non-usable software. And entering the force now and for the last decade are 18, 19-year-olds that have grown up with touchscreens and tablets and all these things that are easy. We can do this better. The software that we're producing right now for most of defense is anything but usable. I forgot to mention airgap. It's not as simple to just deploy in air gap. I actually love this meme with Boromir here because it highlights, like, it's a good analogy, right? Like, Frodo and Sam had to go through this long journey to get through there. They had an insider threat with Boromir. They had the guy that spoke one line to him, Legolas, and you have my bow, look it up. True story. He said one line to Frodo this whole time. The guy that you know is good at his job, but I don't really ever talk to him. What does he do here? Like, how does he help me? It's a challenging journey. We have to do all these things. 

‍

(04:33)

There's a lot of problems in airgap that I think everybody is very familiar with. One of the first use cases that we had with Zarf, which I'm going to show you guys in a bit, was working with the Navy, walked into a closed facility and they said, "All that we have is Windows NT. That's our operating system. Can you please do something with Windows NT?" "Sure, like, why not? Let's go for it." So we did, deployed Zarf using Windows NT, and that's the starting point. And I wish that was not the norm, but that's not the case. It's very, very common. But what if all this could be easy? I think it can be. I think we can get there. What if I had a capability that I could make portable, build it once and deploy it anywhere many times simply. What if I could deploy that capability regardless of my environment, cloud, on-prem, edge, submarines. What if that capability was built in such a way on top of the shoulders of giants where control mapping and responses were already done and I don't have to do this? And the top right is a picture of Big Bang. Duong Hang talked about it yesterday from Platform One. Big Bang is a massive great thing on the shoulders of giants, thousands of contributors to open source projects, thousands of releases, hundreds of thousands of commits only to illustrate that there are a lot of people working on a lot of these detailed problems and we can reuse that. We can benefit from that. With Zarf, we have Big Bang and package it up into a single component and make it easy to deploy. Same thing can be true for Software Factory. What if I had Software Factory with collaboration tools on day one, ready to go in any environment? I do my own class development and I do a classified development. It's okay. It's the same Software Factory that I'm deploying. What if I had SSO and IDM already built in ready to go? What if I had those tools and those CI/CD pipelines already in place? What if those pipelines have the guardrails in place such that the developers could focus on developing and not worry about what are the good CI/CD practices? All these things can be done and are done even if you're not experts in Kubernetes. How many people are experts in Kubernetes? Nobody. How many people know that their guy who goes to the classified environment is also an expert in Kubernetes? Nope. Exactly. Kubernetes is a great tool. Another talk for a good value proposition of Kubernetes. 

‍

(07:02)

But with Zarf you don't have to worry about the complexities of Kubernetes itself. With that, I'm going to switch over. Cool. So to begin with, I really just love to talk about a couple of things, a couple of topics here. It won't flow super well, but I think it'll get the point across. So the first thing I wanted to show you guys is my setup. What do I have going on? This is running on my local machine, and in fact, I'm going to kill internet. This is running on my local machine and I have no internet connection. I can't talk to anybody. The thing that I did previously to this was I had Docker k3d, which is just a lightweight Kubernetes distro, and the Zarf binary installed on my machine. And the first thing I did was run k3d cluster create. Takes about a minute. Didn't want to waste your guys' time with that minute. And then the next thing I did was Zarf init. Also takes about a minute. So setting the stage with zarf init, Zarf deploys into the cluster from that zarf init, and I have two components. The first is the Zarf agent. That's just the worker bee. It's the guy that does all the work inside the cluster to make sure that when I deploy packages, things are good to go. The second is the registry. The registry can be run outside of it, for any of the nerds in the room that want to talk about that, but has the registry so that I have everything I need self-contained and be able to deploy things easily. Ultimately, zarf init just primes a cluster so that I can deploy as many packages as I want into it. 

‍

(08:40)

This particular example, I've already built the package, and that's that Zarf package [Inaudible]. I want to show you guys the zarf config real quick. Actually, let me show you in the better window. I have the zarf config in here. Relatively straightforward, relatively simple. You don't have to worry about any of the details in here. But this is what it is, what exists, 25 lines or so. From that, I'd ran zarf package create producing this artifact, and then the next step is, I'm going to run zarf package deploy. I could add a few more flags here and make it automated, but instead I'm just going to walk you guys through that. 

‍

(09:16)

First thing, let me select the package. The second, do I want to deploy the package? Step three, just kidding, two steps. So in just a second here, we're going to see this capability deployed. This does a couple things for us. One, it gives us a little bit of nostalgia. You guys will see that in a second. Two, we're going to see DOS, a legacy system that is running in a modern architecture. And three, we're going to have a little bit of fun. So I'm running this and you can see these things. These are a few old games, right? This is not Mario Galaxy, the latest one, which is a pretty cool game. My wife loves the elephant. But it's a fun game. A bunch of different things like this. Just to show this is also not vaporware, I can actually interact with this, and at that first screen DOS, old legacy architecture. So again here just to show this is a real thing, I'm going to move in a second. Go right, go left. I think you can sprint in the old Mario and jump. So that's great. The cool thing about Zarf is no matter what package I have created, no matter how complex it is, it is easy to deploy because I just run zarf package deploy. That's it. There's a lot of other features they're going to show you guys in a second that Zarf can do, but I wanted to show a few other use cases. 

‍

(10:37)

Big Bang. Big Bang out of the box has roughly 1,000 configuration parameters, which are necessary for the value proposition of Big Bang itself. We want to use Big Bang to make it a configurable, easy to use, easy to consume thing, but still have a lot of that optionality in there. Defense Unicorns has found that 90% or so of those customers don't need all those parameters exposed, so we've simplified it down in a Zarf package, simplified it down so far that there's now three configuration parameters. There's a few more that we could add there if we needed to, but I need my domain and my certificates. I have this Zarf package in here that defines a lot of the nitty gritty details of Big Bang. Ultimately, most people don't have to worry about this. They need the package that actually deploys into the runtime environment. And so the same thing, once I build this package, I can do zarf package deploy and Big Bang is up and running in the cluster. 

‍

(11:35)

What ifs...doing the same thing for Software Factory. What if I could bring those Zarf packages together, the GitLabs, the collaboration tools, the runtimes, the Keycloaks, all of these things, package them up into a single bundle, and deploy in the same way. This is through UDS, which we haven't really released yet, so you're getting a spoiler or sneak peek, I suppose. But same thing, like, I have a complicated package where the people who know the things can work on this upstream, build it there, do everything they need, build that package once, and deploy it anywhere. Maybe I'm deploying it in a place to test it. Maybe I'm deploying it for production. It doesn't matter. I can deploy it anywhere. Holistically, we care about that entire software literally lifecycle to include some things like SBOM. 

‍

(12:16)

Couple years ago or a year ago, we had the memo on everything must be SBOM, right? And it's like, "oh my gosh, how like, cool, but how do I do this now? That's just another thing on my list." Zarf has SBOM built into it so I can have SBOM in any package that I create with Zarf. I can do zarf tools SBOM attest, and get an output file of - this is my SBOM list. Or you can look at a user interface, just one little nugget. Another thing in there that I can do that's...two things actually that are really cool. One, I can have a sign-in key, which is a option down here. Sign that key, prove that my package hasn't been modified between connected and disconnected environments. And then the other thing I can do when I need to upgrade a package, I can build differential packages, as well. So I build Big Bang and I get an updated version of some component. I don't want to rebuild the entire thing and re-carry that whole thing across airgap. I can build a differential package and deploy that on top of the things that I've already created. 

‍

(13:09)

On the shoulders of giants. I mentioned mapping and controls. This is all kudos to Platform One Big Bang, OSCAL components. OSCAL is a machine readable language, should have control mapping and responses. So inside OSCAL components on Big Bang, we have responses already in place for this. And we've had, you know, the cyber guy look at this stuff. 70% of your controls are already satisfied. I as a non-cyber person in defense really like to look at that as, like, cool, "I have to do 70% less of the things as an engineer." I understand Istio. I don't really want to spend a lot of time talking about how Istio satisfies these controls in NIST. That's the piece that's already done for us here. 

‍

(13:49)

And this is true for all of the components in Big Bang. And I know I opened this tab, but I did it twice in the other tab, so this one's old news. Okay, and then if we could switch back to the slides. And with the wall, oh, there it is. I still have a dad joke. Do you guys want to hear a dad joke?

‍

[Audience Member] Yeah.

‍

I was talking to my wife the other day. She was having a really hard time with work. And I said, "Babe, you just really got to embrace your problems in life." So she gave me a big hug. 

‍

(14:31)

I know this is short, sweet, and quick, but I think that's the gist of it. This is the value proposition. How can I build packages once, by the experts upstream, the people that know the Kubernetes, the people that know the mission, that know the domains, and be able to deploy those anywhere? How do we enable developers to develop or have the guardrails in place to develop appropriately for best practices without them having to worry about, oh gosh, like, "what linter am I going to configure today? How am I going to build this piece of software today?" What if it was just done? How do we make solutions scalable and cost effective instead of rebuilding the same thing in silo after silo after silo in defense? 

‍

(15:12)

Collaboration is one thing, but I've found and seen collaboration in defense is really, really hard to do, for good reasons and bad reasons. It's all in there. There's bureaucracy, there's classifications, there's sensitivities. Like, it's hard to do. But what if we can do things in a way that says, like, no, this is my common baseline. Let's solve this common baseline once, let everybody use it, and we can do this for mission capabilities. The most important thing, we can do this for secure runtimes like Big Bang. We can do this for software factories. We can do this for anything. Anything. We can...legacy applications that run on old legacy systems like NT or DOS. We can do this. We can package these up consistently. We can leverage the work of the open source industry and giants with obstacle mappings. NIST 853 control response and mappings, SBOMS already in place. Ultimately, this is geared towards making it easy for the capabilities to be leveraged by the warfighter. It's the only thing that matters, the whole reason for this. Defense Unicorns is holistically focused on that picture, and that's why I brought that first slide up. Zarf is a piece of it. There's a lot more to it and there's a lot more in industry that we can do and leverage together to make things better.

‍