Entangled ways of product development in the area of cybersecurity #1 - Asynchronous or parallel?

🇨🇿 Česká verze je níže / Scroll down for Czech version.

First acquaintance

I started working at TeskaLabs at the beginning of autumn 2017 as a student at the Faculty of Information Technology of CTU. In the job advertisement, I was particularly interested in the fact that it is a small, product-based company that does not focus on just one technology or one programming language. As a student, I asked about the possibility of a part-time job, and after my previous experience, I was looking forward to working with software engineers who understood the subject matter. In short, I would no longer have to write Android apps or websites on my own.

"We need to build a website!" was the first task from my new colleague Mila, who was currently the only other programmer in TeskaLabs besides our boss Aleš Teska. "A website for our product CatVision.io," Míla added with a smile, "but don't worry, you'll get something else to do afterwards." His last sentence made me feel a little better. Good as a part-time job, I thought, although it didn't compare to the interesting parallel programming in C that we were taking at university at the time.

I had the website written in a couple of days, as it was more or less just a one-page product description with a supposedly handsome table of pricing plans. I don't even know what Mila was working on at the time and why he was surprised when I told him I was done with the site. "Okay," Mila said brusquely, "now I'm going to introduce you to the CatVision.io backend, frontend, and mobile app, where we'll capitalize on your previous Android knowledge." Hooray, after the first week on the job we're moving on, just like that, I said to myself.

While I was diving into customizing a JavaScript site in Angular.js, a library I'd never seen before, as well as a Flask backend in Python and customizing the design of an Android app with a winking cat in the logo, Ales Teska and Mila were working on delivering SeaCat, our first or second generation secure communications product. I realized right away that CatVision.io actually uses SeaCat as well, to transmit the current state of the mobile screen to the web portal server. So I saw SeaCat as the TeskaLabs center of gravity, but I wasn't very wise from the code written in C that I was looking at out of my natural curiosity, as well as Python, Java, C#, etc. Enlightenment was to come much later.

In addition to SeaCat, at the time Ales was deploying the first form of another product of ours that was written in Python and could collect and parse logs, or various events recorded as lines of text, in short, information about what happened on a given computer. It was a product called LogMan.io, which at the time, in addition to SysLog, could collect some events from telecommunications providers. At that time Aleš was already using ElasticSearch and Kibana, where he stored these processed events, i.e. parsed into a uniform structure. SeaCat, LogMan.io, events - all these concepts made sense to me after a few months when I realized that the direction TeskaLabs was planning to take would be the right one for me.

Asynchronous or parallel? Python or C?

It all started in the first months of 2018. For a long time we worked in an agile way, i.e. we always devoted one day a week (at the time of writing this article it's only once a fortnight) to reviewing what we had done, planning our next work, retrospective and technology window, when Ales gave us a workshop on some new technology he was researching. We could afford it at the time, given the size of the team and the virtual absence of other teams in the company, and I'm extremely glad for that time because I learned a lot. Aleš was a real member of our development team back then, so we also went through his tasks and planning. However, we also held workshops outside of these planning days, especially when we needed to write a library together. And that's what happened in the early months of 2018.

"SeaCat, LogMan.io, and the new product for data analytics pumps all have something in common," Ales began broadly, "and for that common ground we need to write our own library so that the code is the same everywhere." That's not really how he put it, but I'm trying to give you some idea. "Have you ever heard of asynchronous programming?" He asked. There was silence. I wondered if it might be parallel programming in disguise, with multiple processes and multiple threads working in parallel to process part of some more complex task. I asked, but Ales replied, "That's different, but you can combine the two concepts through a so-called proactor pattern, which we will also write." When no further questions came, Ales decided to give a theoretical introduction to this mysterious concept of asynchronous programming. He started talking about an event loop that always processes some input or part of the code that was triggered by that input, by that event. If no event is currently occurring, the program sleeps and thus wastes no CPU time. On the other hand, if multiple events are being processed at the same time, the code must be written so that the first processing of an event gives the second event a chance to be processed. If the processing alternates in this way, we speak of asynchronous code; if it does not, we speak of synchronous code. The asynchronous approach is suitable for processing inputs, the synchronous approach for long computations, and the two can be combined in what is called a proactor, a parallel approach where you move the synchronous computations into threads. Their result is then an event, an input back to the asynchronous part of the program. "I wrote something similar in the C part of SeaCat," Ales finished. I have to say, it made me quite dizzy at the time.

Anyway, that day our asynchronous library ASAB started to be created in Python 3. After the introduction, we split the work, I remember that I was given the task of writing the publish-subscribe (PubSub) mechanism, with the ability to call both asynchronous code and synchronous code. PubSub is used to allow different parts of the code to let each other know about some important internal event, such as that ten seconds have passed, that a data pump needs to be started, and so on. Unlike the frontend Angular.js, where a similar mechanism also existed, I found PubSub very clear and simple, even though it may not seem so from the description. After writing ASAB, we immediately started writing another library called BSPump, which was built on top of ASAB and was just for creating data and analytics pumps.

"One day I'd like to rewrite SeaCat into ASAB," said Ales, "but we can rewrite LogMan.io into ASAB and BSPump right away." And so it happened. Mila and I took the parsers from the previous LogMan implementation, he took SysLog and I took the telecom protocols. This created two programs, two independent microservices built on asynchronous Python. "The first data pump will be under LogMan.io," Ales went on to say, "the second, the telecom one, we will start to extend and offer as a BitSwan product under our sister company LibertyAces." In addition, we've abandoned Angular.js and started working on React.

We hired another temp at the time to write ASAB with us, but he left right after that. That was unfortunate for Ales, but life goes on. "We need to recruit someone else now that we have a separate room for developers," he told with a smile. In the meantime, I was extending the data processors for all the important telecom processors according to our customer's specifications and doing the deployment. We learned with Docker, making deployment faster and more enjoyable. I even wrote an Android app called Gargoyle that collected GPS data, including phone status data, and sent it to our data pumps. It was then possible to view things like the phone's movement over time, its battery status over time, and so on, over the data in ElasticSearch using Kibana and its maps.

Other parts of this series can be found here.

🇨🇿 Spletité cesty produktového vývoje v oblasti kybernetické bezpečnosti #1 - Asynchronní nebo paralelní?

První seznámení

V TeskaLabs jsem začal pracovat začátkem podzimu roku 2017 ještě jako student Fakulty informačních technologií ČVUT. V pracovním inzerátu mě zaujalo především to, že se jedná o malou, produktovou firmu, která se navíc nezaměřuje jen na jednu technologii nebo jeden programovací jazyk. Zeptal jsem se jako student na možnost polovičního úvazku a po předchozích zkušenostech se těšil na to, že budu pracovat se softwarovými inženýry, kteří dané problematice rozumí. Zkrátka, že už dále nebudu muset sám psát aplikace pro Android nebo weby.

„Potřebujeme napsat web!“ zněl první úkol od mého nového kolegy Míly, který byl momentálně vedle našeho šéfa Aleše Tesky jediným dalším programátorem v TeskaLabs. „Web pro náš produkt CatVision.io,“ dodal Míla s úsměvem, „ale neboj se, potom dostaneš za úkol něco jiného.“ Jeho poslední věta mi trochu zvedla náladu. Jako brigáda dobrý, řekl jsem si, i když se zajímavostí paralelního programování v Cčku, které jsme v tu dobu brali ve škole, se to srovnat nedá.

Web jsem měl napsaný za pár dní, protože se jednalo více méně jen o jednostránkový popis produktu s údajně pohlednou tabulkou cenových plánů. Ani nevím, na čem Míla v tu dobu pracoval a proč byl překvapený, když jsem mu oznámil, že jsem s webem hotový. „Dobře,“ řekl Míla stroze, „teď ti představím CatVision.io backend, frontend a mobilní aplikaci, kde zužitkujeme tvé předchozí znalosti s Androidem.“ Hurá, po prvním týdnu v práci se posouváme, jen tak dál, řekl jsem si pro sebe.

Zatímco jsem se nořil do úprav JavaScriptového webu v knihovně Angular.js, kterou jsem nikdy předtím neviděl, jakož i Flaskového backendu v Pythonu a úpravy designu androidí aplikace s mrkající kočkou v logu, Aleš Teska spolu s Mílou pracovali na dodávkách SeaCatu, první nebo druhé generace našeho produktu pro zabezpečenou komunikaci. Hned mi došlo, že CatVision.io vlastně také SeaCat využívá, a to pro přenos aktuálního stavu obrazovky mobilu na server do webového portálu. SeaCat jsem tedy vnímal jako těžiště TeskaLabs, ovšem z kódu napsaného v Cčku, který jsem si z mé přirozené zvědavosti prohlížel, jakož i v Pythonu, Javě, C# apod. jsem moc moudrý nebyl. Osvícení mělo přijít až mnohem později.

Kromě SeaCatu Aleš v té době nasazoval první podobu dalšího našeho produktu, který byl napsaný v Pythonu a dokázal sbírat a parsovat logy neboli různé události zaznamenané do podoby textových řádek, zkrátka informace o tom, co se na daném počítači stalo. Jednalo se o produkt LogMan.io, který v té době kromě SysLogu uměl sbírat některé události od poskytovatelů telekomunikací. Už tehdy Aleš využíval ElasticSearch a Kibanu, kam tyto zpracované, tedy do jednotné struktury zpracované události ukládal. SeaCat, LogMan.io, události – všechny tyto pojmy pro mě získaly smysl po pár měsících, kdy mi došlo, že směr, kterým se TeskaLabs plánuje vydat, bude to pravé pro mě.

Asynchronní nebo paralelní? Python nebo C?

Vše začalo v prvních měsících roku 2018. Už dlouho jsme pracovali agilně, tedy jsme vždy jeden den v týdnu (v době psaní článku už je to jen jednou za čtrnáct dní) věnovali review toho, co jsme udělali, plánování další práce, retrospektivě a technologickému okénku, kdy nás Aleš formou workshopu zasvětil do nějaké nové technologie, kterou právě zkoumal. Tehdy jsme si to vzhledem k velikosti týmu a praktické absenci jiných týmů ve firmě mohli dovolit a jsem za tu dobu nesmírně rád, protože jsem se hodně naučil. Aleš byl totiž tehdy opravdovým členem našeho vývojového týmu, tedy také jsme procházeli jeho úkoly a plánováním. Workshopy jsme ovšem pořádali i mimo tyto plánovací dny, obzvláště v době, kdy bylo potřeba společně napsat nějakou knihovnu. A to se právě stalo v prvních měsících roku 2018.

„SeaCat, LogMan.io a nový produkt pro analytické datové pumpy mají něco společné,“ začal Aleš zeširoka, „a pro tento společný základ musíme napsat vlastní knihovnu, aby byl kód všude stejný.“ Takhle to ve skutečnosti neřekl, ale snažím se vám to nějak přiblížit. „Slyšeli jste někdy o asynchronním programování?“ zeptal se. Nastalo ticho. Přemýšlel jsem, jestli se náhodou nejedná o převlečené paralelní programování, kde se pracuje s více procesy a více vlákny, které paralelně zpracovávají část nějakého složitějšího úkolu. Zeptal jsem se, ovšem Aleš odpověděl: „To je něco jiného, můžeš ovšem oba koncepty spojit přes takzvaný proactor pattern, který taky napíšeme.“ Když žádná další otázka nepřicházela, Aleš se rozhodl dát teoretický úvod k tomuto záhadnému konceptu asynchronního programování. Začal mluvit o smyčce událostí, která zpracovává vždy nějaký vstup nebo část kódu, který byl daným vstupem, danou událostí spuštěn. Pokud žádná událost momentálně nenastala, program spí a neplýtvá tak procesorovým časem. Naopak pokud se zpracovává více událostí najednou, musí být kód napsán tak, aby první zpracování nějaké události dalo možnost zpracování druhému. Pokud se zpracování takto střídají, mluvíme o asynchronním kódu, pokud se nestřídají, mluvíme o kódu synchronním. Asynchronní přístup je vhodný pro zpracování vstupů, synchronní pro dlouhé výpočty, a oba se dají spojit takzvaným proactorem, paralelním přístupem, kdy synchronní výpočty přesunete do vláken. Jejich výsledek je pak událostí, vstupem zpět do asynchronní části programu. „Něco podobného jsem napsal v Cčkové části SeaCatu,“ dokončil Aleš. Musím říct, že se mi z toho tehdy docela motala hlava.

Každopádně ten den začala v Pythonu 3 vznikat naše asynchronní knihovna ASAB. Po úvodu jsme si rozdělili práci, pamatuji si, že mně byl dán za úkol napsat publish-subscribe (PubSub) mechanismus, a to s možností volat jak asynchronní kód, tak synchronní. PubSub slouží k tomu, aby si různé části kódu mohly dát vědět o nějaké důležité interní události, například že uplynulo deset sekund, že je potřeba spustit datovou pumpu a podobně. Na rozdíl od frontendového Angular.js, kde podobný mechanismus také existoval, mi PubSub přišel velmi přehledný a jednoduchý, i když se to tak z popisu nemusí zdát. Po napsání ASABu jsme začali hned psát další knihovnu jménem BSPump, která byla na ASABu postavená a která sloužila právě k vytváření datových a analytických pump.

„Jednoho dne bych chtěl do ASABu přepsat SeaCat,“ řekl Aleš, „ale LogMan.io můžeme do ASABu a BSPump přepsat hned.“ A tak se také stalo. S Mílou jsme vzali parsovací procesory z předchozí implementace LogMana, on SysLog a já telekomunikační protokoly. Vznikly tak dva programy, dvě nezávislé mikroslužby postavené na asynchronním Pythonu. „První datová pumpa bude pod LogMan.io,“ řekl Aleš dále, „druhou, telekomunikační, začneme rozšiřovat a pod naší sesterskou společností LibertyAces nabízet jako produkt BitSwan.“ Kromě toho jsme opustili Angular.js a začali se věnovat Reactu.

V té době jsme najali ještě jednoho brigádníka, který s námi ASAB napsal, ovšem hned poté nás opustil. To Aleše mrzelo, ale život jde dál. „Musíme nabrat někoho dalšího, když teď máme zvláštní místnost pro vývojáře,“ řekl Mílovi s úsměvem. Mezitím jsem podle specifikací od našeho zákazníka rozšiřoval datové procesory pro všechny důležité telekomunikační procesory a prováděl jejich nasazení. Naučili jsme se s Dockerem, takže nasazování bylo rychlejší a příjemnější. Psal jsem dokonce i aplikaci pro Android s názvem Gargoyle, která sbírala GPS data včetně údajů o stavu telefonu a posílala je do našich datových pump. Bylo pak možné si nad daty v ElasticSearch pomocí nástroje Kibana a jeho map zobrazit třeba pohyb telefonu v čase, stav jeho baterie v čase a podobně.

Další části této série naleznete zde.

About the Author

Premysl Cerny

Software Developer at TeskaLabs