Moving fast is great, but it doesn’t do you any good if you’re moving in the wrong direction.
Zack Kanter recently penned an article for TechCrunch where he made the case for startups to adopt a Serverless-first approach to increase software development velocity. “If the fastest startup in a given market is going to win” says Kanter, “then the most important thing is to maintain or increase development velocity over time.” He’s absolutely right. If a billion-dollar market exists, both other startups and incumbents in that market (or in adjacent markets) are going to compete for that market and velocity is going to play a large role in determining who wins, and going Serverless will increase long-term velocity.
But there’s another most important thing. As Martin Fowler wrote several years ago, “the biggest risk to any software effort is that you end up building something that isn’t useful. The earlier and more frequently you get working software in front of real users, the quicker you get feedback to find out how valuable it really is.” The best way for startups to build fast feedback loops, validate new ideas, avoid shipping things that aren’t useful, and to stay pointed in the right direction is to adopt Continuous Delivery.
Continuous Delivery (CD) is the capability to get any software change into production quickly, safely, and in a sustainable way. In practice, it is achieved by automating entire the process of taking a code change to production, which typically includes building the change, testing the change, deploying the change to pre-production environments for further integration testing, and then finally having an option to deploy the change to production environments. Most modern tools for automating the release process describe the automation as a pipeline that new software revisions flow through. As Fowler points out, companies that are able to maintain CD over time prioritize maintaining working delivery pipelines over new feature development.
The Continuous Delivery landscape is riddled with domain specific jargon that can be confusing for people who are approaching the space for the first time, so it’s worth taking the time to understand a few related concepts. Continuous Integration (CI) is the practice of merging code back from development branches into a shared branch often, which requires thorough and reliable tests as well as investment in build and test infrastructure so that tests can be run against any change to validate that the change can be safely merged. Some people describe CI as being upstream from CD in the development and release process (which is where the term CI/CD comes from), but given the above definitions, it makes more sense to view CI as the early part of the CD process because it plays a vital role in empowering an organization to ship any change. Continuous Deployment is the process of actually releasing every change to production. You need Continuous Delivery to Continuously Deploy, but the reverse is not true.
None of these ideas are new. Kent Beck coined the term Continuous Integration twenty years ago as part of the Extreme Programming movement, Timothy Fitz first blogged about Continuous Deployment in 2008, and Jez Humble and Dave Farley published the first book on Continuous Delivery in 2010. So why is CD a big deal for startups right now?
In their book Accelerate, Humble, Nicole Forsgren, and Gene Kim reveal their findings from several years of research about the way that teams ship software. Their flagship finding is that high performing teams achieve higher levels of throughput, stability, and quality without trading those attributes off against one another. More specifically, high performing teams deploy small batches of software changes to production frequently, which results in a lower percentage of changes failing, quicker resolution when changes do cause failures, and lower lead time to go from a customer making a feature request to shipping the requested feature. Perhaps most importantly, CD also lets these teams test the features that they’re shipping frequently so that they can validate them with customers and course correct if the features aren’t meeting a real customer need.
Despite these benefits, CD is still under practiced, particularly at small companies and startups. A recent study conducted by DigitalOcean found that 52.1% of respondents at companies with more 1000 employees reported using CD, but just 45.7% of respondents at companies with 6-25 people and 35.3% of respondents at companies with 1-5 people are using CD. If startups win by moving quickly in the right direction, there is no reason for any software startup to launch without embracing CD on day one. The process of manually shepherding a dozen changes to production likely costs more than the initial investment necessary to automate the release and adopt CD.
The number of tools available for customers to use to adopt CD and automate their release process is growing rapidly. For companies that deploy their infrastructure to Amazon Web Services, AWS CodePipeline lets customers automate their release process from hosted source code repositories like AWS CodeCommit or Github all the way to deployed services running on AWS EC2, ECS, Lambda, or other AWS environments. Google’s CloudBuild allows customers to create pipelines that use built-in integrations to deploy to Kubernetes Engine, App Engine, Cloud Functions, or other GCP environments. Microsoft’s Azure DevOps product includes Azure Pipelines, which can automate releases not only to Microsoft offerings like Azure VMs and Container Service, but also to other cloud providers. Elsewhere in the cloud ecosystem, products like Jenkins, Travis, CircleCI, and GitLab are all popular solutions for automating the release process. Microsoft’s $7.5B acquisition of Github has caused a fresh wave of excitement about the developer tools ecosystem from early-stage investors, which is fueling a new wave of exciting startups that are pushing the CD frontier forward while driving down costs.
Further, CD is eating the entire stack, which is opening up new potential benefits for adopters. The rise of Infrastructure as Code (IaC), provisioning resources up and down the entire software and hardware stack through software instead of a manual process, has made it possible to apply the principles of CD to the entire stack. Companies that leverage IaC offerings like HashiCorp’s Terraform or AWS CloudFormation can take advantage of the CD products listed above to deploy low-level compute and storage resources continuously in the same way as software. Need to spin up capacity in a new Virtual Private Cloud in a different region to add redundancy and reduce latency? Push a template change through your infrastructure pipeline and the new resources will be provisioned for you with the same kinds of testing and blast radius mitigation that you’re using to getting from a software pipeline.
Every startup is ultimately a factory that takes time and capital as an input and produces a product or service as an output. The company that wins in any given market is determined by who reaches product/market fit first. First-mover advantage only goes so far; battles are ultimately won by maximizing velocity and building tight feedback loops to stay pointed in the right direction, and Continuous Delivery one of the very best available tools to achieve that outcome.
Leave a Reply