At a certain point, each ops is faced with the questions “Who am I?”, “Why am I here?” and “What to do?”, which generate numerous arguments and discussions. On the one hand, we have current problems that need to be solved, and on the other hand, we have a logical and consistent devops architecture. There is logic both there and there, so it is worth turning back and looking at the history of the Devops culture.
Let’s say that we have a business – development of some software. Thus, inside we already have several teams that develop different components and services. Regardless of the language they use, different teams do it differently. Some can afford it, others can’t. Someone wants to use some architectural solution and someone simply can’t because of the product specifics. In our reasoning we take as a starting point that all teams have different tasks and try to make them as accurate and simple as possible. You can also use devops as a service if you want to implement this culture in your business.
Ops
After a while, it becomes clear that the teams, even if they solve different tasks, face the same or similar problems. The solution of some of them will be the same regardless of the service. Accordingly, the business thinks this way: if we can highlight something common, we can form a department of people who will do only that and benefit from it.
Savings on the difference in the cost of work
If we have an expensive developer, whose time costs 30 dollars per hour, then why should he do the job that a person worth 10 dollars per hour copes with? If you allocate all the low-paid and simple work, you can save money. Besides, an expensive developer will do complex tasks which are interesting to him, and a cheap Ops – simple tasks which are not interesting to the developer.
Saving on idle time
If there are people inside the team who only do ops tasks, they will have some downtime until the team generates new tasks. By bringing people together in a common department, you can share them into several teams and benefit from this.
Saving on expertise
If there are tasks that are common to all, then different departments still come to approximately the same solutions. It is always more expensive to develop expertise in several teams at once than to keep several experts who will solve a problem both faster and better. Besides, having several experts who replace each other, you don’t have to worry that someone will become irreplaceable simply because nobody but him knows how to update a tricky setup.