Adam Such, Sonatype | DevOps Connect 2022

Today I want to talk about what defects can learn from Elon Musk. So I've had a long interest in the space industry and talk a bit about how the space industry can teach us a lot about what we're doing in software development and devops. So a little bit of background about me, I'm a Solutions architect.

It's on a type. So I've been helping people for over four years with that open source problems looking at open source contribution and the types of Open Source by pulling in and how we can make that better and get more productivity of the software writing using Open Source before that. I was a developer and a product manager.

So I've been in the thick of writing software and that's how I like why I like to help people try and get the best out of the software. They're writing. So my interest in space started quite a few years ago when I was at University, I was working within the sorry satellite Technology Center which in the UK are sorry university has associated with a commercial organization which developed satellites.

So got me interested in Satellite. It's and writing control systems for a quadrate helicopter. Got me interested in these things as it would and a little bit about what they were doing with satellites.

So satellites have traditionally been great big monolithic massive projects the likes of NASA building them and I'm not saying they're bad. They're brilliant projects Hubble is obviously done some amazing things, but they were massive and they did lots of things. That's just pick one example here of a weather telescope.

You can see it has here eight different functions and senses does a lot of different things is massive Wade multiple tons took a special launch vehicle to get into space and it was designed to cost a lot of money but run for many years and be very predictable across those years that it was designed to run. So it's a great project and useful as I say hubbled. It's really cool stuff and we're now launching things like the James web telescope, which is again a great big project kind of spare multiple decades, which is useful, but there is another approach and this is where sorry satellites came in where I got my interest in these cubes that so much smaller satellites.

Tiny little things standardized size much smaller in terms of way. And there was a few advantages to this firstly they use much cheaper components. They didn't use specialized components for space.

The standby standardized size meant they could be launched to space in much more standard launch vehicles. And they were much quicker to develop and they typically only did a few small functions. So instead of being a massive project with lots of functions, you send up multiple to each fulfilled a single function often just tests for special sensors and the like we could send up test and bring back down again.

So why am I talking about satellites? What's that relate to software development? We can see a pretty good correlation here from what's satellites been doing to what we're doing in software.

So we've gone from monolithic applications and software to microservices and containers all the few years ago. Now the satellite since were way ahead of us the good few years ahead in standardizing building these smaller kind of blocks of things. So these cubesats were wear head.

So it's very useful to see how they're doing those but also I mentioned some of those cheaper components if you think of the NASA type projects designed to run for decades, they use radioactive radiation proof components to ensure longevity and make sure those projects are going to run for a long time these cheaper cubesats you standard components from consumer grade equipment often so things that mobile phone standard memory batteries, and typically they add in one or two so they have a bit of redundancy. Um, but also these aren't designed for run to run us for as long because they don't have to have that longevity. There's so much cheaper we can send them up and if they last a year or two, what doing well and then if they expire we can send up more and we're still costing less than these critic projects.

So it's quite a different model. But this kind of an analogy here and software of these standardized components. We know longer rate individual software for every single function.

We need to feel someone's already written an SSL Library. Someone's already written cookie management Library. We don't start again on those things from right to each type.

We pull in those standardized components and they might not fit for fill our needs exactly every single time, but we can easily take what functionality is that add to it and create what we need will that happen to write that whole thing and that's those open source components coming from the internet and that's where I like to spend my time looking. But also mentioned that the longevity of these things it's also worth noting we talk about pets and cattle microservices, but they've been doing that also with satellites for a long time. If you think of these giant monolithic type projects like Hubble Space Telescope to spend up send up a mission in space shuttle to replace a mirror these much smaller telescopes.

They just deal with them. They will often test functions new senses these type of things and if they don't work, they'll do your bit if the components fail the deal bit and they can just stand up another one and that's important because they cost so much less than something like Hubble you can tend up many often hundreds and still not hit the price of some great big launch. And this is enabled some pretty amazing projects.

So starlink is aiming to send up 42,000 and satellites into space to give the world internet coverage globally covering the world with these other satellites. This is only possible because of this cost reduction standardized launches. They're sending up bulk launches of these styling satellites to fulfill the need for these massive coverage and 42,000 satellites.

Just put a context is 15 times and number of operational satellites in orbit today. So that's 15 times all of the satellites. The currently in space are going to be first single project.

So you can see the cost benefits of this and how it enables completely new projects. So talking of starlink, we have a link here to Elon Musk and what he's been doing obviously massively associated with space. Lots of people no space sex, but how did he get there?

So he wanted to do a project called Mars Oasis and originally this was around just getting some plants on Space seeing some things grow obviously had to get water there and the seeds and creating a million for these but he just wanted to start off the build some of the kind of buzz that was around the Moon missions and he Get that kind of buzzing around Mars. And this is slowly evolved into trying to get people on Mars. So that project is now fully fledged and there is a road map to get some people to Mars but this where it started but Elon didn't just set out abroad ambitious goal of getting to Mars.

He was looking at the technology and where the costs were of doing something like getting to Mars. So he was looking at squeezing the costs and linking back to Surrey satellite technology. He saw that the price of things like satellites were squeezing and going in different directions.

He actually invested he gave a 10% backing to the sorry satellite technology, but you know around 2004 you can see where he was looking at Cost savings and space in general obviously getting satellites certain places around bars and the moon were important to this Mission General to build a presence to get on the Hop to Mars. Um, but in that process of looking he saw that the prices were compressing elsewhere. But the prices of the Rockets and the launch Vehicles were very expensive.

And some companies were using decommissioned missiles and things like this for not vehicles, but obviously those are limited Supply not kind of a long-term thing and they were very much for these small launches. So he founded SpaceX in 2002 to try and yeah, bring down this cost and get this Mars mission running. So SpaceX has taken quite a new approach where I've been talking about the kind of monolith of those old projects that bassetted.

They're very good for learning a lot in the same way NASA took a very conservative approach to launching and all the other the governments and private contractors who are sending space missions up building Rockets. Everyone was taking a very conservative approach if rocket was to be destroyed they'll see that's massive failure. But SpaceX took a very different approach.

We call the devops approach feel fail fast, but quickly and fell fast kind of approach. And there was lots of data collected along the way and these failures so they weren't shy to try things out. Try these reusable Rockets things that would land on the pad and be relaunchable, but obviously they sound quite severe failures in the way.

And they didn't let that hold them back. They carried on they took a very different approach this devops approach. and collected a lot of data around what happened which support So they moved from this Dev a move fail fast and learn approach.

Into Ops which will come to a moment, but you can see the quick succession of different missions different Technologies, but they will learn very quickly learned from each other and got these reusable Rockets going stability technology very quickly. but then we move on to what they did with that technology and I would say key point in turning this around from Dev and move and failing fast to a much more standardized approach was when they started putting people on these Rockets because obviously then people's lives were on the line very important they went well, And this brings us to an interesting comparison of when we talk about security for software and I spend all day talking about security to lots of people. If you look up the different dictionary definition.

It's a state of being free from danger now, I don't think that actually describes very well what we do within software security actually safety describes it better. And obviously there are lots of safety standards around launching people into space. And actually I think safety is a better comparison to what we're trying to do that we're trying to protect from the danger at home.

We try and draw around our software reduce the risk whenever free there's always a new log for jail or something else coming along, but we can always protect from those things and make sure we're So with that in mind, let's look at some of the standards that not NASA has drawn up over many years for launching people into space because they're very interesting and take us on a bit of a journey through what we can learn in the software because as we've seen space has been quite far ahead of us in some ways. And technology and their kind of progression. So what can we take as lessons and build this into what we do?

So we're taking from this Belfast to production critical people's lives on the line type of approach. So the first thing pulling out some of these standards the first standard I've looked at in the crude missions. Is a safe and habitable environment.

Now this seems very obvious much like many standards. It starts with things that we would see as probably pretty obvious and wouldn't want to do like put in sharp things in a capsule that people are going to be sat in but equally we need to do similar thing for our developers as we're developing. Because things like look for shell look for Jay vulnerability.

I still come across people who are using that by accident. It's only when we run scans or look at tooling we find that they're actually using that very high CVSs score critical vulnerability. Tonight is probably documented but it's not obvious when you're downloading a version which versions are good.

Which versions are bad. Even more cryptic is many of these deliberate attacks. Now taking place on those ecosystems, especially npm pip.

I've seen happening recently people trying to catch people mistyping dependency names trying to install crypto mining software to CI systems through introduction of new packages or transitive dependencies of packages that people are using But also there's things like licensing which can capture out there's anti-commercial licenses which are trying to prevent you using software for commercial purposes, which can often catch out organizations developing software. So all these things much like our crew being safe in their capsule. We want to be aware of these as we work and develop I used to be a developer.

I know I wasn't aware of them. I wish I'd had the information to hand to know and make the right decisions. Um, the next one looking up is this probabilistic safety criteria?

So this kind of comes back to our definition of security and our definition of safety. We are never free from risk much like these crude missions are never free from risk. No one sends up a crude Mission expecting it to be a hundred percent safe.

They obviously reduce the risk as much as possible but it is space exploration is by its nature reaching the frontiers of kind of human endeavor. So we accept some risk along the way but we try and reduce it as much as possible much same as software we had no risk. We're probably never release anything.

We need to reduce those risks. So we need standardized rules and exception processes all these things so we can have a clear guideline of what we should and shouldn't be allowed. Partly, so we're not just decide to wrap the end and slowing down our releases.

But also so we can make the right decisions and be clear of what risk is entering our production environments. The next part is emergency systems. This is things like fire extinguishers oxygen.

Should there be a problem? This still seems very obvious in the case of space exploration being in a capsule. We would expect all these things to be there.

But a question I often get asked when talking about security and software is things like well, I have a wife why would I need to find issues as I develop software? My wife will protect me or I can report issues as the detected. I have plenty of ways to capture data about attacks.

Why would I need to fix it right at the beginning or friendship measures in? And it's much in the same way as we wouldn't allow the capsule to catch fire. We wouldn't because we have fire extinguishers.

We would have special protections for electronics and maybe dangerous gases to prevent fires. And there are five distinguishes are a backup much the same way our security. Our wax are security team are there to catch those exceptions not to prevent those things happening in the first place.

So it's kept these things early. The other thing we need to look at. Is us making mistakes.

So I as I say used to be a developer, I know I certainly Miss type some dependency names. I probably made plenty of other mistakes part of that was covered in character reviews. But also again we need this data and what we're using what is good.

What is bad with things like open source dependencies that can often be very hard to find so having the right Tools in place the right data behind. It ensures that were made aware of what we're doing in prevented from causing human error through just not knowing what causing any us to be able to resolve those issues quickly through knowing which versions are good or which other dependency which could introduce the same functionality I have available. Um, so on that same note, we need to be able to recover quickly.

So part of that is about knowing early on and picking that up in the right places. So having the right data as you develop as you go through Source control things like code reviews that data to hand and as you build the software itself, you can fail because zero days happen all the time between you developing the code and it getting to production. It could go bad.

So we need to be made aware throughout this process because you don't want to find out once it's in production you first find that as you through the process, And you can isolate and recover and the earlier you do that the easier it is to fix. But also we need to standardize language around what we have in our software is a very good to say having good data. but we also need to know which exact components what are software is made up of internal and external so we can track when we make a release or when we look back through our catalog of previous releases exactly what had which components in Now there's a good analogy here of obviously.

SpaceX we're sending up their brackets and reusing many of the components. So as soon as they layout those launches and Recovery, they were using engines and other components. Of course, they kept a record of which components have been refurbished how they've been refurbished by who how many times they had been launched and reused because that was critical data in part of this moving fast and testing because if there was a failure they wanted to know whether it was a failure of Bishop and the only had a certain lifetime much same way as software.

We need to know which releases contain which versions of which components. So when something I can look for Jay comes along we can track which versions have that in and fix that quickly. The last one is also we're all kind of familiar with the model of space missions will familiar pictures of the ground crew this Mission Control talking to the mission itself resolving any issues, but it's much like our security teams and developers.

If you imagine developers the crew and the capsule and the security team our mission control. I often speak to security teams who want to send out emails to the developers saying don't use this component. I've told you not use love for Jay and that isn't taking this kind of approach if you imagine when the crew are Have a catastrophic event.

They could be on the dark side of the moon have no communication back to Mission Control. They need to know and the standard sets this out a way of managing that then I've had lots of training. They will understand the process understand the systems know which buttons to press and have the right data to hand within the caption itself not reliable on the sugar truck is the same way with security.

We need to have someone who can set broad rules allow us to make the right decisions, but then trust us the right data to make the right decisions. So we need to treat security and development in this way security picking up the exceptions and the special cases and helping us through that. not setting Kind of, you know Mandate of you can do this or just looking right at the end so we can take the same approach as the space projects.

So That concludes my presentation. So it's like to leave you with a sort of we can take development moving fast developing quickly iterating developing new technology move that through to operations and taking it to a place where it's very safe just because we're doing too quickly doesn't need we need to compromise once we put it into production so you can wrap the whole thing in security and governance and look at across the whole ecosystem of what we're developing and make sure that remains good. That's the end of my talk.

Thank you very much for joining.