Dive into an enlightening discussion on enhancing the platform development experience in defense with Marc Ray, a Mission Manager at Defense Unicorns. In this engaging session titled "Hacking the Platform Developer Experience," Marc sheds light on the innovative strategies and tools employed by Defense Unicorns to streamline software delivery in highly secure systems. Learn how they focus on mission outcomes, leverage cutting-edge tools like Zarf, and handle complex integrations to deliver impactful solutions in challenging environments like SCIFs, boats, and air-gapped systems. Get insights into their approach to tackling security, compliance, and the ever-evolving challenges in software and infrastructure development within the defense sector.

Marc Ray (00:13)

Welcome to Hacking the Platform Developer Experience. One, really appreciate everybody coming to this talk. My name is Marc Ray. I'm a mission manager for Defense Unicorns. What that means is, day to day, I'm just hyper-focused on helping our customers, we tend to call them mission heroes, achieve the outcomes that they engaged us for. As part of today's talk, we're gonna give you a little insight to how we operate and how we look at hacking the platform developer experience. 

‍

(00:44)

And by the way, if you're ever giving a talk for the first time and they stick you in the ballroom, it's a little bit intimidating. So.

‍

[Audience Member] Woo!

‍

Marc Ray (00:53) 

Woo! All right. So, two, I do like these talks to be somewhat conversational. We are gonna get into some tactical information. I would be curious, anybody willing to share of, like, what you thought this talk was gonna be or what you wanted to get out of this talk? Anybody? Yes.

‍

[Audience Member] Something useful or something cool.

‍

(01:15)

You are gonna get both, my friend, out of this conversation. All right, let's see if this clicker thing works. So Defense Unicorns, other than cool logos, right, we make software delivery for the most secure systems in the world. Like, we're really good at taking complex applications and putting them in hard places. So a SCIF, a boat, an airplane, a small kit in the field, that's getting, you know, dirt all over it. We have tools, and we're gonna see that reflected throughout this conversation, where we're innovating on making that an easier process. So we have to ground ourselves, though, in some foundational truths of the kind of space that we operate in. And this is sort of regardless of whether you're in the DOD. My background is actually like kind of commercial, customer success, and working with large corporations who also have requirements and things that keep us grounded as a team. So one, it's a little bit captain obvious, but it kind of always has to be repeated. We have to be mission and outcome focused. 

‍

(02:23)

So in my past history running customer success teams, the one question I would always ask when there was a problem is like, "Well, what are they trying to achieve?" They engaged us to have a certain outcome. And it's a constant reminder because we should always be mission focused, we should always be outcome focused. And that means that outcome helps us determine the right decisions that we make. Platforms should accelerate innovation and mission impact. If the platform doesn't do that, it's just a big tool that is blocking you and in your way. 

‍

(02:50)

We can't have platforms for platform's sake. We can't have big systems for big systems' sake. We actually need them to do what they're supposed to do. The heavy lifting on the automation to allow us to focus on innovation. Security and compliance. Ever-evolving target. Doesn't matter where you do software development, it is an ever-moving target and it's a target that's empowered by both ever-changing standards and sometimes even how someone is feeling that day, right? So it is always a target and it always keeps us grounded in terms of we are never gonna have a baseline and be done. 

‍

(03:24)

That baseline is gonna consistently evolve and we'll talk about that more. I got this slide wrong. I wrote it and I put a developer's experience is as critical as a user's experience. Actually, everybody interacting with the platform, their experience is as important as the end user's experience, right? The old adage of garbage in, garbage out. If your experience is horrible using a platform, what are you building then? It surely can't be as good if you had a great experience with that platform. And software and infrastructure development are always in progress. Yes, it's agile, yes, whatever, but it is never done. 

‍

(04:01)

I've had similar conversations with a team as the woman from Kohl's who presented, CTO from Kohl's that said, "Hey, we have this app catalog and the guy's like, 'It's done.'" Similar experience at a company where, you know, we were looking at designing and doing our quarterly roadmap and they're like, "Oh, that's awesome. We're gonna release it and then we get to move on to cool things." And I'm like, "What? What are you talking about?" Like, that just enables us to actually deliver value. That in and of itself is nothing. Like, it doesn't actually achieve an outcome. So we have to stay grounded in these truths. Then we kind of have to stay grounded in them while dealing with, like, a dancing thumb drive that's kind of in our face like, "Ah, great, now we gotta do all of this and then deliver it into air gap. Put it on a submarine, put it in a SCIF." 

‍

(04:51)

I had somebody, a gentleman I was speaking to yesterday, he's like, "Can you help with EMP guarded data centers?" So I guess like electromagnetic pulse. And I was like, "Yes, we can," 'cause some of what we're gonna show you will work anywhere. But this really adds a lot of complexity to the equation. Traditionally, software development, we could build pipelines, we could do all this great thing, and then we could automate the deployment like, poof, go live, poof, go live. Well, you can't do that when a thumb drive or there's an, you know, thumb drive, CD. I once saw that some airplanes still use floppy discs for firmware [Inaudible], which is, just don't fly in those airplanes. 

‍

(05:33)

Alright, so now that we have our foundational truths out of the way, we have to run towards the hard problems. At Defense Unicorns, we do this in multiple ways. One, we look for ways to innovate. We look at really hard problems. You'll see that in the next slide with a tool called Zarf that helps basically alleviate the pain of that air gap deployment. We do that by empowering the teams to run towards hard problems two days a month. We empower our teams with dash days. Where we give them two days a month to say, "Attack something." That something could be software, that something could be an internal process, and that something could be also just, you know, an idea that somebody has that they want to, you know, get started and incubate within the company. 

‍

(06:21)

Speaker trick, don't drink Diet Coke right before you present . 

‍

(06:26)

But by empowering that culture and having that team, it allows you to have innovation. True, authentic innovation. Some of the capabilities we're going to show you that we've built as a company, and by the way, it's not selling, I know that's one of the tenets here. They're open source. You can go on GitHub, except for one. Don't tell anybody at Rise8 about that one. 

‍

(06:45)

But, if you empower people and you give them true innovation, you can truly make a difference. But it's got to be authentic. You've got to give them the tools and, frankly, you've got to get out of their way. So let's take a look at one way that we're looking at hacking the platform experience. So one of these ways is a tool called Zarf. Tool, solution. Can use the term inter-mixed. Has anybody ever heard of Zarf? Does anybody think they know what Zarf does? Alright. Go to market people, record that. We gotta get that. Zarf is a tool that helps attack the problem of going from a development environment, where you might be completely connected, all the way to air gap, where you might be completely disconnected. We like to say it helps to save people from dependency hell. I like to think it makes developers and admins or SREs or other people who are on the other end of the environment, friends again. And it saves people from the tyranny of runbooks. 

‍

(07:49)

So what Zarf does, is allow you to take an application, you can develop it high side, or excuse me, you can develop it in a connected environment, use all the wonderful tools, have access to all the wonderful open source tools, have access to your own internal tooling, use collaboration tools like Mattermost or chat or get in person and build these amazing applications. But then usually what happens is once you do that, you then have to package it up and it can become a grinding halt when it goes to deployment. And that is not actually then delivering value or capabilities to the warfighter. So with Zarf, what you can do is declaratively say, "Hey, my application needs all of these different components. It needs docker images, it needs source codes, it needs artifacts, it needs binaries, it needs all these tools," and Zarf will then package that up into one file that you can then stick on that thumb drive and bring into an air-gapped environment. Bring it to a submarine, put it in space. It doesn't matter. Everything you need for that application to be faithfully reproduced and run consistently with the way that you designed it will be brought to that environment. It's also designed and written, it's a little low level, but it's written on Go, so it's extremely portable. Put Zarf on the thumb drive, two commands, click Go, and then Zarf will automatically exstantiate that application into the environment. 

‍

(09:18)

Now, what happens if you don't have Kubernetes or what happens if the person there doesn't really know Kubernetes? Zarf's got you covered. Because we realize that the experience can't just end with technologists who are experts here and always assume that there are experts on the other end, right? Zarf can either, A, exstantiate a Kubernetes environment. As long as there's hardware there, it'll spin up Kubernetes and deploy the application. It can also then deploy it into an existing Kubernetes environment. And it does this through some pretty cool stuff that, I'm gonna throw some buzzwords out because I've never been a Kubernetes developer, but for Kubernetes folks, what it does is it'll do some tricks like, one, spin up a Git server. It'll spin up a registry for images. It basically makes the environment that it's going into think it has all of the resources it needs to truly exstantiate that application. And there's a whole lot more it can do. But one thing it can do is reduce the overhead and the load of trying to go from a highly connected environment to a disconnected environment. And it's completely open source and available for people to use. 

‍

(10:30)

Give contributions back, give us ideas. The Zarf we have today was not the Zarf from like a year ago. And the Zarf we have tomorrow will not be the Zarf that we have today. So we're open to feedback. And you can even do some of these feedback loops even within your own organizations. Alright, so that's Zarf. And I'll try to leave a little bit of time if anybody has any questions. If not, find someone with a Doug shirt and we're happy to talk about how you can utilize these. 

‍

(10:58)

Alright, another area which is always extremely fun to deal with is security and compliance. Amazing buzzwords. I do think somewhere out there there must be an association of lawyers who just simply are funded to make security and compliance the top of everybody's mind so that they can stay in business. This is a problem that exists everywhere. I'm sure, potentially in the DOD, it might be worse than corporate America, but there's nothing more fulfilling in a job or life than getting a spreadsheet that asks you questions as if you're buying IBM software circa 1994. Like, oh, "please tell me about the CPU requirements that you have in this." And you're like, "I don't know. Can you go ask Amazon? Like, why am I answering these questions?" Or, "Here, we need to, you know, send you this test in which, hey, if you click this a thousand times and you come over here and you do this," like, can you please remediate that bug?" We want to get ahead of that. 

‍

(11:53)

There are two ways of getting ahead of that. One, good coding practices. Two, giving people all the information they need upfront so that they almost don't want to ask you questions because you're gonna look so good about how all the information that you're providing, and you're also doing it at such a rapid pace, that it helps to alleviate the process of determining the different, you know, requirements that you have, whether that's going for an ATO or whether that in, you know, corporate world was going for basically the equivalent of an ATO at like a Fortune 500. 

‍

(12:25)

So this is the only one that is coming soon. It does actually exist. It will be open source, but we will be releasing this, in which case, we're going to release pipelines that allow you to, for any application, run them through different security checks so that on the back end of it, you have everything you need in terms of requirements. It meets 70-ish percent of NIST controls. It has, whoops, sorry, my mic's falling out, SBOM creation. It allows your team to spend more time innovating and less time, like, documenting. Imagine like trying to be a security expert, a developer expert, a UI expert, everything. Like, we expect developers, you know, oh, it's code, so they know everything. Well, actually it's hard. They can't. And so with secure pipelines, you'll be able to easily just go through and have your application go along each of the gates that are necessary. So for instance, making sure no secrets are in the application or trimming it down to only the components necessary to run that application. 

‍

(13:24)

Now, a lot of these are not new concepts, but being able to apply them in a much more rapid fashion and combining it with a deployment tool on the backend and also combining it with a portable production runtime that also gives you a baseline for security controls, again, accelerates that pulse of development and innovation getting out to the warfighter. The last sort of capability that we're gonna talk about where we are, again, how we're hacking the platform experience, is you can use Zarf to package up your applications, you secure it through great pipelines, but then it comes time for integration. And integration can be tough. With our tool Pepper, we're trying to not only attack the integration but also reduce the tribal knowledge for applications. Anybody here know what Flock Of Seagulls actually is? Alright, this metaphor is gone. I once had a group say...yes, thank you, an '80s band, right? It's old, it's dated. Their hair is crazy. It doesn't work anymore for two reasons. One, I had a group of people, a little bit younger than me, think it was seagulls pooping on the idea, which I'm not against using that metaphor, however, not exactly what I was going for. And two, Flock Of Seagulls is now making a comeback, which means if they become relevant, this metaphor is completely gone. But tribal knowledge is a killer in any organization, anywhere you work, right? It's a huge risk and it's a killer to productivity. 

‍

(15:02)

So with Pepper, what we're looking to do is allow you to declaratively, in TypeScript, not YAML, I think one of the buzzwords we use is save people from the tyranny of YAML, declare how your application can be consumed when it's deployed in an environment. It's also written on top of Node, which means you can add logic to that integration, right? No longer do you just say, "Hey, here's my YAML file and here's how my application should be used." You can now use Pepper to actually add logic so when an application comes in and says, "Hey, I need to," as simple as like, "Hey, label my application as needing Keycloak." Keycloak sees that application come in, the Pepper module runs, and it does all the work necessary to integrate that application and also to maybe not integrate that application. Maybe that application wasn't configured in the right way or it was missing certain controls. There's a lot you can do with Pepper, and it does it in a way that is human readable, so that now you can have folks who may not be Kubernetes experts on the backend understand what is happening during that integration point. Pepper can also be used for validation and keeping your system in a correct state. Again, it's open source. And similar to some of the other capabilities that we're developing, it's there to make the lives easier of developers and admins and folks so, again, you can keep up that pulse of innovation in that throughput going out to the field. Alright. 

‍

(16:33)

So wish I had a better, compelling story. No. I think one way that we could look at, you know, teasing these, looking at the full, sort of, platform experience is if you think about applications, especially with AI and especially with the way that we are looking at providing better innovation within the DOD space, there are gonna be times when an application is gonna go to production for the first time, and that application needs to be developed in a way that it can be as agile as possible, utilizing the best tools, and many times, that's going be in a semi-connected or connected environment. We're then going to need to make sure that application is secure, right? And getting those applications into the hands of the warfighter is critically important because you might have an application that's needed now. You might have something that's needed to help process AI for retrieval, augmented generation of maybe, you know, infield sort of, excuse me, in the field, for processing intelligence in real time. And you might need that ability for that application to be used in 10 different places and they might have 10 different requirements. So in order to do that, you have to make sure that we can be hyper-responsive. First we need to develop it, we need to secure it, we need to get it approved, and then we need to deploy it. And putting it on a thumb drive and knowing that in those 10 environments, that that application can be reproduced and deployed faithfully and potentially, similar to many tools that we deploy, when it's in the field, it might need to be reconfigured, right? You might be using two different languages or processing different intelligence data in different places and you don't want to wait for that need to go back to the developer and then come back through the complete pipeline. Utilizing a tool like Zarf, you can actually deploy all the resources they need into the field faithfully so that, in real time, they could potentially reconfigure the application. 

‍

(18:27)

And last, we never stop, right? We gotta power that innovation engine. You know, AI is definitely something that, you know, we're exploring and I know other companies are exploring to help enhance and, again, drive the throughput of that innovation along the platform experience. Something that I'm really excited about, relatively new to Defense Unicorns, but I love how we're also buying down platform technical debt and complexity, right? We're not just looking at something and going, "Wow, there's this cool platform, it works." We're saying, "No, like yeah, it works, it's great. It worked great for the time that it was developed, but we can do better. We can reduce the footprint. We can reduce the complexity. We can reduce the amount of work it takes to deploy it because that's better for the war fighter." And last, platforms need to be extensible or they're just big tools, right? It depends on, you know, different teams are going to want different tools or capabilities. I had somebody I was speaking to yesterday about the pipelines that we're working on deploying and said, "Well, will it work for firmware?" And I'm like, "Don't know. That's an interesting concept." But if we hard code the platform too much, no, it won't because we won't be able to plug in different tools and capabilities to solve for that particular use case. And last is to just get started today. We all work in different environments, we work with different constraints. But if you start today and you try to work around those constraints, you can find out that many times you can innovate very fast and quicker than if you just waited for the permission to do so.

‍