Continuous Delivery Foundation cdCon 2022, 24 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keynote: You're Good at CI, You're Good at CD, But Where's the Work Taking You? - Michael Stahnke

Description

For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/

Keynote: You're Good at CI, You're Good at CD, But Where's the Work Taking You? - Michael Stahnke, Vice President of Platform, CircleCI

We'll cover the complexity of change approaching modern application delivery and why the changes you intentionally make, and the ones that happen to you, require us to deeply understand desired behavior and reactions to the true initiator of all technology work -- change.

A

uh Yeah, so I'm michael stonke, I'm at circle ci, you can find me on the internet, uh where I will talk about hockey more than I'll talk about uh technology. Just to let you know, I'm a big hockey fan. So uh I want to start with this. I love automation for the last 10 years or more. I've been working in the automation business, specifically writing tools to help people automate things. Before that I was doing a bunch of automation. That's how I got to automation tools. I love automation.

A

The issue is, I love automation way more than I love testing, because testing sucks, and so I get kind of upset about it and I'm like I really like automating things except testing's hard, so that's kind of the prob, the problem that I have and I'm going to guess that I'm not alone, I'm going to guess.

A

There's people in here that are like automation's awesome doing the hard work to making sure everything's going to work out right on the other end is is less good, but we spent all this time building machines and building pipelines and building building building all this stuff, basically just to get code from one end to the other. As fast as we can right, we move it as fast as we can and we validate all of it.

A

We validate most of it. We validate some of it that goes through the system and why don't we validate all of it because testing's hard, so we really really invested into these pipelines testing's hard, all right, so you're getting the point.

A

So we attempt to lower the cost of being wrong because testing's so difficult and by lowering the cost of being wrong. We think about things like well. If it's broken, I can fix it really quickly and no it'll notice or if it's broken well I'll, send it to only one percent of all requests and therefore I'll know it in a very quick time before 100 of all requests get it cool.

A

So we have things like rapid releases and iterations and all this cool stuff- and we think great I've solved the problem that I hated to do testing, because I can just find out really quickly in safe ways cool.

A

But then you just keep thinking about it. Keep thinking about! I'm like yeah, let's go through an example, so let's say you're having an outage. How many people out here have been through part of an outage or an incident, or anything like that? Yeah yeah, they're, awesome, uh oh, no! So something's broken.

A

What's the very first thing you ask anytime something's broken what changed yeah? What changed? Do you know? What changed? Do you really because source code allegedly isn't that difficult to track? What changed right? You just have to go through the repo, the repo. Is there one repo, no most applications these days are hundreds thousands, many many repos. So what changed well source code, let's just say that that's actually pretty easy to track because source code, at least literally has a thing that happens every time a change happens, it's a commit and that's intentional change.

A

Any change that happens in source code is intentional because it was registered as a commit, even if it had a weird side effect. There was at least an intention to change something. Maybe it didn't change the thing you thought it was going to change, but it did change and you said: hey, I'm making a change, so we can validate that because we know a change is coming. We send it through our machinery that we built earlier and we have all of our things to reduce the cost being wrong. But then we have other issues.

A

What about change? That's unintentional happens all the time, so you can have things like new libraries, new containers, new images, different user behavior.

A

I have an elb, it's got five nodes, a bunch of user traffic comes on it, spins up ten new nodes, it runs docker poll it pulls latest latest is immutable. Tag doesn't point to the same image. I have a new version of my library. Now, oh crap, none of that was intentional. None of that was validated. It just happened.

A

The way we've been thinking about code for years was it's all these building blocks. It's all these pieces. It's all these things we put together and it's a tetris game and it's code. This is how we think about validation.

A

The issue is anymore with a modern application code. Is this small part of the overall thing we're delivering, which is user value, usually through an application, but that application is code running on somebody else's computers on somebody else's network using somebody else's api using a whole bunch of things you don't control, it's pretty difficult.

A

Did you validate all that? You know what happens when your payment processor decides? You no longer can process anybody who lives in russia. You didn't have anything to do with that. You didn't get it commit on that. How do you validate that?

A

How do you validate that? So the point here is: change comes at you from all angles, a lot of its code. The people in this room are all about optimizing code changes we're at cdcon, it's of course, what we're doing, but modern applications are beyond this. Is the code working? Is the code doing the stuff it's supposed to do because the application is so much more than the code? The complexity to deliver is enormous.

A

So code's cool, but it's a subject, a subset of change, and now it's about change, reaction and validation event, driven validation, stuff coming in from all over. How do we really change things it comes from all over and we're not ready for this we're not you can see the complexity of these systems all the time, we're not ready yet, but we're beyond code and into change we're into change. We want to automate confidence, confidence in change.

A

So if there's one thing, I'm going to leave you with, because this is a short talk, open up your brain a little bit and think about this just a little differently, and that change is the unit of work for how we're actually doing stuff with modern applications.

A

It is not just the code there's so much more than code out there. Thank you, I'm mike stonke. You can find me later or around the areas or on the internet or whatever.