Has conventional lean-startup wisdom gone too far?
Examining it from the DevOps perspective, this article will propose new goals for companies starting today and offer practical guidelines for building good automation and infrastructure.
By following the rules here, startups will be able to move faster than ever before.
Where Lean Startups Go Wrong
Conventional startup wisdom from “The Lean Startup” states that you should build a minimum viable product (MVP) to learn what customers want and achieve product/market fit as quickly as possible.
A true minimum viable product is expected to be embarrassingly low quality or not even real software (e.g., a video showing how the software might function). This idea has revolutionized startups and drastically cut down on wasteful development.
Risk of Failure
When people take things too far and build such a minimal product, the problem increases the risk of failure. This can occur when not enough upfront effort is put into optimizing development cycle time by automating manual tasks and using scalable infrastructure.
For Starcraft fans, this is like only building zerglings (the weakest but cheapest unit) and failing to invest in more advanced technology. It will be faster at first but quickly leave you at a disadvantage.
Advances in DevOps
When The Lean Startup was first published in 2011, it made sense not to include much automation in an MVP because it was liable to be a net slow-down on the path to customer traction.
For startups launching today, the equation has changed. The overhead of using the latest DevOps technology from day one is low enough that it is more likely to reduce the risk of hitting the end of your runway.
In 2022, we need a new paradigm for moving fast: minimum functionality with robust automation and infrastructure.
9 Best DevOps Rules for Startups
You can do a lot with DevOps, and it’s easy to go down a rabbit hole. At the same time, it is also easy to kick the can down the road to stay lean.
Striking the right balance is difficult, but the following goals are a good place to start and should be possible to achieve with a modest amount of effort for a new company:
- Automate frequent manual tasks.
- Optimize for the shortest development cycle time.
- Minimize deployment effort for changes to the application.
- Avoid any lag or batching of changes between development and production.
- Mitigate risks that could require major refactoring before customer traction.
- Avoid architecture that causes productivity loss when adding new developers.
- Don’t expose yourself to security risks that could take down the company.
These goals are abstract, but you can achieve them with the nine rules.
1. Use infrastructure-as-code
The idea behind infrastructure-as-code is to use a system like Terraform to write all of your infrastructure configurations in a declarative language. This allows you to use version control and enjoy its benefits, including code review, change tracking, etc.
However, the biggest advantage of infrastructure-as-code for a startup is that it allows you to rebuild your entire infrastructure in just a few minutes. Established companies don’t often need to do this, but it is common early on to want to blow away and restart everything or stand up a replica of your environment for testing.
Developing your infrastructure with Terraform is more work than manually setting everything up in AWS or another cloud provider, but this effort will pay for itself quickly as changes that would normally become cumbersome and error-prone remain straightforward.
2. Go serverless
There was no way to run a service without managing servers until recently. AWS Lambda changed that. It is now possible to deploy a service purely with code and delegate infrastructure management to the cloud provider.
Serverless technology saves a tremendous hassle by setting up scaling configurations and updating systems. It also provides good security and reliability out of the box.
Despite its advantages, serverless technology is still somewhat nascent and may be challenging to set up for a complex application with Terraform. Still, you should strongly consider going serverless for new applications, as the technology will also improve over time.
In addition to API endpoints, you should seriously consider ditching servers for landing pages and content management. Technologies like Gatsby and Netlify automatically scale to large amounts of traffic without managing any infrastructure.
3. Use containers
In cases where you do need to manage servers, Docker has made it easier than ever to rapidly build and update systems. Docker lets you stand up complex infrastructure quickly and rebuild containers in seconds when making changes.
AWS recently announced that you can now use custom Docker images with Lambda, which allows you to go serverless.
4. Write at least one unit, integration, and end-to-end test
Automated testing is often the first thing on the chopping block when building an MVP. This is not necessarily bad since writing tests takes time, and customers don’t buy tests.
However, developers need to be able to write tests with a new product. This can immediately save time by enabling developers to write tests when doing so is faster than repeated manual runs, which is only possible if the testing infrastructure is in place.
If you don’t have the testing infrastructure, you also run the risk of building untestable software, creating major problems down the line.
Finally, and most importantly, having zero tests will prevent you from truly automating deployment.
Start by implementing at least one test from each layer of the testing pyramid: unit, integration, and end-to-end. This shouldn’t be too difficult and enables developers to make better cost/benefit decisions about testing that progressively speed up future iterations.
5. Use a CI/CD system for deployment
Most software starts with manual deployment. Setting up a continuous integration/continuous deployment (CI/CD) system takes some work, and a single deployment may only take a few minutes.
However, manual deployment time quickly adds up, and it is time that developers could spend building new features.
Rather than wasting this time, bite the bullet and set up CI/CD right away. (This does not apply to infrastructure-as-code, where CI/CD is probably too difficult with current technology.)
CI/CD will also expose potential problems with architecture or build stability, which is harder to fix the longer you wait.
6. Develop locally
With recent advancements in systems like LocalStack, it is now possible to run fairly complex architecture locally, including most of the services provided by AWS.
There are several benefits to local development:
- Resource isolation: Local development guarantees that developers are not stepping on each other’s toes with shared resources. This further reduces the risk of nondeterministic application behavior and flaky tests caused by interference between application instances.
- Easier infrastructure changes: If the infrastructure runs locally, developers have full permission to make changes and can more efficiently.
- Easier onboarding: Running systems locally eliminates the need to configure cloud infrastructure for each new developer, making onboarding faster.
- Secure by default: You should already separate production and testing environments and follow other security practices, but local development provides security by default because you are not accessing the cloud.
While local development can be helpful, it has some limitations. You may still need a cloud development environment for certain situations like processing large data sets or testing features not accurately simulated by LocalStack, but it’s worth investing in a local environment that most developers can use for day-to-day work.
7. Use automated error monitoring and notification
MVPs have lots of errors, and errors drive away customers. It is best to discover errors before customers do (or worse, investors).
Early teams often check their analytic dashboards regularly to make sure everything looks good, but this wastes time. Instead, developers should rely on error monitoring to notify them if something requires their attention.
The following checks are relatively easy to set up and make a good starting point:
- Resource alarms using a system like CloudWatch
- Front-end and back-end exception tracking with a system like NewRelic.
- External service ping using something like NewRelic
- Consolidate notifications into a system like PagerDuty that efficiently notifies the right person without spamming everyone when there is an incident.
8. Isolate production
When you get your first customers, the thought of making production data available for development is alluring. Real data is richer, and using it lets you see how your features will look to customers.
However, developing in production risks catastrophic mistakes or security incidents. Real data is also unstable and may change or go away, so using it for testing prevents automation.
Invest in a good test data set (which may replicate anonymized information from production) and fully cut off development from production to avoid these pitfalls.
9. Follow good security practices
Security is probably the last thing on anyone’s mind when building an MVP. Of all the causes of startup death, data leaks and ransomware are probably not high on the list. But with the ease of implementing decent security practices, why take the risk?
Scrambling to clean up bad practices later is also far more work than keeping things clean from the start.
Here are some basic security practices you can follow without much effort:
- Use two-factor authentication with all services that offer it.
- Use a password manager and randomly generated passwords for everything that requires a password. Opt for systems like AWS Identity and Access Management (IAM) that provide time-limited credentials rather than using basic password authentication.
- Encrypt everything. This includes full disk encryption for all local systems, database encryption, and SSL/TLS or SSH for all connections. Encryption is just a box to check when configuring these services with negligible performance impact.
- Don’t allow any direct network access to systems other than what is strictly necessary.
Is This Really Worthwhile?
The rules outlined above are possible to achieve with modest effort. A seasoned DevOps engineer would probably take a few weeks to implement these practices for a simple application.
For startups that don’t have access to this type of person, it may take a regular engineer several weeks to learn and implement these guidelines.
Though several weeks isn’t a huge amount of time, it is not free. It is certainly possible for a startup to succeed without following any of the practices outlined here, and many of the risks are unlikely to materialize.
After all, startups like Facebook got by without the latest technology.
Is It Worth Investing in DevOps?
The first problem with this argument is that the trail of dead bodies is harder to see than the successes. Slow development cycles and technical debt have probably killed many companies, but we rarely see post mortems on failures despite being much more common.
It is also important to consider The Lean startup's motivation and build a minimum viable product.
You should avoid overbuilding quality because it will be thrown away if customers don’t want the MVP. If it took several weeks to implement DevOps for each product, doing so might be a bad idea.
DevOps Eliminates Waste
However, the work that goes into DevOps is fundamentally different from wasted product development effort because most of it builds the organization's capabilities, not the product.
If you pivot to selling hamburgers, it all might be a waste. But, the chances are that if customers don’t like a startup’s first web application, the next product will still involve some sort of cloud software.
The Bottom Line
Of the work it takes to implement the practices here, only a small portion (maybe 10–20%) is application-specific, and the rest will help you hit the ground running after your next pivot.
Following good DevOps practices may just save your company.
Try minware today
