Continuous Delivery Foundation cdCon 2020, 20 Oct 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keynote: Safe at any Speed - How Progressive Delivery Eliminates Risk - Edith Harbaugh, LaunchDarkly

Description

Keynote Session - Safe at any Speed - How Progressive Delivery Eliminates Risk - Edith Harbaugh, LaunchDarkly

Continuous Delivery makes you go faster. Progressive Delivery helps you go faster, safer. Edith Harbaugh, CEO/co-founder of LaunchDarkly, the leading feature management platform, talks about how you can go as quick as you want, in a way that’s responsive, performant and compliant

Looking for something specific?
0:00 - Intro
2:05 - History (Waterfall)
8:13 - Continuous Delivery
9:14 - Progressive Delivery
10:02 - Two Core Ideas
11:05 - Use Cases
17:20 - Summary

SUBSCRIBE CDF CHANNEL ►►https://tinyurl.com/y4e4434n

ABOUT US
The Continuous Delivery Foundation seeks to improve the world’s capacity to deliver software with security and speed. Learn more at https://cd.foundation/

A

Welcome back to cdcon day 2 keynotes kicking off our keynotes. Today we have edith harbour speaking on progressive delivery. Edith is co-founder and ceo of launch darkly with her keynote on progressive delivery. Please welcome edith, harbour.

B

Hi, I'm here today to talk about progressive delivery, safe at any speed, progressive delivery means delivering software safely and reliably and at high velocity and for a lot of the history of software. These ideas have seemed at opposition.

B

There's been this idea that either you deliver something quickly with a lot of risk or you deliver something slowly but much more safely, and neither are quite right, I think, there's a middle ground where you can have the best of both worlds, where you can deliver value quickly, your customers and get that value them cost quickly.

B

So who am I I'm edith? Arba, I'm ceo and co-founder of launchdarkly launchdarkly is the leading feature management platform. We deliver trillions of features every day to customers like atlassian, ibm and intuit.

B

My background is, I got a bs in engineering at harvey, mudd college and then was an engineer, designing big content management systems and as part of that, I got several patents on deployment about how to move components between testing staging and production after several years. As an engineer I wanted to get closer to customers. So then I was a product manager. Most recently I was at tripit, which had millions of users so from this you could see that I'm really passionate about building software about the right patterns to build software.

B

uh This is me in front of the bay bridge in oakland, uh one of my favorite bridges in the world, so the tools for software are still pretty new. You know software as a field is about 60 years old.

B

When my great-grandfather was in college, he got a degree in civil engineering. uh This is a picture of him as his graduating class in 1905 from purdue.

B

He went on to become a bridge engineer, and this is one of the bridges he worked on. As a structural engineer,.

B

So there were patterns that they had been using at that point for thousands of thousands of years to build bridges.

B

You know you can look at the way he built a bridge as he got requirements uh in his case. He got the architect because he was a structural engineer. He does. uh He then put together the bridge people built the bridge, they verified that it worked, and then you had maintenance.

B

So it was a pretty set pattern. We would now call this a waterfall pattern. You know the idea was that once you build a bridge, it's going to last, for you know not just a year or decade, but hopefully hundreds of years as a reliable way to get people from point a to point b.

B

This is my grandfather, robert harbaugh, so he grew up in the 1930s. This is him as a young guy and he actually dropped out of high school. He dropped out of high school in 1942 to join the u.s army air corps. uh The air force did not exist back then, so when he was a training school and he he loved telling me the story by the way when he was a training school to be a pilot.

B

He was up in the air and you know he told me that you know he he kind of had a disastrous test flight. He survived it. You know, which in hindsight is pretty amazing and he landed and like not only was the landing terrible but like even on the ground. You know he just wasn't very good and the story that he still told was. uh You know his his flight instructor just like giving him a terrible hard time.

B

It was like harbaugh. You are an incredibly bad pilot.

B

Not only are you terrible in the air on the ground, you don't even know what you're doing you can't even get the plane to the you know to the to the terminal. It's just like driving a car on the ground, and my grandfather looked at the flight instructor. He said you know, I'm the youngest of five kids and I dropped out of high school, and I grew up in pittsburgh in the depression.

B

I have never driven a car. I don't know how that works.

B

So I guess you could take from this that my grandfather was a pretty much fly by the seat of the pants kind of guy. um He said he got then moved over to become a navigator and successfully. You know navigated his way through, even after never flying a car, never flying a plane. Ever um so after world war ii ended, my grandfather went to school on the gi bill and he got a degree in engineering. Also, his job then was that he would go to rural areas and help them with their first telephone system.

B

You know, there's still places that didn't really have a telephone system. Yet you know all the major towns and cities did, but there would be a little. uh You know little hamlet, that didn't have them, so his job was to go there and set it up.

B

It was hard, though, because you know there's no way to tell people without a telephone that you're coming there to set up their telephone, so he told the story of once. You know he showed up in a small town and I say town, it was just like a you know about a group of houses all together and usually somebody would volunteer to host him uh for a couple days while he needed to be there when he got to this town. You know nobody wanted to host him.

B

You know he was a stranger they're like well, we we don't really have room for you. You know, and you know sorry and my my grandfather said you know. That's you know, that's fine. I understand that um I'll go to the next town and set up the telephones there and I guess you'll have to wait.

B

I don't know how long for you to get telephones and then all of a sudden I was like. Well, you know what you know. I I do have a spare room. You could stay in, so he was a real problem solver. He he didn't wait for a set of requirements. He was pretty much like I I'm gonna, I'm gonna solve this stuff. As it comes up, you might say that he was more about agile or continuous delivery.

B

You know he was pretty much like I'm gonna go, try to do something, I'm going to test and learn I'm going to keep going until I figured it out.

B

So you know to go back to continuous this continuous cycle. I'm in this town, I don't have a place to stay. Maybe I could say I need a room and they'll give me a place or I'm in the air, I'm not sure how to fly.

B

uh You know and maybe I'll get through this very much a figured out kind of guy and then there's my mom. uh My mom is an amazing person. uh She was just elected to the ieee board of governors. um She is completely passionate about software and she writes standards for software. You know this is an actual standard that she works on and she is again very much kind of like a designer.

B

You know this idea that you can have a system in the world that makes everything work. So then, there's me, you know I like to think that there's both sides of like this idea that you can make everything fit in a rigid system and then there's also kind of this idea and software.

B

That is always a little bit of fly in the seat of your pants, like there's, always gonna, be a little bit of like I'm, not quite sure where I'm gonna go with this, and but I need to have the best of both worlds of some sort of discipline and some sort of idea where I'm going so the 80s really preach this gospel of waterfall.

B

You know, let's write down everything in these big huge books, and then software pops out five years later, where that really started to break down was that the world could change really quickly in five years.

B

uh Software that's designed for world five years ago, could be completely irrelevant today. So there was really this need for continuous delivery. uh Facebook netflix really popularized. This idea of, like you, know, hey instead of trying to plan in these five year or even three year planning cycles. Let's have a system where we can ship stuff.

B

Maybe every month, maybe every week, maybe every day and that allowed them to be a lot more responsive to their customers needs.

B

However, continuous delivery is pretty intimidating if you're in it, if you're in an enterprise, you know, if you're an enterprise, maybe you don't want to ship every day. Maybe you have customers that need training.

B

Maybe you have different regions where you have regulatory requirements.

B

Maybe you just need to get all your marketing materials lined up so that you can actually have a release, so continuous delivery was seen as a very scary thing and that a lot of business processes just aren't set up for this.

B

So from all this came progressive delivery.

B

So, to go back to the bridge metaphor, progressive delivery is the idea that you can roll stuff out when you want to. This is the reconstruction of the bay bridge. I talked before about how bridges would last for you know, decades or hundreds of years.

B

What happened in the bay bridge was that part of it collapsed as part of an earthquake.

B

uh They were trying to short up and they finally realized that they actually needed to build a new bridge. So you could see them trying to build the new bridge parallel with the old bridge.

B

While this was being built, they had to keep both bridges running. You can't just say: hey we're going to knock down a whole bridge and build a foot every night and everybody wait for the new bridge.

B

So this goes along with the idea of progressive delivery.

B

Adjusting the number of users able to see it are impacted by new features at a pace appropriate your business.

B

So what they did with the bay bridge is, they said: hey we're going to build this new bridge and when it's ready, we'll start putting people over there's a lot of the same things that you can apply to software.

B

If you're doing a major change to your software, for example, a radical change, the ui you might want to only put that out to a certain number of people.

B

Another idea is, if you are impacted by regulations, for example, if you're a financial institution and you're working in different countries in europe, you might have very different things that you could push out anytime to different regions.

B

Delegation is a step after that delegation is the idea that you can control by a business user who gets that code when this is all based on the fact that you can separate out deployment from release so with progressive delivery. What we're trying to do is say instead of having this big code base, that everybody sees all at once, we're going to carefully section up pieces of code and then chunk them out to the right person at the right time.

B

So, let's talk about some of those use cases. The ones closest to developers are around testing and production, and multi-state management, testing and production is really not as scary as it sounds.

B

You know, charity majors talks a lot about this and I'll give her a lot of credit. uh Cherry charity majors the founder of honeycomb. That's like everybody, has a testing server. Sometimes it's different than production testing in production means pushing all your code out and then very carefully turn it on for different people in different use cases with this ability to turn it off immediately. If something is not right, that is incredibly liberating because the old way of having to push stuff out to everybody is terrifying.

B

You know, I call that the push and pray release where you've pushed everything out and you're just crossing your fingers like have I tested everything and the answer usually is no, and even if you have tested everything, things are going to be pretty different in production.

B

uh It's very common to have back-end systems that are impossible to step out. It's pretty common to have integrations that there are no way to fully test. It's pretty common to have scalability that you might have thought you tested completely in an internal system, but just act completely different in the world real world.

B

So the freedom of testing and production is the confidence that I'm actually getting real production data and also that I could just stop it.

B

And then that gets the next thing, which is the kill switch by separating out testing by separating out testing in the real world carefully, you can turn off anything. That's not working.

B

Instead of having to roll a release in a hurry, you just stop the thing: that's not working! That sounds really fun.

B

You know it's! It's really fun to be able to say hey this thing's, not working, let's just stop it rather than I need to get. You know, 20 of my engineers, including the two that are on vacation, uh to figure out how to patch this and worry about whether or not the patch is going to break something else.

B

Along with that, a safety valve is really a good way to go about progressive delivery.

B

uh A safety valve is the ability to slowly ramp up traffic, to something I've been talking a lot about financial use cases, because this is again a really powerful use case for progressive delivery.

B

If you're worried about flooding some back back-end system, you can put slowly over time five percent ten percent, twenty percent, thirty percent of traffic to that back-end system. If you find that the system is not scaling, if there's something that's brittle, there's something that's breaking! You can just turn it back down to zero.

B

uh This is much more reliable and safe than putting a hundred percent of traffic to something and having it overwhelm something uh overwhelm a system. uh The the classic overwhelming is, if you have so many errors that your error logging system actually starts to go haywire and can bring everything down.

B

So a safety valve is a really nice way to relieve a lot of stress and also to test when you're ready for it a product could use dark launches. uh They could turn something that you can launch a feature completely off and then a product manager could turn it on for different people selectively.

B

uh These different people might be people who've, been volunt, volunteer voluntarily said like hey. I want this new feature.

B

uh They might be people who you're a little bit concerned about about whether the new experience will be something they like again. You can always turn it off if they don't like it.

B

A synchronized launch is something that marketing really craves uh if you've ever.

A

If you've ever.

B

Worked on something that has an east coast, release time at 8 am and you're on the west coast. What that usually means is your engineers are up at you know: 3 a.m or 4 a.m. To make sure the launch is going to go, live with progressive delivery, you could have actually deployed all that software a week or two ago, tested it and made sure that everything works, maybe even turn it on.

B

For a couple people in the press, uh you know a day or two ahead of time and then, when it's time to launch it's just a matter of just flipping the switch it's already there, you don't have to worry about deployment.

B

You know some of um customers who want starkly who are using this method say that sunlight releases are boring, and I love that you know that, instead of a release being a stressful thing of oh, my god, like does this code work, the release itself was boring. You already know that the code works. All you are have to do is sit back and enjoy all the you know the kudos and fun times. Are you saying how nice these new features are?

B

um We have a lot of customers who are in the into entertainment and streaming releases are who are using this when they're like this thing absolutely needs to be live at this time and we cannot risk it being down even sales and customer success can get involved in progressive delivery.

B

uh If you have something that you want a customer to try out uh a sales person instead of having to open a ticket and saying hey, can you turn on a trial, for you know so, and so in illinois uh a sales or customer success person with proper delegation, you can just turn them off and finally, there's a lot of fun things that data science can do uh with features properly segmented.

B

A data scientist person can examine how that feature is being used, get analytics around it and really understand its usage and again, this all comes back to encapsulated features nicely so that you could go through this progressive release where you can turn them on one by one and have controls over. Who has the ability to turn them on?

B

Who has the ability to turn them off, so the heart of this all is again deploying when you want release it when your customer is ready instead of having to mash them together and saying we have these huge releases with everything a customer might want, and if they don't like it, there's no way to control it carefully, segmenting out what people want and then delivering at the right time.

B

So this is the bay bridge it's completed. It is one of my favorite bridges, because I I mean I live in oakland and I think it really shows the power of progressive delivery.

B

So if you have only one take away from this, it's that it's not an either or with continuous delivery. It's not continuous delivery is dangerous or we go back to waterfall. It's that we can have both. We can have safe releases that help our customers and help us move quickly if you're interested in learning more go to our website at www.launchdarkly.com, and I hope you enjoy the rest of the conference thanks.