Software engineering is changing and DevOps is at the heart of it. There are myriad of DevOps blogs and conference talks on transforming enterprises to more DevOps, usually centered around incorporating operational concerns early on software development lifecycle (SDLC).
An Enterprise Transformation
On a larger scale, Mike Kavis, VP/Principal Architect for Cloud Technology Partners, puts it quite bluntly on a post titled No, You Are Not a DevOps Engineer.
“Enterprises are struggling with DevOps. They all want DevOps even though many do not know what it is. In many cases, I see infrastructure teams who are calling themselves DevOps leading a grassroots initiative. When I ask them where the development team is, they often say either “we did not invite them,” or even worse, “we don’t talk to them.””
Kavis goes on saying:
“Another reoccurring pattern I see is that a “DevOps” team’s first step is often to figure out if they are going to use Chef or Puppet (or Salt or Ansible or whatever else is hot). They have not even defined the problems that they are setting out to solve, but they have the tools in hand to solve them. Often these teams wind up building thousands of lines of the scripts, which raises the question, “are we in the business of writing Chef scripts or in the business of getting to market faster with better quality and more reliability?” Too often, these teams code themselves into a corner with mountains of proprietary scripts that actually add more waste to the system, instead of removing waste from the system, which is what the driving forces behind the DevOps movement are all about.”
Arguably these are symptoms specific to big enterprises, where traditionally massive engineering silos exists with minimal communication coupled with ticketing/queuing systems in between departments. But are startup basically immune to these symptoms?
Definition of DevOps
I agree with Kavis that DevOps is not a role or job title, it is not an engineering discipline nor a methodology or process framework. I also agree with this post, titled What Is (Not) DevOps, and How do We Get There, that DevOps is a culture shift. It is a movement that encourages and improves communication, collaboration, and fosters quality software product delivery through tight knit teamwork.
Daemon Edward, Co-Founder of DTO Solutions stated in QCon London 2014, titled Dev “Programming” Ops for DevOps Success, that the definition of DevOps to him is
- a way of seeing your problems
- a way of evaluation solutions
- a way of communicating these things
- always evolving
I wholeheartedly agree.
DevOps taxonomy in startups
Arguably the size of startups and the limited resources requires every technical members to be all-hands-on-deck, participating in all aspects of SDLC. Often those that are slightly more interested in Ops would take the lead in addressing the many -ilities in requirements and release management. Those more interested in Devs would take the lead on churning out code and test automation. Based on the lack of resource and the inherent drive and focus of a startup, the taxonomy of DevOps in startups would be the following:
- -ilities are addressed as backlog items during development
- Release/production concerns are on the table from day one
- Teams have a tighter bond, communication channel transparent
- All efforts are tightly mapped with tangible values (be it business or customer)
The DevOps sweet spot
It would appear that startups are DevOps havens. This would not be the case. Startups are not immune to the aforementioned problems in larger enterprises. Silos do exist in startups, be it a single man team or hundreds. There are plenty of pitfalls along the way. In my experience, I believe in the existence of a DevOps sweet spot. The points below are my own guidelines for chasing that utopian DevOps shangri la.
- Non-functional requirements, -ilities as features residing in backlogs
- Build systems that makes managing easy for Ops
- Foster a nurturing company environment for thriving Devs
- Treat Ops as customer facing, sales/consultancy alignment
- Treat Devs as business value delivery, marketing/R&D alignment
- Adopt lean/agile principles
- Last but not least, Stop, collaborate, and listen! (no wiser words have come out of the 90s)