A participant arrives at the course or intensive. They see rows of tech support, neatly run power cables, a well-organized lecture hall, vibrant images, and slide diagrams. Speakers deliver information with jokes and smiles, making it easy to engage. The stands are set up, and practical tasks flow seamlessly, though sometimes assistance from tech support is needed.
Plus, there are coffee breaks with like-minded individuals, an energetic and dynamic atmosphere, sharing experiences, and the most unexpected questions for speakers. Responses and insights that you won’t find in manuals but only through practice.
How much time, effort, and nerves do you think went into making it look just this way?
Thanks to Volodya Guryanov, a certified Kubernetes administrator and engineer/team lead at Southbridge, who has been a witness and an active participant in the creation of many Slurm courses from the very start.
He has seen the intricacies of course creation — the challenges and pitfalls, insights and unexpected solutions. And the familiar intensives on Kubernetes, such as Slurm Basic and Slurm Mega. And the new, largely revamped course , which is rapidly approaching and will begin on August 19.
But let's move away from the lyrical part and get to the actual story. How a couple of intensive topics gradually grew into a fully self-sufficient and multifaceted . So, let me begin the tale of how courses are created and developed — it’s almost like 'A long time ago in a galaxy far, far away...'
What’s behind the scenes?
If you ask how we create courses and where it all begins, I’ll simply say, 'It all starts with an idea.'
Usually, the idea comes from somewhere — we’re not sitting chained in a basement waiting to come up with: 'What topic should we make a course on?'. Ideas come from external sources. Sometimes people start actively asking: 'What do you know about this specific technology?'. Or, as with Docker, it became clear that it couldn’t be squeezed into the intensive's timing — it clearly had to be presented externally to accommodate some content within the intensive.
That’s how the idea comes about.
Once she appeared, the most challenging moment begins, in my opinion — understanding what to include in this course. It's quite comparable to how speakers prepare for various conferences.
There is one main pain point: when you seem to have chosen a topic and think, 'What can I say about it? This is too simple, this is obvious, everyone knows this.'
But it's really not like that at all. Personally, I often mention that what seems obvious to you is not at all evident to those who will come to listen to you or take the course. This creates a significant amount of work and internal conflict regarding what to include in the course. As a result, you end up with a broad outline of the chapters detailing what the course will cover.
Then the simple routine work begins:
- Material selection
- Careful reading of the documentation for the current version is essential, as the IT world is advancing at breakneck speeds. Even if you are working on something and creating a course about it, you need to go into the documentation to see what new information has emerged, what might be interesting to discuss, and what could be particularly useful to mention.
- A skeleton of the course begins to take shape, where most of the topics are generally laid out, and it seems like you just have to record the videos and launch it into production.
- But in reality, that's not the case; the hard work continues, but it's not for the course authors anymore; it's for those testing it. Typically, our alpha testers are technical support staff, who, on one hand, proofread the courses for any grammatical or syntactical errors. On the other hand, they really give us a hard time and complain when there are any obscure or confusing points. They scrutinize the texts, especially when there are complicated compound-complex sentences spanning a couple of pages or clear nonsense.
- Then comes the testing phase, where some obvious non-working elements are identified and certain points are highlighted that could either be simplified because just sitting and copying is less interesting, or they reveal areas where we expect a lot from the people who will take this course. Recommendations then come in: 'Make it a bit simpler here, it will be easier to understand and more beneficial.'
- After the work volume is completed and the part related to the video is written, everything seems fine. We can already move on to the release and advertising of this course. But again, it's too early — lately, we have somewhat lost trust in ourselves and have begun to work more with feedback. A new thing has emerged, called beta testing — this is when we invite external individuals, unrelated to our company, and show them all parts of the course, video, text, practical tasks, to assess the quality and accessibility of the material and help us make the course as good as possible.
- When we go through several iterations with speakers, alpha testing through technical support, and beta testing with revisions, it all starts over — technical support, beta testing, revisions.
- At a certain point, it becomes clear that we either stop with the revisions because it's utterly unrealistic to make everyone happy, or we make some radical decisions. When many comments on certain aspects are critical, we have to overhaul them globally because something has gone wrong.
- Then comes the time for minor corrections — where a sentence is not very elegantly phrased, someone dislikes the font at 14.5 and would prefer it to be 15.7.
- When only these types of remarks remain, the course is more or less ready, and official sales begin.
At first glance, the seemingly simple task of creating a course turns out to be anything but simple and takes an incredible amount of time.
There's one more important point: the work on the course doesn't end when it's released. First, we carefully read the comments left on various parts. Despite all the efforts we've put in, some flaws and issues are still identified and addressed in real-time, so that each subsequent user receives a better quality service.
Each course has its own product owner who not only defines the overall concept and checks deadlines but also takes notes on the side. When it's time to completely rewrite the course, which will definitely come in a year or two as some of what we teach will become outdated, these notes are crucial. The product owner tracks common questions, which parts were unclear, which tasks seemed very difficult, and which were quite easy. This feedback is taken into account during the rewrite and refactoring process, ensuring each global iteration of the course improves in quality, convenience, and comfort.
This is how courses come to be.
How the Docker course was born
This is a separate and even unusual topic for us. On one hand, we didn’t plan to create it since many online schools offer Docker courses. On the other hand, it naturally emerged and found a fitting place in our concept for training IT specialists in Kubernetes.
If we look at the big picture, it all started with the Kubernetes course when it was first launched, I think, after the first Slyrm. We gathered feedback and realized that many wanted to read more about Docker, and a lot of people came to the basic Kubernetes course not knowing what it is. .
Therefore, for the second Slyrm, we created a course — or rather, we created a couple of sections on Docker. We covered some of the most basic things so that participants in the intensive course wouldn't feel lost and could understand what was happening.
And then events unfolded somewhat like this. The amount of material grew and it ceased to fit within three days. A logical and obvious idea arose: why not create a small course from what we teach in Slyrm Basic, to which we could send people who want to check out something about Docker before the Kubernetes intensive.
Slyrm Junior is essentially a compilation of several basic courses like this. As a result, the Docker course became a part of Slyrm Junior. This means it's a foundational step before and . And then there were quite fundamental abstractions.
At some point, people started asking: "Guys, this is all great, and it's enough to understand what you're discussing in the intensives. But where can we read more about what Docker can do, how to work with it, and what it is?" Thus, the idea emerged to create a , so that, on one hand, we could still send people who attend Slyrm on Kubernetes to it, and on the other hand, for those who aren't even interested in Kubernetes at this stage. So that an IT specialist could come, check out our Docker course, and begin their evolutionary journey just with pure Docker. This way, we would have a complete, well-rounded course — and many, after watching this course and working some time with pure Docker, have progressed to the level where they needed Kubernetes or some other orchestration system. They particularly came to us.
Sometimes the question arises: "What kind of people currently might not need Kubernetes?" But this question isn't about people; it's more about companies. It's important to understand that Kubernetes has specific use cases where it fits well and tasks it solves effectively, while conversely, there are scenarios where using Kubernetes brings additional pain and suffering. So, it's not even about the people, but rather about what and how companies have been developing.
For example, some creepy monolith Legacy — it's probably not worth pushing it into Kubernetes, as that would bring more problems than benefits. Or, if it's a small project with light loads or just not much money and resources, there’s no point in dragging it into Kubernetes.
In general, as many have said, if you’re asking yourself, 'Do I need Kubernetes?', then it’s likely that you don’t need it. I don’t remember who first came up with this idea, I think it was Pasha Selivanov. I completely agree with that. You need to grow into Kubernetes — and only when you understand that you really need Kubernetes and that it can help our company solve specific issues, does it make sense to learn how to properly configure it, so that the transition to Kubernetes isn't too painful.
Some minor issues and even some rather simple things can be learned, particularly from us, rather than having to go through your own pitfalls and pain.
Many companies have followed a path where they first had a simple infrastructure without containerization. Then, as managing everything became difficult, they transitioned to Docker, and at some point, they grew to realize that with Docker and what it offers, it became cramped. They started to look around at what systems solve these problems, and specifically Kubernetes is one of those systems that helps when pure Docker feels tight and lacks functionality. This is a good case where people gradually move up, realizing that this technology is insufficient and transitioning to the next level. They used something, felt it was insufficient again — and they move further.
This is a conscious choice — and it's really great.
I see that our system is beautifully structured, for example, , even in video courses. Then, after Docker comes , then , then . Everything is logically structured — a person goes through it and ends up with a cohesive profession.
Essentially, the course set covers a lot of contemporary cases. There are still areas that remain unclear, and I hope we will soon create courses that address these gray areas, particularly related to security. This topic is becoming quite relevant.
In short, we have some gray areas that it would be great to cover so that the picture is complete. People should be able to piece together their learning experience much like building with Lego blocks, assembling different elements, and supplementing as needed, just like our courses allow them to understand what they need to create a cohesive puzzle.
If you ask yourself a proper and honest question: "Who would benefit from an active Docker course now?" then:
- Students who are just starting to explore.
- Employees in the testing department.
- In reality, there are many companies where not only are they not using Docker, but nobody has even heard of this technology and essentially does not know how to use it. I know several large companies in St. Petersburg that have been developing for many years, and they continue to use older technologies. For such companies, this course can be very interesting for engineers since it will, firstly, allow them to quickly dive into this technology, and secondly, once a few engineers understand how it all works, they can bring it into the company and foster this culture and direction internally.
- In my opinion, this course may also be useful for those who have done a little bit with Docker, but mainly in a "do it once, do it twice" fashion— and now they aim to interact with Kubernetes in some way. This imposes certain obligations; if they only have superficial knowledge of what Docker is and how to launch it, but do not know how it works internally or what the best practices are, then this course will be well-suited for systematizing and deepening their knowledge.
But if your knowledge is at the level of: 'I don't know how to correctly write Docker files, I have an idea of what namespaces are, how containers work, how they are actually implemented at the operating system level' — then there’s really no point in coming to us, you won't learn anything new, and it will be somewhat disappointing for the money and time spent.
If we were to outline the advantages of our course, it would be:
- We’ve aimed to structure this course with a sufficient number of practical cases that will not only help you grasp the theoretical part, but also understand why it is necessary and how you will use it in the future;
- There are several sections that are rarely encountered anywhere — and there isn't much material on them at all. These relate to Docker’s interaction with the operating system, although not exactly. What mechanisms Docker has borrowed from the operating system to implement containerization — and this provides a deeper understanding of the entire issue of launching containers within the Linux operating system. How it works, how it interacts with each other within the operating system, externally, and so on.
This is a rather deep insight, which is quite rare, and in my opinion, it is very important. If you want to thoroughly understand any technology and know what to expect from it, you need to have at least a general understanding of how it works at a low level.
Our course shows and explains how this works from the perspective of the operating system. On the one hand, all containerization systems use the same mechanisms of the operating system. On the other hand, they take what is available in Linux, like Docker. Other containerization systems haven't invented anything new — they took what already exists in Linux and simply wrote a convenient wrapper that allows quick invocation, launching, or interaction with it. Docker itself is not a huge layer between the operating system and the command line; it's a utility that allows you not to write tons of commands or any C code to create a container, but rather to do so by entering a couple of lines in the terminal.
Moreover, when we talk specifically about Docker, what it truly brought to the IT world is standards. How an application should be launched, how it should operate, what the logging requirements are, and what the scaling and configuration requirements for the application are.
In many ways, Docker is about standards.
These standards also transition to Kubernetes—where the same standards apply. If you can run your application well in Docker, it will most likely perform just as well within Kubernetes.
If you're interested not only in how the Docker course was created but also in other courses, and you're curious about the course from a practical perspective, then
We would be happy to see you!
Source: habr.com
