Go Way Fest 2017

Go is repeatedly being marketed as a language suited for developing high performance server applications, but what exactly makes Go programs scale? In this session we'll look at the design of the Go language and runtime, compare it to other technologies and understand how it works internally and what makes it perfect for high performance applications. If you want to learn about the language that was used to develop Kubernetes, Docker, Gett, Juno and other well known high traffic systems, this is the session for you!

Новые микросервисы появляются, но монолит никуда не исчезает. Мы в Avito разрабатываем и деплоим сервисы с помощью связки Docker и Kubernetes. Зачастую интегрировать монолит с сервисами довольно проблематично. А что, если монолит тоже завернуть в Docker+Kubernetes и применять те же практики, что и для микросервисов?
В докладе речь пойдёт о том, как изменилась Dev-среда в Avito в связи с переходом на микросервисную архитектуру. В частности, поговорим про:
- подход "legacy in a box";
- то, как мы решали проблемы с базами и sphinxsearch;
- то, как Docker и Kubernetes помогли нам сократить различия между окружениями;
- Developer Experience.
Доклад будет полезен как командам, планирующим или переживающим распил монолита, так и всем тем, кому приходится работать со сторонними legacy-системами.

The Golang standard library provides a lot of examples of code design practices and patterns which allow us to create great things. However in practice engineers often ignore them. I`m going to tell the story about one little library: the way from write-to-work stage to the idiomatic go implementation.

In this talk I will make a review of code generation tools that can help you to test your Go programs without writing tons of boilerplate code. Together we will go through the process of testing concurrent go program using a mock generation tool that we use at Juno.

One of the primary strengths of Go programming language is a built-in first-class support for concurrency. Go is designed with concurrency in mind, backed by solid mathematical theory, and has incredibly good tooling for testing and developing concurrent software.
I offer a completely new approach to understanding and representing concurrency by visualizing it in 3D space. This new approach allows you to see what’s happening inside the real code—from a simple “Hello, World” to real production-level high-loaded servers. It leverages the power of open source technologies, such as Go and WebGL, to help you understand the complex but astonishing world of modern concurrent software.

Over the years Go compiler become smarter and standard library become faster, yet sometimes one still needs to fix a bottleneck, to resolve a locking problem and understand garbage collector pauses. My talk is about all this. We will learn to write proper benchmarks, use pprof and execution tracer, will look into runtime debug information and will touch a Linux performance tools. I will also mention a few of Go compiler optimizations and how not to accidentally disable them.

This speech is about team which invented its own network security protocol for the big Golang project. Yes we were sober and conscious and still did it!
First of all - “why”?!
Everybody knows Go runtime SSL is quite slow. Less common it’s memory footprint could not be considered as optimal.
Yes, we do know we can link OpenSSL to our program and get as performant as NGINX, for example.
But did it cross your mind OpenSSL is also not fast enough for some corner cases? Say, you have to accept 1M new connections in 30 seconds…
The problem is: SSL is slow and CPU intensive on establishing connection phase.
On inCaller project we came across this: to perform the tasks we need 32 CPU cores only. That mean 4 servers cluster. To accept new connections fast enough we need 480 CPU cores, which give us 60 servers cluster.
60 servers cluster is about 15 times worst than 4 servers cluster, obviously.
Looking to this unpleasant math we’ve decided to build our own encryption and security protocol. And we succeeded!
What we did, how we did it and what we’ve got finally - this is what my speech about.

Each day, Pusher sends billions of messages in realtime: source to destination in less than 100ms. How do we achieve this? A key factor is Go’s low-latency garbage collector.
Garbage collectors are a bane of realtime systems because they pause the program. So when designing our new message bus, we chose the language carefully. Go emphasizes low latency, but we were wary: does Go really achieve this? If so, how?
Go's garbage collector runs concurrently with the program. But concurrency is hard! It was only through several white-board sessions that we convinced ourselves that Go's GC works. In the first half of this talk we step through animations of the algorithm which we hope will give you some intuition.
So much for theory -- is it low latency in practice? In the second half of the talk we will present the results of benchmarking pause times in a number of languages. How did Go compare? Come to this talk to see the results...
This talk is given by Will Sewell and Jim Fisher, both working at Pusher. Can't wait? You can read their investigation into Go's GC.

Choosing Go for backend side was Juno's right choice along with many other companies worldwide. Why Go? How did we start? And the most important is how did we look for right people to join the backend team?