In the JUG.ru blog, a new analysis, this time Nikita Makarov from Odnoklassniki, under the magnifying glass, was a multiple participant in the program committees of our conferences. Today we will review the report on microservices for test automation. The performance took place in 2015 at the devclub.eu meeting in Tallinn:



Slides of the report can be found here .

Plot

Starting point

Binding to the word micro in Nikita’s story seems too strong to me. Purists may say that the report is not related to micro services. The speaker most likely suspected something like that, and so a section appeared on how large the micro should be. It is necessary in order to refer to the definition if necessary.
')
In my opinion, all this is superfluous. It was not worth building a speech “from buzzword,” that is, from microservices. Testing a social network is a difficult task, and the approaches Nikita talks about are interesting and valuable no matter how small the services created for this are. The talk about interesting things - about the specifics of the subject area - begins approximately from the seventeenth minute. I would have pulled it to the very beginning, and the explanations about microservices dosed as they become necessary to understand what is happening. So you can make room for interesting things that are now affected in the story only indirectly.

For example, for such

Testing in production is very interesting, and it’s good that Nikita and the team never managed to drop the Odnoklassniki portal. From the inside, I remember, dropping “Yandex”, once I was able to assess the quality of the search with some of my participation. If you are added to all whitelists and anti-vandal systems therefore do not react, and you shoot a lot of requests into the service without delay and other politeness, then anything can happen.

But about the load, people usually remember this way, but in my experience, they start to exclude their own bots from statistics only after incidents. How many bots are there, they think. For “Classmates” Nikita gives the answer: there are ~ 20,000 of them. We, he says, know our bots by sight and by name and know how not to take them into account. But from the further course of the story it is clear that “we” are a rather narrow circle of people. Admins in their statistics considered bots as normal people. Who do they consider, for example, people predicting advertising revenue or analysts who consider any user engagement, retention or churn rate? Bots perform repeated scenarios without interruptions for sleep and food, and, if they are not excluded from the calculations, they can generate a lot of statistics. At 24:20 Nikita gives an example of a testing team, which could be lit even on the scale of Youtube, and this is not an exceptional case.

To remove some class of scripts or users from statistics is a difficult task when you solve it for the first time. Usually there are many places where users are taken into account (not all of them design a system for collecting statistics at once with the expectation that it is convenient to exclude anything from it), and no one knows all these places. If it really was possible to distinguish everything, then this is a valuable experience worth sharing.

In general, the topic of testing in production is quite broad and facile, and I would add to the story some bloody details related to it.

findings

Conclusions (entitled "Lessons learned") begin at 44:00 . Everything Nikita says at the end of the report is connected with the problems of microservices as a whole and, in my opinion, does not relate directly to testing. “If you have 800 fronts, then how to get some of them out of production and then turn them on again so that users won't notice anything?” - this is not about the services used specifically for testing. This, as well as the other points of the conclusions, are the lessons learned by Odnoklassniki as a whole in the process of introducing microservices.

Thus, the story falls apart: the introduction and conclusion are devoted to microservices as a whole, and the central part covers, in fact, their use in testing.

Slides

Laser pointer

I’m sure you already know everything about the laser pointer and how much damage it carries, but I’ll note that it appears at 3:37 and 7:40 in the talk, and for those who watch the video, it’s not clear both times where it is located “right here Referred to by the speaker. From the context, this can be restored, but at the cost of extra mental effort.

Duplicate items

On many slides we will see an orange plate in the area of ​​the upper left corner. What is written on it marks the place (chapter, if you will) in the script of the whole performance, while the title of the slide refers to what is on the screen right now. This is an attempt to implement a sensible idea of ​​preserving the context (so that the viewer at every moment understands where we are now globally), but in my opinion, it does not work.

In reality, on many slides, the title is simply duplicated (sometimes literally, sometimes only in meaning):



In addition to the fourth slide shown here, which we will look at further below, this situation occurs on slides 3, 5, 6, 7, 8, 9, 10, 16, 17, 18, 19, 21, 22, 24, 25, 28, 29, 31, 32, 37, 50 and 51. All the attention that the viewer spends on comparing these headlines and subheadings is a net loss, albeit a small one.

How to reduce this loss? We will be greatly helped by the revised plan of the report, in which the topics are highlighted more large, then the orange title will not change so often. But it will help us even more if we can show this plan at the beginning of the speech and return to it periodically, marking the points as we go through them. This can be either a text list or a schema. For our purposes, the diagram shown on slide 48 would be quite suitable, but more on that below.

Drawings

While we are not far from slide 4, note that there are:

• white graphic picture on a dark gray background;
• the word "VISIBILITY" written vertically;
• a piece of the word "MATURITY" on the horizontal axis

I believe that it is worth getting rid of all this, at least somehow (the option is not perfect, but very simple):


On many other slides, a gray background adds a frame around the content; it works as an extra (extra) element. In my opinion, if the picture occupies all the available space without fields, it looks better, for example, here:



or here:



The fact that the Alien and the Predator have a board that is wrong and the first to go black is discarded as petty quibbles: after all, they are aliens and are not obliged to play by earthly rules. But for the future, we note that any person with a chess past, seeing a board in a piece of art, immediately begins to check whether the colors are in the lower right corner and how the pieces are arranged. And it is especially distracted if it notices inconsistencies.

Schema and Saving Context

Let us return to the diagram that appears on slides 38-48 (I will give here the first and the last of them):



These two pictures show the initial and final view of the Odnoklassniki testing architecture at the time of the story. Slides 39-47 are intermediate states.

Relatively complex architectural schemes to correctly display exactly the way Nikita does. Elements of the scheme should appear consistently, then at each moment the viewers understand what the speaker is commenting on and where to look. Moreover, the architectural scheme, as a rule, is interesting not in the static form of the current description, but along with its history, in dynamics. The history of the emergence of architecture explains why the scheme is exactly what problems the developers have solved, introducing each new element. So the viewer is much easier to understand what is applicable from this in his case and what is not.

Descriptions of only current architecture in isolation from its history, so often encountered at technical conferences, in my opinion, almost completely fly past the ears and brains of the audience. So in this place I urge you to take an example from the speaker.

Nevertheless, I think that it was possible to do even better. If you take slide 48 as a basis, and from the 38th to begin the performance, then this consistently growing scheme could serve as an excellent skeleton of the whole story. Then detailed stories about Revolver, Mnemonic and Storekeeper could appear in those moments when the corresponding block opens in the diagram.

Minute advertising

In Moscow, December 8-9, the next edition of the conference Heisenbag will take place, and Nikita will perform there . He will tell interesting things, just saying.

Regular Parsing

If you want to get feedback on your performance, I’ll be happy to give it to you.