There are many ways to implement a DevOps culture, but some methods work better than others. Here are a few that stand out.
The One-Man Band Method
The One-Man Band approach implements the DevOps strategy by having all members (sometimes, quite literally, one person) be responsible for Development, QA, and Operations. This model is most commonly used in smaller organizations that aren’t able to support many team members.
The axiom “Jack of all trades, master of none” perfectly describes this method.
Engineers have to split their time and talents evenly between code development, testing, and operations.
The Silo Method
The Silo model keeps the separation between teams, up to the management level, allowing for higher levels of expertise to emerge as each engineer draws on their own strengths – as dictated by their role within the organization or team. Teams are strongly encouraged to keep communications open and work together to solve issues.
Organizationally, this is almost identical to the “throw the code over the wall” approach, causing a tendency to emulate the old model as the teams maintain separation.
DevOps then becomes a mantra that the company uses in name only.
The Embedded Method (our approach)
SCTG strives to approach DevOps with the Embedded Method. We have a team of Development-oriented Engineers and Architects working in tandem with a team of Operations-oriented Engineers and Architects. Both teams report to the same management, and both are involved throughout the development, deployment, testing, and operations processes.
The teams begin by thinking through how the software will run, so the Cloud infrastructure is developed more like a piece of software. Resources on the team can exercise their personal expertise in a particular area, but are fully collaborative with all others in the DevOps organization.
This process allows for expert design of both software and infrastructure components, but without the problems of complete separation. We also find this keeps the development efficiently streamlined, as there are fewer surprises when code is developed and deployed into Testing and then to Production environments.
Treating code and infrastructure in a similar manner allows us to build and manage the infrastructure via an iterative code-like development process.
Infrastructure changes can be made just as swiftly as application code, and tested as thoroughly as a regular code update. We can handle an increase in load or a different use case as easily as we can add a feature to the software.
The Embedded method also enables us to save approximately 30-40% more time than the “over the wall” approach. Not only does it cut down on various iterations, but the AWS infrastructure is also flexible enough that we can adjust and revise servers on the fly.
If you think your organization could benefit from a DevOps model, contact us.
