Put another way, can DevOps work for small businesses? Over the past year, I've been semi-regularly attending devops meetups in the DFW area and noticed that almost everyone else who attends works for large companies. Given this realization, I started noticing how all the case studies, blog posts, and product offerings promoting devops focus on the enterprise. As someone who works almost exclusively on small teams at small companies, was I in the wrong place? Was I an impostor?
Remind me, what exactly is DevOps again?
The truth is, devops is this nebulous umbrella over a collection of tools, techniques, traditions, and anecdotes. Ask 10 devops professionals to define devops, and you will certainly get 10 different answers. For today's discussion, I will use the recently published DevOps Handbook as a guide and define devops this way:
Devops is a way of working to achieve fast and reliable delivery of software, provide rapid feedback, and support continuous learning and improvement.
With that in mind, let's explore some of the ways small teams can practice devops. Hint: You're probably already doing DevOps without even knowing it!
Devops starts small and can stay small
A common denominator in nearly all of the enterprise devops adoption stories I've heard begin with a single team. In some tales, a single underperforming team is set aside, given devops training or mentors, and ordered to ship up or ship out. In other stories, a highly performing team already working the devops way is asked to teach their process to other teams in the company. Either way, successful enterprise devops adoption starts with a single, small, autonomous, cross-functional team, then leverages their success to scale out the practice to all development teams in the company. If you're a small business with a single development team, you have an advantage here because you can skip that last step.
Devops requires modern development practices
In The Phoenix Project we learn about the three ways of devops.
- Flow: optimizing the speed at which ideas travel through the software development lifecycle and land in a finished product
- Feedback: detecting problems as early as possible so you can fix them before they become a fire you have to put out
- Continuous Learning and Improvement: turning local knowledge and discoveries (what a single person knows) into a global knowledge and discoveries (what your entire team or organization knows)
Here is a sample of tools and techniques you may already use that facilitate the three ways.
- Using Vagrant or Docker to increase dev/prod parity
- Agile practices such as pair programming and test-driven development (TDD)
- Continuous integration tools like Jenkins or GitLab CI that let you know when your changes don't play nice with other team members' changes
- Putting absolutely everything you make—source code, infrastructure configuration and definitions, documentation, build artifacts, and more—into version control
- Automated deploy scripts
- Merge/pull requests or other variations on asynchronous code review
- Putting developers in the on-call PagerDuty rotation
- Rotating developers through customer support shifts
- Feature toggles, blue green deploys, and canary releases
I could go on, but you probably get the point. For bonus points, you should stop right here and reflect on your team's tools and processes to see where you are already doing devops and how you could improve.
No seriously, stop and think about it!
You will probably forget everything I wrote in the rest of this post about 2 seconds after you read. So please, stop and think.
Devops is sharing and caring
The most important part of devops is "the community," another vague and overused term that gets tossed around carelessly. The DevOps community is really about the third way—continuous learning and improvement. Whether it's through conferences, meetups, books, blog posts, random internet comments, or sharing links on Twitter and Slack, it's important for devops practitioners to discuss their successes and failures in order to transfer knowledge. The community is not an optional thing you skip out on because you are busy or shy. Participating in a devops community is necessary to cultivate the practice for future generations of developers.
In conclusion
Am I an impostor? Of course not!
Is DevOps only for the enterprise? Hell no!
Can small companies benefit from devops? Most likely.
Do I have to call it devops? No way! Call it whatever you want.
