92nd Monthly Technical Session
HENNGE’s Monthly Technical Session (MTS) is a platform for members to share knowledge with their peers. Each speaker gives a talk for 10–20 minutes, followed by a Q&A session. Occasionally there is also a lightning talk session at the end of an MTS, in which speakers give 5-minute talks.
The 92nd MTS was held on March 25, 2022, on Zoom. This time we also had some talks with our Global Internship Program (GIP) interns.
1. “Introduction to ngrok” by Kodama-san
Kodama-san opened the 92nd MTS with his talk about the basics of ngrok, a globally distributed reverse proxy fronting web service running in any cloud or private network (or even our own machines). With ngrok, we can expose web servers running on our machines to the Internet. ngrok provides public URLs for testing on mobile devices, testing chatbots, sending previews to clients, SSH access to Raspberry Pis, building webhook integrations, etc.
Like most SaaS, ngrok has several pricing plans, including a free one. The Free plan is perhaps most appropriate for testing purposes. On the other hand, the other plans include advanced features such as automatic generation of SSL certificates for custom domains, authentication delegation, management API, event streaming, native OS service management, load balancing, request routing, and TLS client authentication. Kodama-san and his teammates are researching how we can use those advanced features to improve HENNGE’s products and services.
2. “Service Mesh” by Nikhil
Nikhil, one of our GIP interns, gave a talk about service mesh, a dedicated infrastructure layer for facilitating service-to-service communications between services or microservices, using a proxy. The focus of Nikhil’s talk is on how service meshes can help us overcome the challenges of microservices architecture.
Microservices architecture (also known simply as microservices) is an architectural style for developing applications. It allows a large application to be separated into smaller independent parts, with each part having its own realm of responsibility.
According to Nikhil, here are some of the benefits of microservices:
- Faster delivery: microservices allow frequent releases with less risk
- Isolation: it is unlikely for a single service to crash an entire system
- Scaling: each service can be scaled depending on their usage
- Culture: each team works on a single business capability
At the same time, microservices present certain challenges:
- Service discovery: automatically detecting services on a network
- Traffic splitting: specifying the distribution of traffic across multiple versions of a service (e.g. for deployments, A/B testing, service migration)
- Security: instead of a single entry point, microservices offer many, with each potentially being a point of vulnerability
- Monitoring: understanding the behavior of a microservices application and troubleshooting its problems are challenging since requests span multiple services, with each performing its own operations
Service mesh promises to be a solution to those challenges. A service mesh consists of services and proxies running as sidecars to the services. A sidecar is attached to a parent service and provides supporting features for the parent service. A service mesh combines its sidecars into a proper distributed system, including a data plane and a control plane. The former manages sidecars, while the latter performs service discovery, service routing, load balancing, authentication, and authorization, among others.
3. “GPU Programming” by Steve
Steve, another one of our GIP interns, gave a talk about GPU programming. GPUs were invented out of the need to render 3D images to the screen (i.e. pixels) using the graphics pipeline, which is basically a number of matrix transformations. As the pipeline grew more complex, CPU processing could no longer keep up with it. And thus the GPU was invented to handle tasks like the graphics pipeline (i.e. single instruction, multiple data — SIMD). Today GPUs are also used in machine learning, crypto mining, image processing, and other SIMD tasks.
Compared to CPUs, GPUs have smaller but many, many more cores, most of which are arithmetic-logic units (ALUs), control units, and caches. This is intentional, as CPUs are designed for serialized executions, low latency, and more flexibility. On the other hand, GPUs are designed for parallelized processing, high throughput, and fewer design controls.
So, how do we program GPUs? There are many GPU programming frameworks out there, such as NVIDIA CUDA, OpenCL, and OpenACC. The most popular out of these is CUDA, to the point that it is also used internally by machine learning and deep learning frameworks like Tensorflow and PyTorch.
CUDA is a toolkit that extends C and C++ by allowing us to define functions called kernels. When a kernel is called, it is executed N times in parallel by N different CUDA threads (as opposed to only once in the case of regular functions). Each thread that executes the kernel runs independently and has access to various useful information, such as its own thread index, through built-in variables.
Steve compared the performances of a CPU, a single CUDA thread, and 256 CUDA threads in adding 2 arrays, each containing a million elements:
- CPU: ~70ms
- 1 CUDA thread: ~400ms
- 256 CUDA threads: ~2ms
This is an example of a SIMD task, and considering the number of threads used, the 256 CUDA threads came out on top as expected.
4. “Go 1.18 and Fuzzing” by Tanabe
Go 1.18 was released on March 15, 2022. Fuzzing is one of the new features included in this version. It is the act of automatically seeding random data against tests in an attempt to find vulnerabilities or crash-causing inputs.
Fuzzing is recommended for programs that are expected to be robust even when given any kind of input, as it is really hard to manually produce certain inputs that hit edge cases. For example, Chromium is continuously fuzzed by the Chrome Security Team, utilizing 15,000 cores (Mozilla and Microsoft also fuzz their browsers). The Heartbleed vulnerability was also discovered by fuzzing OpenSSL.
Fuzzing is integrated with the standard toolchain of the “go test” command. However, since fuzzing is very resource-intensive, it has to be invoked manually by using the “-fuzz” flag. Failing inputs are automatically saved to the “testdata/fuzz/<TestName>/<Input>” directory. Fuzzing is done concurrently using multiple CPU cores, and it indeed uses a lot of CPU capacity (as well as storage). As of Go 1.18, coverage-guided fuzzing is available for AMD64 and ARM64 architectures as a more efficient alternative.
Tanabe-san and his teammates had tried fuzzing their products and services. After several hours, a crash bug was found and the team then worked on fixing it.
At the end of his talk, Tanabe-san gave some tips on writing fuzzing tests:
- Follow the standard library’ convention in naming fuzzing tests (i.e. <TestName>_test.go)
- Write a round-trip fuzzing test whenever possible (i.e. parse → encode → parse → compare the result; for successful parses, assert that parsers are in the “known” state)
- Start writing fuzzing tests so that as many errors as possible fail early, then update the code to ignore known errors and carry on fuzzing (make use of the fact that “go test” automatically records all failing inputs)
5. “Infrastructure as Code with Pulumi” by Krizza
Krizza was the last of our GIP interns to give a talk on the 92nd MTS. She introduced us to Pulumi, a so-called developer-first Infrastructure as Code (IaC).
These days there is no shortage of IaC tools, such as AWS CloudFormation, Terraform, and Pulumi, among others. AWS CloudFormation is exclusively for AWS services, written in JSON or YAML, and — according to Krizza — doesn’t provide the best developer experience. Terraform, on the other hand, is cloud-agnostic and written in HCL. Pulumi is quite unique as it is built on top of existing tech (i.e. other programming languages) and is open source. With Pulumi, we can provision infrastructure using familiar languages, such as TypeScript, JavaScript, Python, Go, C#, etc.
Krizza spent most of her talk actually demonstrating infrastructure provisioning with Pulumi. The programming language she chose for this demo was Python.
6. Lightning Talk #1: “Criminal Actor Targeting Organizations for Data Exfiltration and Destruction” by Ogura-san
In relation to Okta’s investigation of digital breach reports, Microsoft has released a report detailing their own investigation into large-scale social engineering and extortion campaigns against multiple organizations (one of which being Okta). Ogura-san used his lightning talk to raise awareness of both the issue and the report and encouraged everyone to think about what we can do to protect ourselves from such campaigns.
7. Lightning Talk #2: “How to Write For-Loops Without Actually Writing For-Loops (in Python)” by Jonas
No, Jonas’ talk was not about recursion.
Instead, he used a combination of decorators, unicodes in identifiers, regexes, and ASCII codes to replace actual code objects. The idea is that the code object of the decorated function is replaced with an updated version of itself (the update being replacing certain identifiers with ASCII codes, which builds the strings of for-loops 😁).
As usual, we had a party afterward (on Zoom) 😄
