Why DevOps for Startups?
Startups are constantly trying to move towards progress in a race against the clock. Call it product-market fit or making something people want or plain profitability. But as Armon Dadgar from Hashicorp simply put it in his DevOps for Startups talk, “…The default is failure”.
This is inspired largely from Armon’s talk with bits from around the internet and my experience working as a DevOps / Infrastructure engineer at a few startups.
But what is DevOps and why would we want it?
Some believe it’s a cultural movement within organizations where barriers are removed and responsibilities between traditional developers and operators are shared.
Some focus on the tooling, believe everything should be automated, and strive towards Automating All The Things!
Some just want to use Docker.
Hashicorp, in their DevOps Defined article, synthesizes it into three points: optimizing throughput, coordinating with tools instead of people, and clean separation of responsibilities.
DevOps can be seen as moving away from the slower Waterfall methodology, where the Dev team would pass code to the Ops team and Ops to Security team, and so on. DevOps seeks to optimize for throughput by allowing teams to work in parallel. How?
Reduce the need for coordination and empower through tools. Allow teams to focus on the delivery of their product in a low friction way.
That sounds good for larger companies with teams of people dedicated to operational tooling. What about my startup?
What typically happens in startups is the person with the most experience or interest with operating software become the Ops person. They become responsible for all things infrastructure. This works and can continue to work until that process becoming a bottleneck.
Things that are manual and require specialized knowledge about infrastructure become blockers. People become afraid to deploy because they don’t have the training and tools. The amount of work ops work is becoming unscalable for a single developer.
What should we do instead?
Democratize the Ops work through tools and automation but, as always, be pragmatic about the approach.
- Invest in deployment tooling and infrastructure to allow all members of the team to push code to Production
- Setup automated testing through a continuous integration pipelines with a provider such as Codeship.
- Provide access to monitoring, logging, metrics, and alerting to empower team members to own their product.
- Have processes automated or written down so people can follow checkboxes instead of relying on specialized knowledge.
- Leverage open source and paid tooling to allow engineers to focus on building the core of the company.
However, you don’t need to have everything at once. Talk to your team. See what would provide the most value and go from there.
If you would like help implementing some of the above with your team and organization, please don’t hesitate to send me an email at me@lamroger.com
Next up: Which cloud, CI/CD, deployment, chat, email, kitchen sink, do I pick?
