The participant comes to the course or intensive. He sees the slender rows of technical support, neatly routed power cables, the staggered order of the lecture hall, bright pictures and slide schemes. Speakers with jokes and smiles give out information so that you just have time to delve into it. The stands are set up, the tasks for practice simply fly off the fingers, except that sometimes you need the help of those. support.
And also coffee breaks with like-minded people, a cheerful and driving atmosphere, exchange of experience, the most unexpected questions for speakers. And answers, and information that you will not find in manuals, but only in practice.
How much time, effort and nerves do you think it took to make it look exactly like this?
Thanks to Volodya Guryanov, a certified Kubernetes administrator and engineer/team leader at Southbridge, who witnessed and actively participated in the creation of many Slurm courses from the very beginning.
He saw the wrong side of creating courses - difficulties and spiked rakes, insights and unexpected solutions. And the usual Kubernetes intensives, such as Slurm Basic and Slurm Mega. And a new, largely revised course , which is inexorably approaching and will begin on August 19.
But, perhaps, enough lyrics, let's move on to the story itself. How from a couple of intensive topics a completely self-sufficient and multifaceted . So I'll start the story of how courses are created and developed - just like "A long time ago in a galaxy far, far away ..."
And what is there behind the scenes?
If you ask how we do courses and how it all starts, I will simply answer "Everything starts with an idea."
Usually the idea comes from somewhere – we don’t sit handcuffed in the basement until we come up with: “What topic should we do a course on?”. Ideas come by themselves from somewhere outside. Sometimes people begin to actively ask: “What do you know about this particular technology?”. Or, as with Docker, it was impossible to fit him into the timing for the intensive - he obviously had to be taken out in order to have time to tell something as part of the intensive.
That's how the idea comes about.
After she showed up, in my opinion, the most difficult moment begins - in general, to understand what to include in this course - this is very comparable to how speakers are prepared for any conferences.
There is one main pain there, when you kind of chose a topic and think: “What to tell about it? This is too simple, this is obvious, everyone knows this too.
But in fact, this is not the case. And I personally say a lot where that what seems obvious to you, to those who come to listen to you or take a course, is not at all obvious. And here there is such a large layer of work and internal conflict, and what to include in the course. As a result of which such a list of chapters is obtained with such sweeping large strokes, what will the course be about.
And then the simple routine work begins:
- Material selection
- Reading carefully the documentation for the current version, since the IT world is now developing at some cosmic speeds. Even if you work with something and make a course about it, you have to go to the documentation and see what's new there, what's interesting to talk about, what might be especially useful to mention.
- And a certain skeleton of the course appears, where most of the topics are already, in general, painted and it seems that there is something - record videos and run them in production.
- But in fact, no, then the hard work begins, but not for the authors of the course, but for those who test. Usually, our alpha testers are technical support, which, firstly, proofreads courses for any syntactical, grammatical errors. Secondly, they beat us painfully with sticks and swear when there are some completely non-obvious, incomprehensible places. When there are some complicated subordinate sentences in the texts for a couple of pages or obvious nonsense. They read it all, look out.
- Then the practice testing stage begins, where some obvious non-working things are also caught and some moments are shown that can either be made more difficult, because it becomes not very interesting - just sit and copy - and places are identified where it is very difficult and we do a lot want from people who will take this course. And then recommendations come: “Make it simpler here, guys, it will be easier to perceive and there will be more benefit from it.”
- After this amount of work has been done, the part that relates to the video has been written, everything seems to be fine. And you can already give for graduation, for advertising this course. But again, no, too early - because lately we have stopped trusting ourselves a little and, in principle, have begun to work more with feedback. There was such a thing as beta testing - this is when people who are generally third-party are invited, not connected with our company in any way, and for some goodies they are shown all parts of the course, video, text, practical tasks, so that they evaluate the quality of the material, the availability of the material and helped us make the course as good as possible.
- And when there are several such iterations, speakers, alpha testing in the form of technical support, beta testing, improvements. And then everything starts all over again - technical support, beta testing, improvements.
- And at some certain moment, the understanding comes that either we are already tied up with improvements, because it is completely unrealistic to make everyone like it, or some cardinal decisions are made. When a lot of comments on some specific places are critical, remake them globally, because something went wrong.
- Then comes the time for minor edits - somewhere the proposal is not very nicely formulated, somewhere someone does not like the font, 14,5, but I would like 15,7.
- That's when these types of remarks remain, then that's it, the course is more or less opened, official sales begin.
And at first glance, a short and simple task to make a course, it turns out to be not at all simple and takes an incredibly long time.
And there is another important point, that work with the course does not end when the course is released. Firstly, we read carefully the comments that are left to certain parts. And even despite all the efforts that we have made, some flaws are still revealed, some jambs that are corrected along the way, in real time, improved so that each subsequent user receives a better service.
Each course has its own product owner, who, in addition to defining the general concept, checks the deadlines, he makes notes in the margins that when the time comes to completely rewrite the course, it will definitely come, because in two years, or even a year, some of what we tell will become irrelevant simply because it is morally obsolete. The product owner makes notes in the margins that most often people ask which points were not clear, which tasks seemed very difficult, and which, on the contrary, seemed very simple. And all this is taken into account when re-writing the course, with some kind of refactoring, so that each iteration of the global course becomes better, more convenient and comfortable.
This is how courses come about.
How the Docker course was born
This is a separate and even unusual topic for us. Because on the one hand, we did not plan to do it, because many online schools offer it. On the other hand, he himself asked to be free and found a logical place in our concept of training an IT specialist in Kubernetes.
Speaking very globally, initially it all started with the Kubernetes course, when it was just started, in my opinion, after the first Slurm. We collected feedback and saw that a lot of people want to read something else about docker somewhere else, and in general, many people come to the basic Kubernetes course without knowing what it is. .
Therefore, they made a course for the second Slurm - or rather, not even a course, but made a couple of chapters on dockers. Where they told some of the most basic things so that people who come to the intensive do not feel left out and generally understand what is happening.
And then events unfolded something like this. The amount of material grew and ceased to fit in 3 days. And a logical and obvious idea appeared: why not make some kind of small course out of what we talk about on Slurm Basic, to which you could send people who want to watch something about Docker before the Kubernetes intensive.
Slurm Junior is, in fact, an amalgamation of several of these basic courses. As a result, the docker course became a piece of Slurm Junior. That is, it is such a zero step before и . And then there were quite basic abstractions.
At some point, people began to ask: “Guys, this is all great, this is enough to understand what you are talking about during the intensives. And where can I read in more detail about what docker can do and how to work with it, and what it is? So the idea came up to make it straight , so that, firstly, you can still send people who come to Slurm via Kubernetes to it, and on the other hand, for those who are not even interested in Kubernetes at this stage of development. So that an IT specialist can come to watch our docker course and start his evolutionary path simply from pure docker. So that we have such a full-fledged completed course - and many later, after watching this course, having worked for some time with pure docker, have grown to the point where they need Kubernetes or some other orchestration system. And they came to us in particular.
Sometimes the question is asked: "And what kind of people might not need to be Kubernetes now?" But this question is not about people, it's more about companies. Here you need to understand that Kubernetes has certain cases where it fits well and tasks that it solves well, but on the contrary, there are some such scenarios for using Kubernetes when it delivers additional pain and additional suffering. Therefore, here it does not even depend on people, but on what and how long companies have been developing.
For example, some creepy Legacy monolith - you probably shouldn’t shove it into Kubernetes, because it will bring more problems than benefits. Or, for example, if this is some kind of small project, it has small loads or, in principle, not a lot of money and resources. Then there is no point in dragging it into Kubernetes.
And in general, probably, in general, as many people have already said, that if you are wondering: “Do I need Kubernetes?”, then most likely you do not need it. I don't remember who first came up with it, in my opinion, Pasha Selivanov. I agree with this 100%. And you need to grow up to Kubernetes - and when it’s already understood that I need Kubernetes and our company needs it, so it will help solve such and such issues, then it probably makes sense to go learn and figure out how to specifically configure it well, so that the transition to Kubernetes is not very painful.
Some kind of childhood sores and some straight simple things and even not very simple ones, you can find out in particular from us, and not go through your own rake and pain.
A lot of companies have gone exactly the way that at first there was some kind of simple infrastructure without containerization. Then they moved on to the fact that it became difficult to manage it all, they switched to dockers and at some point they grew to the point that within the framework of docker and what it offers, it becomes crowded. And they began to look at what is around, what systems solve these problems, and in particular Kubernetes - this is one of those systems that allow you to solve problems when pure docker becomes crowded and lacks functionality, this is a really good case when people they go step by step from the bottom up, understand that this technology is not enough and move to the next level. They used something, it became scarce again - and they move on.
This is a conscious choice - and it's very cool.
In general, I see that our system is very beautifully built, for example, , even on video courses. Then after docker comes , later , later . Everything lines up logically - a person passes and a whole profession turns out.
In principle, a set of courses allows you to close a lot of cases, just modern ones. There are still areas that remain a gray spot, I hope that we will soon make some courses that will allow us to close these gray areas, in particular, we will come up with something about security. Because it becomes very relevant.
In short, we have some gray areas that it would be very nice to close so that it’s generally a whole, whole picture - and people could come, and how Kubernetes itself is a Lego constructor, different things can be made from it to collect, if it’s still not enough, to supplement, like this with our courses, so that people can understand what they need from this, to assemble a kind of puzzle, a kind of constructor from our courses.
If you ask yourself the right and honest question in general: "Who needs an active Docker course now?", Then:
- Students who are just getting started.
- Testing department staff.
- In fact, there are many companies in which, until now, not only do not use dockers, but no one has heard of this technology and, in principle, do not know how to use it. And I know several large companies in the same St. Petersburg that have been developing for many years, and they used some old technologies, they are moving in this direction. In particular, for such companies, for engineers in such companies, this course can be very interesting, because, firstly, it will allow you to quickly immerse yourself in this technology, and secondly, as soon as there are several engineers who understand how it all works, they can bring it to the company and within the company already develop this culture and these directions.
- In my opinion, this course may still be useful to those who have already worked with docker, but very little and more in the style of “do it once, do it twice” - and now they are going to somehow somehow interact with the same Kubernetes, and this imposes certain obligations on them, if there is a very superficial knowledge of what docker is, how to run it, but at the same time you don’t know how it works from the inside, you don’t know what is better to do with it and what is better not to do, then this course is well suited for systematization and deepening of knowledge.
But if you have knowledge at the level: “I don’t know how to write the same docker files correctly, I imagine what namespaces are, how containers work, how they are actually implemented at the operating system level” - then it definitely makes no sense to go to us, you will not learn anything new and will be a little sad for the money and time spent.
If we formulate what advantages our course has, then:
- we tried to make this course with a sufficient number of practical cases that will allow you not only to deal with the theoretical part that is, but also to understand why you need it and how you will use it in the future;
- there are several sections that are very rarely found anywhere - and in general there are not so many materials on them. They relate to the interaction of docker with the operating system, even a little differently. What mechanisms docker took from the operating system in order to implement the containerization system - and this gives such a deeper understanding of the whole issue of running containers within the Linux operating system. How it works, how it interacts with each other inside the operating system, outside and so on.
This is such a direct deep look, which is quite rare, and at the same time, in my opinion, it is very important. If you want to understand any technology well and understand what to expect from it, you need to at least have a general idea of how it works at a low level.
Our course shows and tells how it works from the point of view of the operating system. On the one hand, that all containerization systems use the same operating system mechanisms. On the other hand, they take what is in the Linux operating system, like docker. Other containerization systems did not come up with anything new - they took what is already in Linux and just wrote a convenient wrapper that allows you to quickly call it, run it, or somehow interact with it. The same docker is not a very large layer between the operating system and the command line, it is some kind of utility that allows you not to write kilotons of commands, or some kind of C code to make a container, but to do it by introducing a couple of lines into terminal.
And plus, if we are talking specifically about docker, what docker really brought to the IT world is standards. How the application should be launched, how it should work, what are the requirements for logs, what are the requirements for scaling, configuring the application itself.
In many ways, docker is about standards.
The standards are also moving to Kubernetes - and there are exactly the same standards, if you know how to run your application well in docker, then by 99% it will work just as well within Kubernetes.
If you were interested not only in how the Docker course was created, but also in other courses, but also interested in the course itself from a practical point of view, then
We will be glad to see you!
Source: habr.com