Companies worldwide and across many industries have felt the pressure to release faster, yet they struggle to do so safely and reliably that doesn’t compromise user trust. Many companies think there’s a dichotomy between whether you can move fast or increase value.
I think the move fast and break things got a bad rap. It’s horrifying to think, Hey, a developer that I’m not even talking to could suddenly blow up my entire customer base without all these gates,” said Edith Harbaugh, the CEO of LaunchDarkly, during a recent SD Times Live! tech talk. However, according to Harbaugh, releasing slower today could make the software more unsafe.
“If you’re doing the old software releases of 20 years ago where you do a release every year, every release has so much heft, weight, and gravity behind it,” said Harbaugh.
The releases are highly technical, requiring developers to check these different branches and features. Still, they are also risky from a business perspective because the value planned a year ago might not be relevant anymore. This could cause a significant release to flop when out in the field.
Both speed and value are mutually possible with the properly distributed architectures and guardrails that limit the blast radius.
One such method for safer deployments is canary deployments, limiting the blast radius from 100% of the user base and having it down to where it may affect 1% of the most progressive users.
The canaries are typically an engineering activity, and feature flags – a core part of this activity – help unlock value way up in the stack, according to DROdio, the CEO of Armory.
“You have to have the seatbelt on before you want to drive the Ferrari fast. The company has to have that psychological safety to flip that cost-benefit analysis in their heads that it is worth deploying out to that 1% of the population so you can deploy ten or 100x faster,” DROdio said.
Also, distributed architectures such as microservices, serverless, Docker, or Kubernetes limit the blast radius so that anyone change becomes much less risky.
Once an organization’s mindset is changed to validate changes, get more into production, and get actual usage in, releasing at cadences of up to even multiple times a day gets much less terrifying, according to Joe Duffy, the CEO of Pulumi.
Another benefit of a faster production cycle is that developers will get quick feedback on all the features they are working on and have more incentive to interact with that feature’s code constantly.
“I think of developers as artists. They have code, want to get their code out into the world, and want to learn from that code as quickly as possible so that they can have an iterative cycle,” DROdio said. “I don’t know that executives often understand that there’s anything more soul-sucking for a developer than having code sit on the shelf for a month or a quarter, and it makes the best developers not want to work at companies that have that lack of sophistication.”
