What are the tradeoffs in the FAB theory?
Fast: Results are fast enough so that people can have a seamless interaction. Accurate: Answers are accurate and don’t have a margin of error. Big: Dozens or hundreds of systems are involved in calculating the result. Most SQL databases are in the FA space whereas Hadoop and related systems are generally AB systems. A system optimized for FB is Elasticsearch for example.
While Fast and Big are relatively easy to understand, Accurate is a bit harder to picture. This talk shows some concrete examples of accuracy tradeoffs Elasticsearch has taken and how to optimize them for your use case.

This talk giving a fundamental understanding of Reactive Approaches with Spring 5 and Reactor 3 and showing how to build/migrate Reactive System to new Reactive Stack. Also, the audience gets an understanding of common business needs where those techniques are shining the brightest and helping in solving complex problems most effectively.

REST-ish APIs have become the de-facto standard in the last 10 years. But is it always the right choice?
Facebook, GitHub, and Pinterest challenge status quo in network communication and embrace GraphQL — query language for the APIs. This evolving standard also gives you runtime to execute the queries and enables comprehensive dev tooling, making it juicy for a developer to try and explore. That's what we, at Wix, did too!
In this talk, we will see GraphQL in real, practical action under Java sauce. We'll elaborate on our experience with GraphQL at Wix, see how it compares to REST, and, like with every other technology, understand its limits and shortcomings.
So, is GraphQL right for you? Come by, and we'll see!

Service mesh is a dedicated layer in and company’s architecture which supposed to simplify communications between service and make it secure and reliable. Service mesh covers a wide range of features: routing, service discovery, balancing, failure handling, monitoring, tracing, authentication and authorization and other. In my presentation, I would like to talk about building a service mesh giving Booking.com as a prime example. The context of this process is essential: we’re moving from monolith architecture to SOA. We will go deep into ideas behind service mesh, design decisions and implementation details of the solution we decided to follow. We will also talk about introduction and usage of L7 proxies envoy and linkerd.

Everyone wants to understand what their application is really doing in production, but this information is normally invisible to developers. Profilers tell you what code your application is running but few developers profile and mostly on their development environments. Thankfully production profiling is now a practical reality that can help you solve and avoid performance problems.
Profiling in development can be problematic because it’s rare that you have a realistic workload or performance test for your system. Even if you’ve got accurate perf tests maintaining these and validating that they represent production systems is hugely time consuming and hard. Not only that but often the hardware and operating system that you run in production are different from your development environment.
This pragmatic talk will help you understand the ins and outs of profiling in a production system. You’ll learn about different techniques and approaches that help you understand what’s really happening with your system. This helps you to solve new performance problems, regressions and undertake capacity planning exercises.

Nowadays, one uses many languages to code an applications. Javascript, HTML, CSS, Java, SQL, Kotlin, Android, iOS and so on. Did you know, Kotlin compiles the same code to different platforms? With that, you reduce the number of languages in your application and benefit from code reuse, e.g., from server-side JVM and client-side JavaScript.
Join us to welcome the new world of reusable code. In the talk, we will be creating a web application with JVM backend, React JavaScript frontend. Eugene explains, how Kotlin allows us to reuse code between platforms. Kotlin will not help you to use your JVM library from JavaScript of vice versa. We will do live-coding and go through several examples. One need multiplatform libraries too, we cover the topic and share and use some production-ready multiplatform libraries for the demo application we create.
You’ll learn about Kotlin multiplatform programming basics and understand how you can benefit from multiplatform Kotlin in your daily projects.

Serverless computing and FaaS (Function as a Service) are the new blacks! They radically change how software is organized, deployed, and charged for.
This hands-on session will present Fn project, a new open-source project, which features a code-first approach to building polyglot applications on top of a FaaS platform. Together, we will write functions using multiple languages (Go, Java, Kotlin) and will discuss the different development phases (bootstrap, local and remote deployment, testing…).
We will then discuss an important aspect, i.e. functions orchestration. We will look at the Flow API, a distributed Promise based API, used to compose multiple functions into meaningful applications. No flow-charts, no exoteric stuff, just plain readable and testable code!

In this talk we will walk through features of Spring Cloud Gateway and Spring Cloud Config projects. We’ll overview new features provided by Spring Cloud Gateway including advanced routing options for API services supporting parallel APIs in several versions, discuss code examples and configuration options. Once API gateway is deployed, we don’t want to redeploy it on configuration changes as well as redeploy other services upon configuration updates. And this is where Spring Cloud Config enters the game. It allows you to keep configurations in the cloud, for example in a Git repository, and once paired with tools necessary, enables almost zero-down-time configuration updates, audit of changes and parallel configurations for different environments.

A few years ago you had to work hard to succeed in some fields. Nowadays you don’t need to work hard but to work smart. So this means that most of the time laziness (of course not extremely) is useful for our productivity. On the other hand, laziness is extremely important when you work with large amount of data and reduced space or power. In this talk we will try to cover all aspects of laziness in Kotlin: starting from lazy initialization of properties using delegates, lazy collections, sequences and, finally, laziness with coroutines. The main thing we would like to talk about is how to use this laziness and be productive with it. To see one more benefit of laziness in Kotlin we’ll refactor a real application to use lazy calculations.

The big project makes simple things harder. You can not make the feature available to all clients immediately after deploy. We use experiments (or maybe you heard about feature toggle) to control step-by-step launching process. And not all of them could be successfully ended because we could have learned that the feature should be reworked or fixed by technical or product reasons.
The typical experiment has several stages each requires some amount of manual labor. It leads to waste of time and sometimes to misconfiguration. For eliminating these concerns, we have decided to automate planning and launching of experiments.
Int this talk author explains: - why Kotlin was chosen, and why classic automation tools as Ansible was not - why good, short and expressive DSL is crucial - what kind of problems we faced and how to solve them all to make it worked as intended initially

AI is New Electricity and Deep Learning is one of key enablers for this, it breaks known limits of possible and disrupts vast areas of our modern life. From dev standpoint it sounds science-heavy and requires PhD in fact its not. Here I’m going to explain why in theory and practice with Kotlin. Kotlin is a modern language with great perspectives to write concise, safe and interoperable applications, while Deep Learning is something what we’re going to develop in the nearest future. So why not to combine those 2 powers into 1?

Kotlin gives us a lot of neat features and just general developer satisfaction, but little is known about its hidden costs and pain it causes. This talk is a almost a 2 year combination of small (and no so small) issues we encountered when developing a full-Kotlin application started from the scratch. Bugs, features, performance, testing — it’s all there with our answers, conclusions and advises.