Reading longer texts takes some time. A cup of tea (or coffee) might help. ☕ |
|
Some keywords:
3GPP IoT Docker C C++ Microservices Python Kubernetes Helm Redis
In summer 2016 I was asked whether I could also take the role of a system manager. Perhaps, I need to explain what it actually means since just saying "system manager" might sound like someone who simply tries to sound important but without having any substance. In telecom different network functions can be spread across many different modules. Many of those modules can use a few different technologies that were evolving over several decades. Different modules might be developed by various vendors and also have many different versions. How could all this possibly work together? By being compliant to industry standards. The most important standards organization everyone needs to know is 3GPP. I might simply suggest you to visit their official web site but you will probably start wondering whether I am related to Ivan Susanin in any way. I am not, sorry to disappoint you.
Jokes aside, one can imagine that telecom is extremely complex. No one human being is capable of knowing every single detail of every standard. Those standards also continue evolving, which means that they need to be followed up. There are many people who are experts in their respective areas. To be able to build a product that works correctly according to 3GPP standards one needs to coordinate efforts among all experts. Those experts might be sitting across the globe, not in the same building. And the development team was expecting from me a list of concrete and detailed requirements that cover all the relevant standards. Needless to say that the requirements needed to be correct, otherwise the team might build a wrong product. Can you now see some more substance in the role of system manager?
Since my team got to introduce the support of IoT, I could call me quite lucky. It only required coordination with ten experts across the company. And the new development only needed to be compliant with eight 3GPP standards. Fortunately for me, other system managers were exceptionally kind, helpful and experienced colleagues. They had exceptional patience. So, in the beginning of work packages I needed to do some reading, analysis, coordination and writing requirements for the team. Then I could join the team as a developer and to do some work as a software engineer. However, once anything became vague or unclear, I had to investigate it – most often with other system managers. When the work package was approaching its end, it was time for me to make sure that every requirement was covered and traced to its acceptance test. Finally, I needed to make sure that the new functionality was properly documented and to update all the compliance documents. And to prepare courses for support teams about how to configure and troubleshoot. All this while making sure that the team always has something to do. I was having a lot of fun! For those who are interested to look deeper, I can always suggest checking out release 14, especially the part about "improvements of the Cellular Internet of Things (CIoT)". Still want to see more? Okay, then feel free to download my two favourite specifications – any version after release 14 will do:
- 3GPP TS 23.401: General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access
- 3GPP TS 29.274: 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3
If you actually downloaded and opened those two documents, then you could understand how information overload feels. I guess, that might be the exact reason why many of my colleagues chose to keep a long distance from system managers. The risk of becoming one was frightening enough. At some point, I even noticed that some of my colleagues started to keep a distance from me. It was not a good sign. Fortunately (or unfortunately – depends on which side you choose), after a couple of years my team received work packages in containerization instead. Suddenly, it meant less administrative work for me. Less coordination and more engineering.
Making an existing application to become cloud native required several steps – the first one was migration of the environment from COTS hardware platform to Docker containers. That required changes in many modules. Even though the main programming languages remained unchanged – C and C++, the architecture needed to be completely reorganized in order to fully support microservices. Since the project was also evoving in other directions, we had to set up some kind of automatic deployment tests. Without such tests, other teams kept breaking our code – without even being aware of it. Good luck with such continuous integration! That became just the right moment for me to step in with programming in Python and to develop such deployment tests. From that point onwards our colleagues were receiving automatic emails every time they broke our code. Some even appreciated it. Once the application was up and running, it became time for us to implement its automatic scaling, which was the main point of making it cloud-native. In other words, we were having fun with Kubernetes and Helm. In order to get better resilience we also had to reorganize the internal data storage, Redis became the new foundation. Perhaps, some of my colleagues still remember my hilarious demos at the end of every sprint – our team chose to outsource all such presentations to me. I did not mind.