DevOps is a quite simple thing. It appeared and was developing due to not only the hype, but also foremost due to its being profitable and convenient for business. In this article, I will try to explain the DevOps economy with the simple words, so that the response to the time-honored sysadmins would sound worthily. Let us begin.

Business

Business first. This is a DevOps’ mantra. Why creating cool things if they are useless? Let us say that there is a Peter who makes up a simple product which earns $ 3 million a month, and there is a Gregory who creates the same thing but gets $ 100 thousand a month. What do you think who can invest more money in his work and win in the long run?

The objective of any good engineer lies in understanding of what money can bring or decrease the damage and what can’t. However, the main thing is business but not money.

Influence

Of course, neither Peter nor Gregory have idea about what makes their development work. They can delegate. In the result, permissions are reallocated in a chain order. And communication is the most important authority of the engineer.

The practice shows that even important code issues are not as essential as the problem of human co-operation. Overhead cost on negotiations and coordination bring quite serious problems. If you help in their solution, well done! If you create problems – not well done. Don’t choose the second option.

Imagine yourself to be a noble doughty knight and you need to save the princess, who has been held hostage by the evil brown shirts. The way to their cave is crossed with an enormous ravine with a single narrow bridge. The bridge is not so pleasant itself, but, in addition, it is guarded by the evil Hillman with shellproof skin, who lets anybody who agree with his opinion pass.

What would you do? Would you try to fight with him? Side-step the ravine? But by this time the princess can be killed or damaged.

Maybe, it’s better to make terms with the Hillman? This idea is evident if you aim not to show your fidelity or cleverness and power, but to save the princess. Make terms, communicate, solve the problem, but don’t show yourself off.

In order to be able to make terms, it is important to know what you want to achieve. Let’s try to have a look at the business economy and include DevOps there.

Classics

There are a few different ways to look at economy. Adam Smith reckoned that if every subject of the economy would act according to his/her selfish interests, this would create the rivalry and in the result it would lead to the overall advantage. He lived in the end of the XVIII- beginning of the XIX centuries. However, his ideas are still sound.

Speaking about DevOps and IT: if it is beneficial to engineers to learn new technologies and create cool things with the aim to improve their CV, then they will do it. While it’s beneficial for the company to get the engineers create cool things. Such as win-win.

However, this rule has the downside: e.i. some schools get additional scholarships if their graduates have a high average examination score. It leads to the tries to fake the results. Even now when there are some overall state exams, in the high school both teachers and children are busy with preparing to pass the exams. The situation is still win -win for schools and pupils, but in fact, instead of acquiring general knowledge and increasing the level of education, they are busy with writing synthetic tests. Partially it is similar to the situation when the video card manufacturers improved the cards for the famous benchmark, sacrificing the performance in the games.

And if it is beneficial for engineers to create cool things for CV, then we get work with the CV, but not the product. It can either bring benefit or break the team after the “cool” tasks being performed.

Whereas surgeons are assessed by the number of successful operations, we get medicine where surgeons are ready to get only the operations with a low possibility of having negative result. Is this beneficial for the patients? Not sure.

When you gather a team, don’t look for people who know all modern words or those who have experience in working with cool projects. Look for employees who solve the problem with minimal spending and who understand what they do.

On the whole, realising of the fact that different people have diverse aims always helps during negotiations. Use this knowledge wisely and make you business work.

Actually it’s impossible to make DevOps if everybody is ruled by his/her selfish interests without any control from the authority. If everybody solves his/her tasks only, in the result such a hierarchy appears by which the majority of company employees work not for the product but for the alpha, and where the smallest whim of this alpha is more important than the crucial needs of the rest.

Neo-classical

The main discrepancy between this and classical schools lies in assessing the results from the point of their necessity.

So if an engineer spends 2 weeks on changing the web-page loading time from 0.1 seconds to 0.05, this work maybe less valuable than changing a landing page background, if the latter is of more benefit in the end.

If pay attention to what is important now, you may appear in the state of a blacksmith who spent much time on efforts to forge the ideal sword and while he was doing it, the kingdom was already twice captured by different unknown to each other forces.

It sounds not bad, as it’s possible to build KPI and quite easy to set priorities. In theory. The practice shows that any KPI turns into synthetic test from the above mentioned example. By the way, there is a problem with long-range investments: the executive seldom makes plans seriously for more than 3 years and/or their plans are not coordinated with other departments.

For example, it’s possible to use SaaS mindless not taking into consideration the cost of migration in the Future.

More problems appear while creating KPI by each department, because everyone wants to assess their own work. The most frequently the absence of the centralized plan leads to diverse priorities between departments or even between the members within one product. You can try to use the Pareto principle but this is more frequently a way to paralyse business but not to come up with something constructive.

I saw the efforts to find a universe solution, including financial reports between the teams and work for inner currency. This seems to be a sound idea that everyone would know how much are spent and from where the money are earned. However, without reasonable implementation it’s possible that marketing department will become profitable. It sounds absurd, but everything begins to spin around the lobbying of inner accounts in front of the big boss who decides who pays whom and how much.

From each according to needs, to each according to the abilities.

Other companies build communism in separately taken society. They are ruled by simple logic:

If to employ people who know how to do their work, who will stick to the general plan and who won’t abuse the system, then it’s possible to provide them with any necessary conditions.

The modern luxury cultural start-up comes out of this rule: office managers, relax and musical rooms, masseurs, free food and latitude inside the company.

Create database or speed up the page load whenever you want. The main thing is to do everything according to the plan. And it’s even better not only to fulfil the plan, but to overfulfil it:)

In any case such high demands make hiring staff in not so easy IT sphere even more complicated: it’s necessary to take into account not only technical skills but also human characteristics in relations to which the demands can be quite high.

At early stages when everyone sees each other it’s quite convenient. In such an open to experiments system DevOps is quite simple, because everyone is ready for changes when there is no necessity to fight for the place under the sun.

On the other hand, if there are sales, then the teams can do anything they want. “Guys at work”. But what are they doing there? If the plan is executed with the aid of marketing then there is no sense for programmers to write quick codes. All these will work till the difficulties start, and then the fuss and reorganisation will come. In addition, the system is not resistant to inner manipulations.

Furthermore, such systems are very difficult to scale. Such nagging as “Oh, this start-up lost its spirit” is closely connected with this. I understand that while there are 20 of you and you are looking for the 21st, then it’s quite easy do not think about the absence of necessity to map out work and just let everybody do everything they think to be correct. Though while beginning to scale, spare tyre is inevitable similar to the beer belly after 30.

On the part of DevOps it is sound to make the decision to divide everything into minimal team flaw stakes or even make noops – come up with the idea that each team deals with its project isolated from other for as much as possible. So that there is communism and freedom inside the team and planned economy outside. But the assessment of this teams work is not as easy as it can seem. And on the whole any planned activities are a-priory clumsy since it’s possible to see whether the department moves in the right direction only while looking at the whole plan.

Schumpeter school

The innovations first, then the rest.

If you are the second to none in something – turn it into your business.

This idea lies in the basis of the book “Re:work “, in which the guys from 37signals boast about making the external product from the internal one.

Following this logic, if you are doing your monitoring then either get a competent advantage or become able to sale it outside. Actually, this idea can be and should be compound with the others, but still it`s necessary to take into consideration that the innovations are not free. And if you are Google then you can afford developing Borg, but it’s better for everyone who is smaller to use Kibernetes.

You should create innovations but it’s necessary to realize what you will get.

Behaviourism

Having a set of rules and restrictions it’s possible to build an ideal system. And I’m on the same page with this theory.

In the ideal world.

In the reality the ITIL processes, which can`t be followed, appear.

On the other hand, you can come to interesting results while combining the creation of restrictions with other systems. Crucial: restriction on rules creation should include the Pareto criteria in one of the “soft” variations. Don’t complicate. If nobody can use the rules then nobody will use them.

As the Greeks said the bad law which is executed is better than a good one, which is ignored, that’s why take into account overhead costs.

Conclusions

The DevOps key task is neither technology deployment nor release speed-up. The DevOps task is to boost business. The most frequently it is communication and interaction. The technical things are just tools of achieving the aim.

If you perform quick monitoring then think whether you need it. Perhaps at this stage in the short terms it is more beneficial to use statsd/graphite compliant solution from a third-party manufacturer? Coordinate with business and count. If it’s difficult to count on money then use the Bayes theorem.

The goal of any employee in the company is help business to develop to the uttermost. Our synthetic test-oriented consciousness forgets about it.

If it’s not difficult to make decision, try to answer the questions:

• Does my solution bring profits?
• Can I make something more valuable?
• Is my decision coordinated with the business plan?
• Do I save the time of other members? How much?
• If I’m solving the problem of stability/safety, is there something more important right now?
• How much will the migration cost?
• How much will the support and development cost in the worst-case scenario?

Think, assess the consequences of your actions, do. And good luck!